Re: Are _T() and TEXT() macros equivalent?
On Mon, 16 Apr 2007 03:59:04 GMT, "David Ching" <dc@remove-this.dcsoft.com>
wrote:
The assertion was "every single application developed in that language for
the last 30 years". Hello World is a part of that.
My point was that you gave a trivial, inconsequential counter-example to
what Mihai stated and then immediately followed it up by talking about
"many modern apps". If you really want to play the absolute technical
correctness game, this is not a counter-example, because "Hello, world"
uses a runtime to which Mihai's assertion certainly applies. Even speaking
informally, there is far more truth in what Mihai said than overstatement,
and in any event, "Hello, world" is not representative in any way of "many
modern apps".
And you must have
missed my reply about my point being many programs don't store binary things
in char arrays and only manipulate arrays of characters as strings, so they
are not concerned if a char takes 1 byte or 100.
Most every program that calls fwrite, _write, ostream::write, etc in effect
does exactly that. It seems only fair, since the language defines an object
of type T in terms of a "sequence of N unsigned char objects, where N
equals sizeof(T)". The second example in my last message used this fact.
Sorry if you thought I was mocking. If I came across that way, it's because
it sounds ludicrous to me that you promote sizeof(char) == 1 to be on the
same level that "all C++ implementations must recognize the keyword
'class'", which is what I would consider "fundamental". But I've found it
is a trait of C++ people to easily lose the forest from the trees.
Well, there you go again. Your statements have clearly demonstrated that
you do not understand the object model the language defines, yet you are
again projecting a deficiency onto those who do know the language, right
after pseudo-apologizing politician-style for doing the same thing earlier.
Nice.
I proposed that, yes. But what you don't get (even though I've said it
several times to several people)
Sorry, I don't read all your posts; there are far too many in this thread
alone. If you said that in a reply to me, I apologize for missing it.
is that the "/unicode" switch can be turned
off or on at will. If it turns out a module makes liberal use of
sizeof(char) == 1, then by all means disable /unicode and don't change a
thing.
If you think it's such a great idea, develop it. By that I mean list the
various ramifications of using and not using the switch. Among *many* other
things, you'll need to define "module". Whether you appreciate it or not,
it is important. As for determining whether or not a body of code makes
"liberal use" of this fact that you hate, the only sane approach is to
assume all existing code does until proven otherwise, line by line. You
can't just glance at it and proclaim it "/unicode-compatible". Finally, you
should talk about why the current approach using TCHAR is inadequate, and
why a switch that makes a sea change in the language definition that
amounts to turning char into TCHAR is necessary to address it.
If you are at all serious about convincing people
who know the language, you should:
1. Go through the standard and list the sections that use char as byte.
2. Collect and present the ways programs make use of (1).
3. Describe the transformations that would be necessary to fix (2) after
changing (1).
4. Describe the difficulty and degree of automation possible to implement
(3).
5. Show why it's worth it to require updating 35+ years of C and 20+ years
of C++ code to conform to the new language.
6. Present your proposal in groups such as comp.std.c++, where you will
find many more language experts than you will here,
And because the compiler supports both /unicode and not, none of these
points are relevant.
Actually, they are, because you need to do all that to help you (a)
determine whether or not code makes "liberal use" of this fact that you
hate, and (b) define the limitations and consequences of your new switch.
Some of the many things you need to think about are separate compilation
and linkage, the effect of applying the switch in code that uses header
files for libraries that were compiled using a different setting for the
switch, etc etc etc.
And no, I am not at all serious about making it my career to change the
minds of those who hang out at comp.std.c++. I can see we have different
goals and values for our lives.
Judging by how passionately and endlessly you've been arguing this, I
thought you might also consider it worth your while to learn how to argue
it seriously and meaningfully. I guess I was mistaken, because there you go
with another sarcastic comment.
Myself, I'd prefer the language to have separate byte and char types, but
I
also know this would not be an easy thing to change. Here, I'll give a
brief example using my numbering system above:
2. Problem
char* strdup(const char* s)
{
size_t len = strlen(s);
char* res = (char*) malloc(len+1);
return strcpy(res, s);
}
3. Fix
char* strdup(const char* s)
{
size_t len = strlen(s);
char* res = (char*) malloc((len+1)*sizeof(char));
return strcpy(res, s);
}
4. To automate this, a program would have to be written that recognizes
that malloc is being used to allocate space for a char array. Moreover, it
would have to recognize this across function calls, translation units, and
even libraries. This program will not be written, so it will be up to
people to do this by hand.
This example is outdated. Here's how you would write strdup with modern C++
and not have to change a thing:
char* strdup(const char* s)
{
size_t len = strlen(s);
char* res = new char[len+1];
return strcpy(res, s);
}
Millions and millions of lines of code are similarly "outdated". It doesn't
make them any less legal than shiny new code. Your "fix" introduces C++
exceptions into a C function and requires the returned pointer to be freed
with delete[] instead of free(). Those changes have some pretty broad
ramifications. For the sake of argument, suppose this belongs to a "module"
that makes "liberal use" of this fact that you hate, so you wouldn't apply
your /unicode switch to it. What does this imply for "modules" that do use
your /unicode switch and want to use strdup? What does it mean to see the
type "char" in documentation?
/unicode would not be compiled for this function, or the write() function
that takes a char parameter (not shown).
Oh jeez, you're actually suggesting it. Again, how are "char" parameters
going to be interpreted by a file that #includes their headers but is
compiled with your /unicode switch and so changes the meaning of the
keyword "char"?
Note that part (2) of both examples I presented would compile OK under
your
hypothetical new language, and they would both lead to buffer overruns.
Not if /unicode were not specified (as it would not be by default).
If it's optional, why don't you just leave the language alone and use
wchar_t instead of char when you want to program with wide characters? If
it's important to control it with a switch, why not just use TCHAR, which
is a macro everyone knows is and always has been controlled by a switch?
Why the fixation on basing the meaning of the keyword "char" on a compiler
switch and creating a new language that changes the meaning of existing
code when the switch is active?
No doubt, this is just scratching the surface. It's what I could think of
immediately without really trying. To do a reasonably thorough job of part
(2), you would need to pose the question to a great number of people
(easy)
and get them to think about it long and hard and answer you (not as easy).
You'd also need to survey millions of lines of code written in every area
people use the language. I haven't done that, of course, but I would have
to conclude, based on my knowledge of the language and experience using
it,
that you would be creating a brand new language. I say this because
existing code would not be portable to it, and no one would find it
worthwhile to update their code to use it, because using char as byte and
wchar_t or even TCHAR as "character" works well enough.
Well, let me sum it up once more, and then I am done with this whole topic,
because I have already spent too much time on it.
1. /unicode is purely optional to use, so it doesn't break any existing
code.
I guess that's trivially true, because if everyone opts out, everything
will remain OK. Of course, /unicode pioneers will have to deal with the
things I've discussed.
2. If it is the opinion that "wchar_t and TCHAR as character works well
enough" then ease of use simply isn't valued and there is nothing more to
say.
What I've been trying to get across to you is that there is more to
consider here than that.
3. This attitude carries far beyond wchar_t and TCHAR, creating montrosities
like STL, Boost, misused pure virtual functions, and other things that
incite religious fervor. It's been enlightening to see how people
supporting these things actually think.
And there you go again. The "religious fervor" has been found in your
rejection of various things out of hand, such as your frequently expressed
disdain for all things STL (some parts of which are actually very good),
protestations concerning language fundamentals, arguing endlessly after one
of your misstatements is corrected, etc, etc, etc. I hope you realize, you
may not be the only one being enlightened here.
This whole thread started out as how the current C++ makes unoptimal life as
a C++ programmer on Windows, especially as compared with more modern
languages. Judging from the attitude shown here, this will likely continue,
and we as Windows programmers will plan accordingly.
Who's "we"? There have been at least three Windows programmers trying to
explain to you why you're fixating on a non-starter of an idea. What I've
gotten from your last post is that you seem to think "optional" means
consequence-free, but that's true only if everyone opts out.
--
Doug Harrison
Visual C++ MVP