Hello Viktor, Since some time i'm switched to using a simple scheme; a letter to indicate the base type (for templates), and additionally a number expressing the precision (for concrete types)
c char (as genuine char) c0 normal char c1 unicode char u unsigned int u0 8 bit ( unsigned char ) -> equivalence of char and int at this precision u1 16 bit ( unsigned ints ... ) u2 32 bit u3 64 bit i (signed) int i0 8 bit ( signed char ) -> equivalence of char and int at this precision i1 16 bit ( signed ints ... ) i2 32 bit i3 64 bit precision digit : ( 2 ^ ( 3 + x )) -> bits r float (real) r0 4 byte r1 8 byte precision digit : ( 2 ^ ( 2 + x )) -> bytes converting all typedefs throughout the harbour repository to a scheme like this results in total freedom to override and finetune external api's; perhaps to use in uppercase instead; regarding templates, using leading underscore, as in _i1 (16bit in 16 bit OS; 32bit in 32 bit OS); just my 2 cents ;-) frank ----- Original Message ----- From: Viktor Szakáts To: Harbour Project Main Developer List. Sent: Wednesday, February 04, 2009 1:45 AM Subject: [Harbour] Cleaning Harbour C types Hi all, What would the preferred direction we should go in order to avoid C type name collisions with external packages, and OS APIs (like Windows API)? Here's is an incomplete list of type names which may cause such problems: BOOL SCHAR, UCHAR, BYTE SHORT, USHORT INT, UINT LONG, ULONG INT32, UINT32 INT64, UINT64 If cleaned up, we could finally get rid of the HB_OS_WIN_USED hack and freely include "windows.h" anywhere in C code. It would allow us to integrate Harbour with any tools without having to worry about such collisions. OpenWatcom 1.8 gives hundreds of warnings for INT32. 1) One route is to prefix everything with HB_. HB_INT, HB_UINT. Pretty obvious, but a tad verbose and not very elengant for such basic types. 2) Using standard types: int, long, unsigned int. 3) Combination of the above: standard types for everything where we can be in sync with underlying compiler types, and HB_* special types whenever we want to enforce certain sizes in public Harbour APIs, or to override compiler limits for consistency, like Harbour string pointer/size, Harbour file pointer (HB_FOFFSET), Harbour array pointer/size, Harbour character type (HB_CHAR). One important point is to make above distinction and planning in advance and in full detail, before touching the source. +1) Regardless of the above we should keep legacy types for Clipper compatibility, so they should be moved to Clipper compatibility headers. Any thoughts? Brgds, Viktor ------------------------------------------------------------------------------ _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
