[Harbour] SF.net SVN: harbour-project:[12805] trunk/harbour

[Viktor Szakáts]

Thanks Przemek.

I didn't want to make any actual type migration in code
before 2.0.0 final, just trying to settle on the plans
for now. (I'm using my small local .c codebase to try
out new type, IOW I don't want to see any Windows types
there rather sooner than later).

As for your planned modifications, I'm looking forward
to see them, sounds great.

Brgds,
Viktor

On 2009 Nov 1, at 16:37, Przemysław Czerpak wrote:

> On Sun, 01 Nov 2009, Szak�ts Viktor wrote:
>>>> Do you remember that HB_[U]LONG is not the same as [U]LONG?
>>> I had it in mind, but after quick (sloppy) check
>>> it seemed the same.
>>> If they are not: what to do? It depends on the
>>> precise meaning of HB_[U]LONG, which I'm not sure of.
>> Am I off the track too much if I say that current
>> HB_[U]LONG should really be called HB_VM[U]INT ?
>
> It should be rather HB_VMMAX[U]INT but VM may not support integer  
> values
> at all (i.e. CLIP does not use and integer items) so we may want to  
> define
> it as HB_MAX[U]INT and leave HB_VMMAX[U]INT rather for internal code  
> or for
> code which needs some strict compatibility with VM internals.
>
>> IOW this is the 'parnint'/'retnint'/'itemPutNInt'
>> value. Or is this something different?
>
> Yes, it is for above functions.
>
>> If this is so, first we should do this conversion
>> to make room for new meaning of HB_[U]LONG. Question
>> is how much 3rd parties will be affected.
>> Alternatively we should either drop "regular"
>> [U]LONG as core type, or find it another name,
>> (which won't be very easy).
>
> I would like to make such modification after final 2.0.
> I expect that it will introduce a lot of problems which can
> make Harbour unstable or unusable for months or even years
> so 1-st I would like to have stable branch with all current
> features which can used in production environment.
> Just simply we may not find enough developers to ever finish
> it and create good documentation for new types for 3-rd party
> developers so they can update their code.
> I added HB_WCHAR only for one reason. wchar_t is 16 bit integer
> in Windows and 32 bit integer in most of other systems and I need
> sth to hold Unicode values in portable way. I want to add before
> final 2.0 version set hb hb_item*Str*() functions to set/extract
> string values with automatic conversions between different encodings
> (CP char string, UTF8, U16, U16LE, ... ) so 3-rd party developers
> can start to write code which will be Unicode ready and later we
> can add support for UNICODE string items to HVM without any it will
> not be necessary to modify code adopted for new string API. I also
> want to replace current cdpapi.c code with new one which should
> resolve most important problems in current implementation. So if
> possible I wold like to ask you to not introduce any modification
> in existing types now. I'll try to finish and commit modifications
> in CDP API in this month so we can try to release finbal 2.0 in this
> year.
>
> best regards,
> Przemek
> _______________________________________________
> Harbour mailing list
> Harbour at harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour