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

Discussion in 'C++' started by kbhat@kaxy.com, Nov 28, 2007.

  1. Guest

    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
    , Nov 28, 2007
    #1
    1. Advertising

  2. * :
    > 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

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Nov 28, 2007
    #2
    1. Advertising

  3. Bo Persson Guest

    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
    Bo Persson, Nov 28, 2007
    #3
  4. Bo Persson wrote:
    > 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
    Ben Rudiak-Gould, Nov 28, 2007
    #4
  5. On Nov 28, 1:39 pm, 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?
    >
    > @@@@@ 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
    Ramon F Herrera, Nov 29, 2007
    #5
  6. James Kanze Guest

    On Nov 28, 9:42 pm, Ben Rudiak-Gould <> wrote:
    > Bo Persson wrote:
    > > 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Nov 29, 2007
    #6
  7. "Ben Rudiak-Gould" <> wrote in message news:fikjr6$n34$...
    > Bo Persson wrote:
    >> 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=21 unicode win xp&btnG=Google Search

    John
    John Scheldroup, Nov 29, 2007
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. KK
    Replies:
    1
    Views:
    1,902
    Richard Grimes [MVP]
    Jul 2, 2003
  2. Christian
    Replies:
    1
    Views:
    555
    Vinay Doma
    Jul 22, 2003
  3. Carlo Milanesi

    Isn't 'vector' a misnomer?

    Carlo Milanesi, Nov 13, 2003, in forum: C++
    Replies:
    19
    Views:
    507
    Mike Wahler
    Nov 21, 2003
  4. Ben Finney
    Replies:
    2
    Views:
    427
    Peter Hansen
    Jul 12, 2003
  5. Tim Peters
    Replies:
    2
    Views:
    776
    Ben Finney
    Jul 13, 2003
Loading...

Share This Page