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
Antonio Linares wrote: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
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.
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
Enrico,
yes, I agree with you. There is always a price to pay...
Antonio Linares wrote: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
const char * hb_parc( int iParam, ... )Anyway, it won't solve all the problems. As an example, I still see CLIPPER FUNCNAME( PARAMS ) in some places.
Enrico Maria Giordano wrote: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
So we can change all the remaining CLIPPER FUNCNAME( PARAMS )?
Did you see the other message of mine?
EMG
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
So, can we use hb_parc() instead of hb_parvc()? It's currently used in only 6 sources.
EMG
Enrico,
Only in those calls where it uses just one parameter
Why? Anyway, all the calls uses two parameters.
EMG
Because harbour's hb_parc() just accepts one parameter