[I, forwarded it to the list, since I don't believe you meant
it as a private mail]
> From: "Patrik Stridvall" <[EMAIL PROTECTED]>
>
> > The only way your solution can be justified is in terms of
> > efficiency, it sucks for debugging and readabillity as Marcus
> > pointed out.
>
> Look, I am not in love with my solution. :) It has its problems,
> I agree, I just hate the current situation.
Talking about overstatement isn't hate that as well.
The currently solution is slow, but at least it works
and is obviously correct.
> That being said,
> I think it is an overstatement to say that it sucks on
> readability. Really.
OK, sucks was a bit strong, sorry.
What I mean is that the the extra int makes the code less readable.
> Debugging can be a bit more problematic,
> I agree, but support for this sort of thing can easily be built
> into the debugger, so you will not see much difference.
Which debugger? Ultimately we want to run gdb as often as possible,
not the internal debugger.
> > > > > > 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 understand where you are going. I admit that I can
> not articulate my gut feeling why I have reservations about it.
I must admit, that I'm a little worried that somebody will find
some serious flaw with it, but so far I haven't been able to
do so myself, so I can understand your gut feeling.
One problem, that I recently realize is that the interal
format can't use TCHAR, LPTSTR etc since it might not be
the same as the "external". This can perhaps be solved
by using UTF16 (WCHAR, LPWSTR) as the internal format
and for the ANSI only case do #define WCHAR CHAR as a hack.
In any case it still avoid the A->W->U transition
that you don't like, in all cases except when
one API does A->W and stores it internally,
and a second API does W->U on the internally
stored string but that is the problem with your
solution as well, unless you store the encoding
format internally.
Perhaps we could use XCHAR, LPXSTR (or ICHAR, LPISTR)
for the internal format instead. But then ASCII (with no W functions)
or UTF16 (both A and W functions) is probably enough.
Beside using UTF8 or whatever as the internal format might
cause compabillity problem. Anyway internally stored strings
are probably more likely to be given back the application
which expect ASCII or UTF16 than to some Unix librarary which
expects UTF8 or whatever.
> And you may be right that it will probably work. The only difference
> between my solution and yours is that what I am doing at runtime,
> you are doing at compile time.
That is almost true. In the compiled code yes, but in the source code
you have to explicitly do things I can get the compiler to do automatically.
> That's why yours may be faster.
> However, if you have two apps running (one ASCII, and one Unicode),
> I am no longer sure yours will be faster.
All applications running under the same Wine server will
share the same internal format, so that is not a problem.
Windows also does it that way.
Sure string that are stored internally much be converted
if the format is not the same but that is unavoidable
with any solution.
String that are just passed to a Unix library need only
be converted if the libary doesn't use the same format,
but that is also unavoidable with any solution.
> Actually, I think it will be
> slower.
AFAIU my solution is theoretically optimal, speedwise.
> The real advantage of your solution is the cleaner code.
Well, if you wish to be able to support _any_ internal
string format you will get some bloat, but I think
UTF16 (which ANSI only as a hack) will do nicely.
As I said an internally stored string are less probable
to be pass to a Unix library than to the application.
> But then again, I do not think mine will add much clutter either.
Clutterwise, I think that it goes without saying that your solution
has more clutter than mine or the current one.
As to whether it is too much can of course be discussed.
> So, it is a judgement call. From my point of view, any will do.
> The question is, is any of them acceptable?
Alexandre has already rejected mine.
I hope he will reconsider, but you never know.
Personally I don't really like your solution,
I have a gut feeling that we might regret it
in the future, and no I can't really can't
say exactly why.
