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
