[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    RE: Auto generation of A->W and W-> A conversions
From:       Patrik Stridvall <ps () leissner ! se>
Date:       2000-04-30 20:03:39
[Download RAW message or body]

> > For example. SHLWAPI has 150 (75 * 2) Path* function
> > that does simple string manipulation. 75 of these could
> > probably be generate using my generic mechanism.
> 
> >In fact, I think almost all SHLWAPI function would
> >work with the generic mechanism.
> Almost no function would work after this.

Without extending the "glue" syntax no,
but then this is only a quick hack.

> Most of the shlwapi functions are shorter than a A->W or 
> W->A conversion 

Indeed, see below.

> and many are having IN/OUT arguments
> (modifying the input buffer or 

Already supported (/* in/out */).

> returning a pointer to a place
> in this buffer) 

Can easiliy be supported, just
a matter of calculating offset.
See below.

> so it wont work and we really need 2
> implementations. 

The cases you describe are very easy to add support for.
We can do it like this for example.

LPSTR /* position:1 */ WINAPI PathCombineA(LPSTR /* out (MAX_PATH) */,
LPCTSTR /* in */, LPCTSTR /* in */);
void WINAPI PathQuoteSpacesA(LPSTR /* in/out (MAX_PATH) */);

> Only the TCHAR way (two times compiling) would work 
> with most of the shlwapi functions and would IMHO 
> really make sense here (nowhere else possibly).

Sure, I have been argueing for double compilation all the time.

Perhaps I should make it more clear, if somebody
didn't understand it I am not argueing for
double compilation as a solution to _all_ A <-> W
problems, but as _one_ of the tools we should use.

We should use do double compilation where
appropriate, automatic generation where appropriate,
and do it manually where appropriate,
perhaps we even should use Dimitrie's solution
somewhere.

The point is that one size doens't fit all,
we should first make the tools that are useful
and then we can discuss which tools that should
be used where.

The automatic generation have its place IMHO,
the question is how advanced we should make
the syntax.

In short, one size doesn't fit all, never have, never will.

[prev in list] [next in list] [prev in thread] [next in thread]