> Patrik Stridvall <psÉleissner.se> writes:
> 
> > Do you consider an Windows _application_ that can be 
> compiled as both ASCII
> > and Unicode as less maintainable?
> 
> Yes; it all looks very nice in theory, but when you try to deal with
> real life problems, like file I/O for instance, this TCHAR magic is a
> pain, and you end up with #ifdef UNICODE all over the place.

Granted file I/O is a pain in Unicode, if you have a file format
common with the ASCII version, which you almost alway have.

But it is not really a failure of the TCHAR magic,
if you wrote an ASCII application that used a Unicode
file format use would suffer almost the same pain.

Sure, the fact that we store need to store some strings
internally has some of the same problems but they not
at all that severe. I'm not even sure we will get
any #ifdef UNICODE at all in the code. Of course
the help macros/function must of course use them
in the headers, but that is very isolated.

> > > Embedded systems may want Unicode too (CE is mostly 
> Unicode AFAIK).
> > 
> > Sure you can run Unicode only if you wish.
> 
> No; most typical apps need a mix of the two, because you want Unicode
> when dealing with the user interface so that you can support multiple
> languages, but you don't want to convert your whole app to use Unicode
> internally where it's not necessary.

Most typical applications, would perhaps be better of if they did,
but the Windows headers files doesn't really support mixed 
ASCII/Unicode application, so I wonder how many application
like that really exists.

Anyway, I just realized one thing. Look at these Makefile directives

.c.ascii.c :
        $(BUILD) @BUILDFLAGS@ -o $@ -ascii $<

.c.unicode.c :
        $(BUILD) @BUILDFLAGS@ -o $@ -unicode $<

In theory each directive could do anything
it wanted the input file.

This mean that we in theory could support with compile options
(1) W->A with auto generated conversions (pseudo Unicode support)
(2) A->W with auto generated conversions (your proposal)
(3) Double compilation (my proposal)
(4) A only
(5) W only

Sure the input files will need to use TCHAR and friends,
but they will use just as much memory as they do now
if we compile with option (2).

What do you think?

Reply via email to