Is the C++ part of VisualC++ a misnomer?

[kbhat]

I am looking at some Visual C++ code and I am amazed at the number of
proprietary extensions to C++ that I am seeing. I even wonder if this
is the same language! I understand the need to have a graphics
library, but I don't see the rationale for tcin, tcout, tcerr,
tstring, _T, __int64, _tcscmp, _tcschr, _tcslen etc. The list could
go on and on. Does anyone know the background for all this? What was
the need to reinvent the wheel?

@@@@@ Does anyone know of a tool (e.g. perl script) that can clean up
the VisualC++ **** and convert it to ANSI C++ code? @@@@@

@@@@@ Will MSFT succeed in bulldozing everybody and getting these
proprietary extensions rolled into the proposed standard? @@@@@

Thanks,
Bhat

[Bo Persson]

kb***@kaxy.com wrote:
:: I am looking at some Visual C++ code and I am amazed at the number
:: of proprietary extensions to C++ that I am seeing. I even wonder
:: if this is the same language! I understand the need to have a
:: graphics library, but I don't see the rationale for tcin, tcout,
:: tcerr, tstring, _T, __int64, _tcscmp, _tcschr, _tcslen etc. The
:: list could go on and on. Does anyone know the background for all
:: this? What was the need to reinvent the wheel?

The C++ standard has nothing much to say about extensions, except that
names like _tcslen etc are reserved to the implementation. Supposedly
the implementation should use them for something. :-)

Most of these names are implementation specific macros, present only
if you include specific headers, like tchar.h. The idea is that you
should be able to write code that sort of works both for Windows 95/98
and Windows NT or later.

If you don't use these names, but write ISO C++ code, almost
everything works as expected. If you don't need the duality of the _t
things to try to support ancient OSs, just don't use them!

::
:: @@@@@ Does anyone know of a tool (e.g. perl script) that can clean
:: up the VisualC++ **** and convert it to ANSI C++ code? @@@@@

Not needed - just don't use what you don't like.

::
:: @@@@@ Will MSFT succeed in bulldozing everybody and getting these
:: proprietary extensions rolled into the proposed standard? @@@@@

No, but they have an entirely different standard working for them,
ECMA C++/CLI.

http://www.ecma-international.org/pu...s/Ecma-372.htm

Bo Persson

[Ben Rudiak-Gould]

Bo Persson wrote:

kb***@kaxy.com wrote:
:: I understand the need to have a
:: graphics library, but I don't see the rationale for tcin, tcout,
:: tcerr, tstring, _T, __int64, _tcscmp, _tcschr, _tcslen etc. The
:: list could go on and on. Does anyone know the background for all
:: this? What was the need to reinvent the wheel?

With the exception of __int64, these are all related to Unicode support. If
you use them, you can write your application to use either UTF-16 or a
locale-dependent MBCS encoding based on a compile-time #define.

If you don't need the duality of the _t
things to try to support ancient OSs, just don't use them!

If you don't use them, you have to choose between bytes and wide characters
for things like fopen(), and there's no reasonable choice. On Unix you
almost certainly want bytes; on Windows you almost certainly want wide
characters. Of course, the _t functions, being Windows-specific, are even
worse. It's a terrible situation. It wouldn't be a problem if Windows
supported UTF-8 as a locale encoding, but it doesn't, apparently because
locale encodings can't have code sequences more than two bytes long.

I think the best solution would be to standardize something like the _t
functions (and while I'm dreaming, it should work by overloading and
typedefs instead of #defines). Failing that, people should use a nonstandard
but portable wrapper library. Unfortunately, most people just use byte
strings, which is a major hassle for people like me who have filenames on
their Windows systems with characters outside the locale encoding.

-- Ben

[James Kanze]

On Nov 28, 9:42 pm, Ben Rudiak-Gould <[e-mail]:

Bo Persson wrote:

[e-mail] wrote:
:: I understand the need to have a
:: graphics library, but I don't see the rationale for tcin, tcout,
:: tcerr, tstring, _T, __int64, _tcscmp, _tcschr, _tcslen etc. The
:: list could go on and on. Does anyone know the background for all
:: this? What was the need to reinvent the wheel?

With the exception of __int64, these are all related to
Unicode support. If you use them, you can write your
application to use either UTF-16 or a locale-dependent MBCS
encoding based on a compile-time #define.

That is, of course, bullshit. The logic you use for UTF-16 will
have to be different than that you use for UTF-8, ISO 8859-1, or
whatever. For that matter, the logic you program will have to
be different for UTF-8 than for ISO 8859-1, even though they
will typically have the same type.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[John Scheldroup]

"Ben Rudiak-Gould" <br***********@cam.ac.ukwrote in message news:fi**********@gemini.csx.cam.ac.uk...

Bo Persson wrote:

>kb***@kaxy.com wrote:
:: I understand the need to have a
:: graphics library, but I don't see the rationale for tcin, tcout,
:: tcerr, tstring, _T, __int64, _tcscmp, _tcschr, _tcslen etc. The
:: list could go on and on. Does anyone know the background for all
:: this? What was the need to reinvent the wheel?

With the exception of __int64, these are all related to Unicode support. If you use them, you can write your application to use
either UTF-16 or a locale-dependent MBCS encoding based on a compile-time #define.

>If you don't need the duality of the _t things to try to support ancient OSs, just don't use them!

If you don't use them, you have to choose between bytes and wide characters for things like fopen(), and there's no reasonable
choice. On Unix you almost certainly want bytes; on Windows you almost certainly want wide characters. Of course, the _t
functions, being Windows-specific, are even worse. It's a terrible situation. It wouldn't be a problem if Windows supported UTF-8
as a locale encoding, but it doesn't, apparently because locale encodings can't have code sequences more than two bytes long.

I think the best solution would be to standardize something like the _t functions (and while I'm dreaming, it should work by
overloading and typedefs instead of #defines). Failing that, people should use a nonstandard but portable wrapper library.
Unfortunately, most people just use byte strings, which is a major hassle for people like me who have filenames on their Windows
systems with characters outside the locale encoding.

-- Ben

Thank you Ben that was interesting.

http://www.google.com/search?hl=en&q...=Google+Search

John