Hi,
The main goal was to drop legacy types, and to do it
with the least amount of risk. Secondary goal is to
clean type names and usage. The first step was introduction
of HB_SIZE to solve one of the most important type
problems we have since the beginning. HB_SIZE should
eventually be converted to signed, for now it's the same
as HB_ULONG, which eliminates risks until we do this.
Converting to ANSI types would have caused huge amount
of code reformatting work, and it would have been also
risky as old type usage by itself might be an information,
and I didn't want to lose any information along the process.
Now we have a clean state. Next steps can be done
gradually, one by one, and these are either to switch our
new Harbour types to ANSI types or new dedicated Harbour
types (f.e. HB_RECNO). We can do further cleanups to
enhance consistency and to prepare for internal UNICODE
supper, non-8-bit byte systems or even 128-bit systems.
Having HB_* types is a convenience (saves typing, makes
formatting easier) and an important tool to help creating
consistent code. With ANSI C types, it's very easy to write
the same thing in dozens of different ways ('signed long'
vs. 'long' vs 'signed long int'), some of the types
have different meanings on different compilers ('char')
and some of them are not clear at all ('signed'), which
makes it very difficult to review or verify code, sync
different parts together and at the end ensure top quality.
Having a few, well-defined Harbour types solves the problem
very nicely.
[ BTW both dropping legacy types and HB_SIZE conversion
was agreed on and even recommended also by Przemek in the
past, I believe his reluctance was due to possible risks
in destabilizing the code. ]
Brgds,
Viktor
On 2010 Feb 9, at 13:42, Mindaugas Kavaliauskas wrote:
> Hi,
>
>
> Viktor Szakáts wrote:
>> Or, we can keep HB_BYTE and HB_SCHAR. (and drop HB_CHAR and HB_UCHAR)
>> Any further elaboration?
>
> I'm a little lost on the whole idea of type name change. I guess we have two
> purposes:
> 1) drop Windows specific defines, like LONG, ULONG, BYTE, etc.
> 2) solve some platform limit problems like array limit, string limit
> problems. We are using long type for this, but 64-bit windows uses 32-bit
> long values. So, we need to change index to have a size of pointer.
>
> I guess the first problem could be solved just replacing LONG, ULONG, SHORT,
> USORT by long, unsigned long, short, unsigned short. Why do we define a new
> types like HB_LONG, HB_ULONG, HB_SCHAR? Just to have a shorter type name?
>
> So solve the second problem, we need to define the expected limits of some
> values, like expected function parameter count, expected dynamic symbol table
> item count, expected array size, expected string size.
> F.e., if the decide we need to have strings as big as memory can contain, we
> need string length to have a size of pointer. In most platforms long (or
> unsigned long) is OK, but on 64-bit Win it is to small, so we define a new
> type HB_SIZE and use it address all string, array, hash, etc, item count.
> If we are satisfied with some existing type we do not need a new harbour
> type. F.e, if int type fits function parameter count (it can be negative,
> because -1 means return value, it is enough width on DOS, 32-bit, 64-bit
> platforms), we can use int to store param count/number. If we want to have
> another type like HB_PARAMCOUNT we can have it, but it could be a big job to
> find all variables that stores param count.
>
> I'm not a guru of different OSes, and I do not imaging how character and byte
> types can have width different from 8-bit. So, I have no comments on topics
> like:
>>> - Deleted HB_I8 and HB_U8 types. Practice shows that
>>> HB_UCHAR and HB_SCHAR are used instead of these.
>> Does it mean that we decided to definitely drop support for platforms
>> which do not use 8 bit characters?
>
>
>
> Regards,
> Mindaugas
>
>
> P.S. perhaps I had to start a message from this, but I see Viktor is making a
> huge worik on type name change, and I see Przemek is a little sceptical,
> because he sees some bad sides of this change. I guess we should
> discuss/deside, what do we want to do, and what are the ways to reach our
> goal.
>
>
> _______________________________________________
> Harbour mailing list (attachment size limit: 40KB)
> [email protected]
> http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
