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

 

[Alf P. Steinbach]

* (e-mail address removed):

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?

Short of it is, you don't have to use it.

The "t" family of macros was a misguided attempt to bridge the gap
between two families of operating systems (win16 and win32).

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

Simply don't use the extensions.

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

This is a good question.

MS has made a serious attempt to have one set of extensions (C++ for
managed environments) standardized. In such code you'll see "^" and
other funny stuff. I think they managed to established an ECMA/ISO
standard for that, but it's not part of standard C++.

Funny note: in 1995, with the introduction of 32-bit Windows (Windows
95) for the masses, Microsoft had ECMA standardize the Win16 API.
Doesn't directly have anything to do with C++, though. Just an example
that standardization doesn't mean much in itself.

Cheers, & hth.,

- Alf

 

[Bo Persson]

(e-mail address removed) 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/publications/standards/Ecma-372.htm



Bo Persson

 

[Ben Rudiak-Gould]

(e-mail address removed) 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

 

[Ramon F Herrera]

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

Fortunately, the Microsoft predator seems to have changed their
attention (A.D.D.?)

They abused, raped & pillaged in the C++ world, but now they are doing
that to Java.

-Ramon

 

[James Kanze]

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.

 

[John Scheldroup]

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 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=21+unicode+win+xp&btnG=Google+Search

John