>>> HB_CHAR should be synonym of 'char' without any fixed 'signed' or >>> 'unsigned' definition. Otherwise we will have to make explicit casting >>> between 'HB_CHAR *' types and 'char *' types, i.e. when we are calling >>> OS functions. >> In this case, we could simply drop HB_CHAR, and >> also drop HB_BYTE and use HB_UCHAR and HB_SCHAR >> as the only types. Though I expect these to be >> less obvious for most users / developers. It took >> me a year to understand it, and while not all users >> are as slow-thinking as me, I'd still think that >> not many users will use HB_[U|S]CHAR because they >> won't easily grasp why/when they are useful. At >> the same time they could look for (and miss) HB_BYTE, >> especially since we always had BYTE in the past. > > BYTE also exists on some platform and its sign is undefined > so HB_[U|S]CHAR is much more precise definition. > Because we have to use OS API functions and these functions > accepts text strings then we have to use corresponding types. > It means that we need at least three types: > > signed - when needed signed iteger value storred in one character > unsigned - when needed unsigned iteger value storred in one character > undefined/raw - when needed text to pass to API function
I'd only argue with the last of the three. In this case we don't need any Harbour types at all, since the API clearly defines the required type either with its own type or some ANSI types. IOW we don't need do maintain a matching Harbour type for all possibly existing APIs we can find. So we need signed and unsigned, and for 'raw' we have ANSI C 'char' or whatever the actual API offers (f.e. BYTE or TCHAR in Widows API) > These are three different things. We can define for text 'char' type > as we currently use in the code but in such case we should not have > HB_CHAR at all because most of people will think it works like 'char' > just like HB_SHORT works like 'short' and HB_USHORT works like > 'unsigned short', etc. Please remember that types like [U]CHAR, [U]SHORT, > [U]LONG, ... are very old types commonly used on different platforms > and now when we redefined all such basic types with HB_ prefix people > will not expect that HB_ prefix gives some special meaning for them > so your proposition is creating exception. I agree with that. So I conclude we don't need HB_CHAR. This leaves use with HB_BYTE vs. HB_UCHAR. They seem to be fuly equivalent, so which one should we choose? Or how do we define the difference? Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
