Hi Frank and all, Nice concept, thanks. We'll need something which makes sure our own type names never collide with anything else.
Your abbrev system has its advantages, it's short and easy to work with once you've got used to it, the drawback I see is that it makes it a bit difficult to grep for type names, and there is a slight learning curve compared to more often used '8', '16', '32', '64' notation. One more: if possible we should also consider using size_t (or deal with the problem by some other means) because currently we have lots of warnings caused by mismatched size_t and long size. Some abstract type we may identify thorough Harbour: - Harbour character (text) (currently: char, BYTE, SCHAR, UCHAR) - Harbour character (binary/raw) (currently: char, BYTE, SCHAR, UCHAR) - Harbour string (text) (currently: char *, BYTE *, SCHAR *, UCHAR *) - Harbour string (binary/raw) (currently: char *, BYTE *, SCHAR *, UCHAR *) - Harbour string length / index (currently: ULONG) - Harbour array/hash table length / index (currently: ULONG) (above two can be the same) - Harbour internal indexes (pcode pointer, param count, line no, class/method ID) (currently: USHORT | LONG) - Harbour integer num (currently: int) - Harbour long num (currently: long ?) - Harbour longlong num (currently: HB_LONG ?) - Harbour float (currently: double) - probably more, please extend. (dates, other internal types...) Brgds, Viktor On Wed, Feb 4, 2009 at 1:00 PM, frank van nuffel < clipper5_...@versateladsl.be> wrote: > 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 <harbour...@syenar.hu> > *To:* Harbour Project Main Developer List. <harbour@harbour-project.org> > *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 > >
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
