Hi Przemek, > On Mon, 08 Feb 2010, [email protected] wrote: > > Hi Viktor, > >> * HB_UCHAR is now a synonym for HB_BYTE. It's now also legacy. >> * HB_SCHAR is now a synonym for HB_CHAR. It's now also legacy. >> ; TODO: Replace all HB_SCHAR with HB_CHAR and HB_UCHAR with HB_BYTE, >> and move the old types to compatibility status. > > 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). > 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. [ Technically both kind of conversion can be done at the moment, though HB_BYTE -> HB_UCHAR conversion will take another half-day with lots of manual reformatting. ] Or, we can keep HB_BYTE and HB_SCHAR. (and drop HB_CHAR and HB_UCHAR) Any further elaboration? Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
