Re: Are _T() and TEXT() macros equivalent?
"David Wilkinson" <no-reply@effisols.com> wrote in message
news:%23xlayYofHHA.1008@TK2MSFTNGP05.phx.gbl...
Maybe, but actually the level of understanding of MBCS in CStringA is
extremely limited. For example, as we have discussed before, GetLength()
does not return the number of Unicode code points, or the the number of
glyphs, but rather the number of char's. Ironically, the main reason
CStringA needs to understand the code page is so it can be initialized
with a wide string :).
Yes, I haven't had to use any of the more esoteric featurs of Unicode that
essentially make it a Multi-byte language anyway. My clients have a
requirement to translate into Hebrew, Arabic, Japanese, Korean, etc. and all
I do is define UNICODE/_UNICODE and build away. I'm still sheletered in the
simplicity land.
When I see the rate of features being added to C#, features being taken
from the best of the dynamic languages, and compare it to the "any year
now" of C++, there's simply no comparison. C++ just can't keep up.
I think you are really talking .NET versus MFC here, not C# versus C++.
Surely most features of .NET are available in C++/CLI?
[I could be wrong here; I know very little about C# and .NET. I do know
that LINQ will not be available in C++/CLI, perhaps because it uses
partial classes.]
I was speaking of delegates, events, anonymous functions. I believe these
are specific to languages, not .NET, although .NET does expose primitives of
these types. WPF uses partial classes, I'm not sure about LINQ.
I have to say that I am afraid that C++/CLI, rather than being the savior
of C++ within Microsoft, could accelerate its demise. Firstly because it
reinforces C++'s reputation as a difficult language (C++/CLI really is a
difficult language...). And secondly because trying (with only partial
success) to keep up with .NET diverts resources from native code support.
Why do you say C++/CLI is a difficult language? There are some complicated
things in there but you do not have to use them for every day programming.
The main reason C++ is in demise is because Microsoft gave up on using it to
develop .NET programs from scratch, leaving them the only place to go is to
use it to extend existing native C++ programs with .NET features. This is a
worthy goal, but it makes C++/CLI used only in legacy situations. Of
course, people do still start new C++ projects, so I guess these would
benefit as well, although the number of people doing this is vastly
decreasing.
-- David