On Tue, 1 Jul 2008, Florian Klaempfl wrote:
> Marco van de Voort wrote: > >> On Tue, 1 Jul 2008, Florian Klaempfl wrote: > >> > >>> I read most of the discussion and I think there is no way around a > >>> string type containing an encoding field. > >> [cut] > >> > >>> I know this approach contains some hacks and requires some work but I > >>> think this is the only way to solve things for once and ever. > >> I think it is the most promising and extensible proposal, > >> so I'm all for it. > > > > I read it shortly, and I still don't like it. I need more time to prepare a > > reponse though. > > Keep in mind in your response, that we want also handle other formats > than utf-8 or utf-16 if needed :) I think that if you put the encoding field at a negative offset, as length for ansistrings, that this code should be relatively compatible to current code if you assume that encoding=0 (or whatever tag value) means ansistring: You just have an extra field; you could even make that 2 fields: in addition to byte length, add character length: it should keep operations fast, as most conversions and other operations will end up with a character length of some kind anyway. Michael. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
