Re: Are _T() and TEXT() macros equivalent?
"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message
news:Xns990D9F97AC07BMihaiN@207.46.248.16...
And I think it was explained at the time that it would be non-standard
compliant :-)
That's my point. If Microsoft is serious about improving native C++ Windows
development, they'll make some sacrifices with being standard compliant.
But they've shown no interest in doing that, and in fact are touting their
future releases as being even more standard compliant. That's why I'm
making the case that C++ is not now, and will be even less so in the future,
the optimum way of creating Windows apps. As someone who's devoted my
career to writing Windows apps in C++, this is not to my liking at all.
As a platform creator (as MS is) you have two options when things evolve:
- Redesign the whole thing "clean and nice". This takes a lot of
resources,
and will break a lot of things developed by 3rd party.
- Patch things to make it work, in the same time keeping compatibility.
There is no need to read the history to use the stuff. But is nice to
read it, so that you can understand why the crap is crap.
Sure, in fact I applaud their backwards compatibility and am screaming as
loud as anyone else about how Vista does a less good job of retaining
backwards compatibility. The mess they made about default file extensions,
the manifest, etc. are examples. OTOH, even this is not as bad as the
laughingstock of Java 2 (which was not compatible with Java 1). So yes,
backwards compatibility is important.
I agree with understanding history, and since I was there, delight it
telling that history just like you do. But there is a myopia here that the
way it's been done before is the way to keep going, and I don't like what
Microsoft is saying is their future directions of C++.
Don't you have any code that you wrote 10 years ago that now you would do
differenty? And would it not be nice to be able to explain to somebody
reading your code today and judging you why is so crapy, what where the
restrictions and the reasons at the time?
There's a difference between genuine breakthroughs in paradyms and patterns
(such as supporting delegates and anonymous methods) and just plain
sloppiness (like having both _T and TEXT macros which do the same thing, but
for different Windows subsystems) that are the result of someone not doing
their job at Microsoft. I'm proud that when I go back through most of my
code now, there is a naiveness to it but it is still clean and well
readable.
There are already compatibility problems between .NET 1.1 and 2.0
Wait 10-20 years and let's see then how clean .NET will look like :-)
True, and the dispicable state of deterministic finalization that was hacked
in at the last minute, and the misunderstanding how how to handle exceptions
are (rare) examples of that. But I hold more hope for .NET, since their
values of simplicity from the ground up just have more common sense in
general. At least we can always hope. ;)
-- David