On Mon, 08 Feb 2010, Szak�ts Viktor wrote: > > Code readability is also important and for people working with platforms > > where 'char' is always unsigned using HB_CHAR as synonym of 'signed char' > > will be seriously confusing so in my opinion it's bad idea. > I thought of that, but IMO the only point in having > special types is to give something more. In case of > HB_CHAR being mapped to 'char' there is no point at > all besides requiring to type more and add one more > thing to worry about for developers. (Same goes to > new HB_LONG actually).
and for HB_SHORT, HB_LONG, etc. If we added new types then they should be easy to use for users and not confuse them. When I see HB_SHORT which is mapped to 'short' and then I expect that HB_CHAR is mapped to 'char'. Sooner or later someone will use 'HB_CHAR *' instead of 'char *'. > > 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 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. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
