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@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
