Prototype missing?

[Antonio Linares]

The reason to introduce it is a very technical one:

Clipper never distinguished between constant and non constant strings. And it was a big missing, as a constant string can never be overwritten because that will generate a GPF. Harbour perfectly distinguishes between those different types of strings

Thats why I tell you that Harbour is so good: its technical level is much higher and complete than the one implemented originally by Clipper.

Thats why Harbour is the real Clipper successor

[Enrico Maria Giordano]

The reason to introduce it is a very technical one:

Clipper never distinguished between constant and non constant strings. And it was a big missing, as a constant string can never be overwritten because that will generate a GPF. Harbour perfectly distinguishes between those different types of strings

Thats why I tell you that Harbour is so good: its technical level is much higher and complete than the one implemented originally by Clipper.

Thats why Harbour is the real Clipper successor

Yes, I know. But still I can't use a tool driven by a group of developers that I don't like.

EMG

[Antonio Linares]

I fully understand what you mean...

Anyhow, we are technicians, and that means that many times we have to make desitions based on technical facts instead of based on personal preferences.

[Enrico Maria Giordano]

Yes, and the technical facts are that Harbour developers broke the compatibility too many times in the past for ununderstandable reasons. And we need of a stable product.

EMG

[Antonio Linares]

Enrico,

yes, I agree with you. There is always a price to pay...

[Enrico Maria Giordano]

EMG

[Enrico Maria Giordano]

The reason to introduce it is a very technical one:

Clipper never distinguished between constant and non constant strings. And it was a big missing, as a constant string can never be overwritten because that will generate a GPF. Harbour perfectly distinguishes between those different types of strings

Thats why I tell you that Harbour is so good: its technical level is much higher and complete than the one implemented originally by Clipper.

Thats why Harbour is the real Clipper successor

This is the xHarbour's prototype of hb_parc():

Code: Select all  Expand view

const char * hb_parc( int iParam, ... )

So it seems to return a const char *, just like hb_parvc() is supposed to do.

What am I missing?

EMG

[Enrico Maria Giordano]

And what about this?

Anyway, it won't solve all the problems. As an example, I still see CLIPPER FUNCNAME( PARAMS ) in some places.

EMG

[Antonio Linares]

And what about this?

Anyway, it won't solve all the problems. As an example, I still see CLIPPER FUNCNAME( PARAMS ) in some places.

EMG

Enrico,

That is kept for Clipper backwards compatibility only. We should use HB_FUNC( FUNCNAME ) instead.

[Enrico Maria Giordano]

So we can change all the remaining CLIPPER FUNCNAME( PARAMS )?

Did you see the other message of mine?

EMG

[Antonio Linares]

Enrico,

Yes, we should use HB_FUNC( ... ) only

I have compared the code of hb_parc() and hb_parvc() and it seems as they are the same except that hb_parc() does not accept the optional parameters. So the argument for constant and non constant seems useless... :-S

[Enrico Maria Giordano]

So, can we use hb_parc() instead of hb_parvc()? It's currently used in only 6 sources.

EMG

[Antonio Linares]

Enrico,

Only in those calls where it uses just one parameter

[Enrico Maria Giordano]

Why? Anyway, all the calls uses two parameters.

EMG

[Antonio Linares]

Because harbour's hb_parc() just accepts one parameter