From: "Patrik Stridvall" <[EMAIL PROTECTED]>
> What I meant is that _every_ such function need to now about
> _every_ supported encoding, so you can't just add new encodings
> just like that, unless you have an very advanced and likely
> ineffiecient scheme.
Well, this is not a concern -- there are relativly few encodings, and
having knowladge to convert back and forth between them is not
a big deal. Besides, we encapsulate that knowladge in these
string conversion functions, so it is a Good Thing.
> Note that you need more functions like
> HEAP_strcatXandYtoZ(int enc1, LPSTR str1,
> int enc2, LPSTR str2, int *unified_enc);
> if you want to be able to concatate string without
> having to convert to a common format and you will need
> HEAP_strcmpXandY(int enc1, LPSTR str1,
> int enc2, LPSTR str2);
> as well and probably others as well.
Maybe, but:
-- we need not go to such extremes
-- most of the cases are simple and we can gain a lot
from this functions alone.
I am not interested to cover ALL cases. Sometimes, it may be simpler
to convert to an internal format (say UTF16 or UTF8) and work with that.
[...]
> > No, it doesn't. In fact, if the input is streight ASCII, we need not
> > worry because in most cases we deal with UTF8 which is
> > compatible with ASCII. So for the common case, we are as
> > fast as we can be (ignoring the very small overhead of carring
> > the encoding around).
>
> Even if HEAP_strdupXtoUTF8(ASCII, str) did nothing,
> you still have the overhead caused by
> 1. Extra function call to HEAP_strdupXtoUTF8
> 2. Extra memory allocation. And no, you can't just pass the
> same string since somebody will do HeapFree later.
I am sure we can no something about that. We can have the most
semnificant bit in the encoding byte
0 -- if this is a string that we got from the user
1 -- if this is a temporary string that we allocated, that needs
dealocation before we return...
We can do something about it, I am not too worried.
> Furthermore your solution will require close to every
> function dealing with string to be rewritten.
Any solution will, since most things are implemented W -> A now.
> > > My prefered solution is that have a common
> > > c file and compile it several times with different
> > > defines for each format that needs to be supported.
> >
> > Hmm, I don't like this either -- I agree with Alexandre on this one.
>
> I see, mind if I ask why?
> I really can't see what is so bad with my solution,
> in comparision with your or the current solution.
It is mostly a gut feeling, but:
-- way too much bloat. I understand loading things on demand,
and such, but still
-- I think we need more control than just trying to reocomplile
multiple times. We'll end up with #ifdef all over the place.
It is true, your solution is (in some sense, and in theory) a bit cleaner
and
a bit more efficient than mine. But, I think the bloat is too much for the
_little_ price I am asking -- carring a int around. Moreover, I think that
in
practice your solution is not going to be neither cleaner nor more
efficient.
--
Dimi.
