> > Yes, it is easy, but there is a lot of effort for little
> gain -- in the end,
> > we only really support ASCII, and on top of it, we do it in
> a slow and
> > inefficient manner (let alone ugly).
>
> No, we don't.
Yes, we do (support only ASCII).
I think he is refering to the cases where the UNICODE function
calls the ASCII function, there are a lot of those IIRC.
BTW, should I add a test to winapi_check that check for
these kind of call. I already have (off by default) an
option that check for cases where the 32-bit variant
calls the 16-bit variant.
> What we do is slow. And inefficient. Yes.
>
> But it is easy to handle and to debug.
True. That is worth a lot.
> And since we are still in ALPHA state and those W<->A
> conversion are one
> of the smaller bottlenecks I think "easy to handle and to
> debug" counts more
> than a bit more speed and efficency.
As I short term solution, I agree.
We have much worse problems than performance.
But I'm not sure it is a good long term solution.
> > > But there is nothing stopping a slow migration from W->A
> conversions into
> > > A->W conversions everywhere.
> >
> > Somehow, I don't think working with W is the right thing to
> do in Unix.
>
> glibc-2.2 will have a nearly complete set of wide character functions,
> the whole other Linux stuff is going the UNICODE way too. QT2
> has it, KDE2
> will have it.
Sure of course we should support UNICODE, but the real question
is that if it is good the penalize the, at least today,
much more common ASCII case.
> > 2. [lazy] remember the encoding that the strings are in,
> and pass that
> > around until we actually need a specific encoding
>
> This is bad from a programming point of view. This adds bloat and you
> have two possible code paths and duplication. You can't test
> both cases
> easily.
Yes, that is a problem with lazy evalution.
Good that you mentioned it, I had forgotten.
As a side note: Programming languages like Haskell that
has lazy evalution are real nice until you need to debug
the application...
