> Excuse me.... since when did this list turn into the
> linux-kernel mailing
> list??? (And I'm gonna add to it.. crap)
I don't think we are there quite yet. :-)
> Double compilation is just plain nuts (sorry Patrick).
No need to apoligize. You are entitled to your opinion.
I am well aware of the drawbacks, I just happend to
believe that the PROS outweigh the CONS.
> Sure
> it doesn't have
> to run that conversion, but compiling every source file 3 times (or
> whatever) does not sound like my idea of fun. And
> furthermore, you have
> that many times as much object code, which is taking up
> memory.
Only functions that has both a A and a W variant needs to
be compiled twice. Granted there is quite a lot of them.
> Worse yet,
> it makes the source file look ugly as hell.
That I definitely do not agree with. What is wrong
with using TCHAR, LPTCHAR and friend insteed of
CHAR and LPSTR. OK, there might be a few extra UNICODE
some where, but I don't think they will be that many.
But nevermind, I don't think it is worth wasting
more time arguing about it...
> So... let's see.. how much processing time did we waste going from
> ASCII->Unicode->UTF8... hmmmm.... 2*N (where N is number of
> characters).
> I think I can live with that. Hell, I'd even be willing to
> live with more
> than that.
... so lets instead concentrate on making the currently
used solution as fast and maintainable as possible.
As to fast I really don't have any idea except for
obious ones like using alloca and allocate on the
stack whenever possible.
Whatever we decide on almost all conversion functions will
be the same so it might be benefical to automatically
generate them.
Perhaps is the spec files something like:
@ convert FooA(str) FooW
@ stdcall FooW(wtr) FooW
Which will generate
DWORD WINAPI FooA(LPSTR str)
{
LPWSTR wstr = HEAP_strdupAtoW(str);
DWORD dwResult = FooW(wstr);
HeapFree(wstr);
return dwResult;
}
or whatever we agree is the most correct and/or efficient.
One problem is that there are functions that don't use zero
termininated strings. But perhaps we could mark them somehow
with * or something, like:
@ convert BarA(str*long) BarW
@ stdcall BarW(wtr*long) BarW
Which will generate
DWORD WINAPI BarA(LPSTR str, INT length)
{
LPWSTR wstr = HEAP_strndupAtoW(str, length);
DWORD dwResult = FooW(wstr, length);
HeapFree(wstr);
return dwResult;
}
Another problem is that the spec files do not specify
the return type, but perhaps using DWORD will do.
It will not work for 64-bit returns, but then we can
simply forbid auto conversion for them, they are few
anyway.
Comments?
