STL annoyances

Discussion in 'C++' started by Dann Corbit, May 26, 2010.

  1. Dann Corbit

    Dann Corbit Guest

    How is it that the STL (which is part of the standard) can be so utterly
    incompatible between various compilers?

    For instance, with Microsoft VC++, to include functional, the
    surrounding namespace is cliext. But with g++, the namespace is tr1.

    If compilers can change the namespace willy-nilly, then it's not a
    standard at all. Do these different compiler vendors really not realize
    that they are using different namespaces?

    In addition, unordered_map may or may not be present. Hasn't
    unordered_map been around for a long time now? It seems like the days
    when the only place to get an implementation of the STL was stlport were
    better because at least it was the same. Now (to quote Forrest Gump),
    the STL is like a box of chocolates. You never know what you are going
    to get.
     
    Dann Corbit, May 26, 2010
    #1
    1. Advertising

  2. Dann Corbit

    Öö Tiib Guest

    On 26 mai, 23:28, Dann Corbit <> wrote:
    > How is it that the STL (which is part of the standard) can be so utterly
    > incompatible between various compilers?
    >
    > For instance, with Microsoft VC++, to include functional, the
    > surrounding namespace is cliext.  But with g++, the namespace is tr1.


    Things like cliext::vector are for MS language C++/CLI. C++/CLI is not
    C++. It looks from a far a bit like C++ but closer look reveals it is
    undead being.

    MSVC++ with zombie mode turned off has std::tr1 namespace like g++.

    [...]

    > In addition, unordered_map may or may not be present.


    Like others have said the things are not in standard. Current standard
    is from 2003 and will be standard for few years more. If you want the
    code you write to be portable use things that are strictly in std
    namespace or use boost. "boost" is 3 letters less to type than
    "std::tr1". As for std, read standard for help, real implementations
    contain always non-standard extensions.

    As for all new things ... the compiler vendors specially screw around
    with these to troll you into writing non-portable code until standard
    comes out. It has been always like that, nothing new there. MS has
    created even that C++/CLI to screw with peoples brains.
     
    Öö Tiib, May 26, 2010
    #2
    1. Advertising

  3. Dann Corbit

    Dann Corbit Guest

    In article <39864029-51f1-4a24-87b6-
    >, says...
    >
    > On 26 mai, 23:28, Dann Corbit <> wrote:
    > > How is it that the STL (which is part of the standard) can be so utterly
    > > incompatible between various compilers?
    > >
    > > For instance, with Microsoft VC++, to include functional, the
    > > surrounding namespace is cliext.  But with g++, the namespace is tr1.

    >
    > Things like cliext::vector are for MS language C++/CLI. C++/CLI is not
    > C++. It looks from a far a bit like C++ but closer look reveals it is
    > undead being.
    >
    > MSVC++ with zombie mode turned off has std::tr1 namespace like g++.


    How do I turn off "zombie mode"?
    [snip]
     
    Dann Corbit, May 26, 2010
    #3
  4. Dann Corbit

    Öö Tiib Guest

    On 27 mai, 00:07, Dann Corbit <> wrote:
    > How do I turn off "zombie mode"?
    > [snip]


    Depends on version of MSVC, since it started from 2003 and 2003 looks
    really different than 2010 ..., but usually it means that any and all
    project settings that are "managed" or "common language runtime" must
    be "No" and "Off" and "Don't use". Be native, unmanaged and free. MSVC
    itself is quite decent C++ compiler.
     
    Öö Tiib, May 26, 2010
    #4
  5. Dann Corbit

    Öö Tiib Guest

    On 27 mai, 00:01, "Leigh Johnston" <> wrote:
    > "Öö Tiib" <> wrote in message
    >
    > > MSVC++ with zombie mode turned off has std::tr1 namespace like g++.

    >
    > VC++ and g++ have different directories for tr1 headers (<type_traits>
    > compared to <tr1/type_traits>) so it is not just a namespace issue.


    Nor is it only directory issue. It is all about little differences and
    incompatibilities how compiler vendors show off and trump each other.
    I basically agree with your "transient aberration" assessment. I only
    said above to show that real C++ with MSVC has std::tr1 namespace, not
    a cliext or some such that OP mentioned.
     
    Öö Tiib, May 26, 2010
    #5
  6. Dann Corbit <> wrote:
    > How is it that the STL (which is part of the standard) can be so utterly
    > incompatible between various compilers?
    >
    > For instance, with Microsoft VC++, to include functional, the
    > surrounding namespace is cliext. But with g++, the namespace is tr1.


    Do you know what the 'S' in "STL" stands for? And did you know that TR1
    is not yet part of it?

    > In addition, unordered_map may or may not be present. Hasn't
    > unordered_map been around for a long time now?


    No. It's not standard C++. Yet.
     
    Juha Nieminen, May 27, 2010
    #6
  7. Dann Corbit

    SG Guest

    On 26 Mai, 22:33, Pete Becker wrote:
    > On 2010-05-26 10:28:34 -1000, Dann Corbit said:
    >
    > > How is it that the STL (which is part of the standard) can be
    > > so utterly incompatible between various compilers?

    >
    > > For instance, with Microsoft VC++, to include functional, the
    > > surrounding namespace is cliext.  But with g++, the namespace
    > > is tr1.

    >
    > functional is not yet part of the C++ standard.


    What "functional" are you guys talking about? From what I can tell C+
    +03 *does* offer a <functional> header. Are you referring to the TR1
    extensions?

    > [...]
    > That difference goes away if you set your include paths right


    What *is* right?
    Does TR1 even mention how to "correctly" include the headers? As far
    as I remember it doesn't. Please correct me if I'm wrong.

    GCC's documentation ( see http://gcc.gnu.org/onlinedocs/libstdc /manual/bk01pt01ch03s02.html
    ) lists the TR1 headers as "tr1/something" where "something" is a
    placeholder for array, regex, type_traits, etc. I didn't notice any
    statement of the form "you can set your include paths so and so to be
    able to include the TR1 headers like they are supposed to be
    included".

    The way I see it: TR1 failed to specify how the headers should be
    included. That's a big fail, IMHO.

    Cheers,
    SG
     
    SG, May 27, 2010
    #7
  8. Dann Corbit

    Jorgen Grahn Guest

    On Wed, 2010-05-26, Stuart Golodetz wrote:
    > Öö Tiib wrote:

    ....
    >> Things like cliext::vector are for MS language C++/CLI. C++/CLI is not
    >> C++. It looks from a far a bit like C++ but closer look reveals it is
    >> undead being.

    ....

    > I don't personally use C++/CLI, because I'm not trying to write .NET
    > code (and if I was, I'd be more likely to use C#) but I don't really see
    > what the problem is with it existing.


    It's a problem if it has "C++" in its name and yet isn't C++. We don't
    want to repeat the Pascal fiasco.

    I don't know if it's true because I don't use it either, but the
    Wikipedia article looks pretty bad. Although I seem to recall
    something called "Managed C++" which was far worse.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, May 27, 2010
    #8
  9. Dann Corbit

    Öö Tiib Guest

    On 27 mai, 01:12, Stuart Golodetz
    <> wrote:
    > Öö Tiib wrote:
    >
    > > As for all new things ... the compiler vendors specially screw around
    > > with these to troll you into writing non-portable code until standard
    > > comes out. It has been always like that, nothing new there. MS has
    > > created even that C++/CLI to screw with peoples brains.

    >
    > I don't personally use C++/CLI, because I'm not trying to write .NET
    > code (and if I was, I'd be more likely to use C#) but I don't really see
    > what the problem is with it existing. As far as I understand it, the
    > basic issue is that normal (unmanaged) C++ doesn't integrate with .NET.
    > C++/CLI exists purely to be a language (dialect?) that looks "sort of
    > like C++" and does integrate with .NET. It's merely a solution to a
    > problem that MS have and that people who write in normal C++ (like us)
    > by and large don't care about. Since MSVC's support for normal C++ is
    > pretty good on the whole (and, in particular, not adversely affected by
    > the work they put into C++/CLI), I don't see an issue.


    MS did it well that designed their own clone of java virtual machine
    (.NET). Sun was really acting like on brakes with any improvements to
    it.

    C++/CLI however is not a variant of C++ that compiles C++ for
    that .NET engine. C++/CLI is a different language that is designed
    based on C++.

    The problem is that that design adds duplicate features to language.
    In C++/CLI you can use both generics and templates as mix, have both
    finalizers and destructors and piles of new non-standard keywords.
    Result feels like a monster beyond repair. About as bad as PL-1 was.
    It is confusing and scaring new people away from C++. That itself may
    be desirable for Microsoft ... C++ is too portable a language thanks
    to things like boost, QT, SDL and so on.

    Herb Sutter's writings do not matter, he is working for MicroSoft and
    so has to behave like an architect working there.
     
    Öö Tiib, May 27, 2010
    #9
  10. Dann Corbit

    John H. Guest

    Leigh Johnston wrote:
    > Yes and what happens to all that client code using the std::tr1 namespace
    > once c++0x is released and compilers are upgraded? Will std::tr1 hang
    > around to avoid rewrites?


    If MSVC++ 10 is any hint at what might happen, it currently accepts
    both.
     
    John H., May 27, 2010
    #10
  11. "Leigh Johnston" <> writes:

    > g++ is a widely used compiler and the default installation does not
    > add tr1 to the include paths, this is pants and a transient
    > aberration.


    I have not used tr1 that much, but isn't what you are calling an
    aberration here actually a Good Thing? IIUC, tr1 not only introduces
    new headers but actually supplements (i.e., /changes/) existing std
    headers. Isn't it, in fact, a gain to be able to *choose* whether these
    additions are available or not? As I see it, a compiler that merely
    makes tr1 available without special inclusion (such as the default use
    of #include <tr1/...> in gcc) is taking choice away from the
    programmer. It starts to feel a little like "extensions that you can't
    turn off."

    Regards

    Paul Bibbings
     
    Paul Bibbings, May 28, 2010
    #11
  12. Dann Corbit

    Öö Tiib Guest

    On 27 mai, 23:43, Stuart Golodetz
    <> wrote:
    >
    > C++ is concerned with writing 'to
    > the metal' code (don't pay for anything you don't use) and .NET is
    > (among other things) more concerned with helping you write safer code in
    > multiple languages.


    What is the feature of CLR for what C++ language must be extended or
    reduced or modified significantly (or in fact at all)? Garbage
    collection has been present long time and it has been used effectively
    even in C projects. MS did want to improve the language, but i know no
    one who likes the result.

    > As to scaring people away from C++ - it's surely not beyond people to
    > tell the difference between the two languages. If it is, they'd probably
    > make horrible C++ programmers anyway.


    Like we saw, OP was confused and annoyed. I do not think that it makes
    him bad (or even horrible) C++ programmer in perspective.

    > Whilst I won't dispute that it makes business sense in some ways for
    > Microsoft to shift people from C++ across to their proprietary
    > technologies, it's hardly the case that they're trying to force people
    > to do so. In fact, their C++ compiler is pretty decent these days - if
    > they were really trying to kill off C++, they'd put out a broken
    > compiler, rather than trying to keep relatively up-to-date with the new
    > standard.


    Yes, people developing MS C++ compiler are up to task. Microsoft is
    developing system software and likely most important parts of it are
    written in C and C++. So ... using compiler of someone else would
    perhaps be not too good publicity for so popular operating system
    vendor. They sell it too, but perhaps it is not much profit from it.

    > The bottom line is that I don't see more choice as a cause for concern.
    > C++ is a useful enough language that it will continue to be used in
    > domains where that makes sense. (Hey, we've got the choice of using
    > C++/CLI for our current projects and we're *not* doing so, right?
    > There's a reason for that.)


    Maybe some of my words were too emotional about it. Nothing criminal,
    only that it is ugly and name is confusing. Ugliness however is
    nothing rare.

    > And I suspect someone like Herb has enough intellectual
    > integrity to say what he thinks about things, in any case.


    Depends what is intellectual integrity? I believe that intelligent
    people avoid saying things that may put the collective that they work
    for (or its products) into bad light. IOW, i expect Herb publicly not
    mentioning aesthetics of C++/CLI *because* he is intelligent.
     
    Öö Tiib, May 28, 2010
    #12
  13. Dann Corbit

    Jonathan Lee Guest

    On May 28, 9:13 am, "Leigh Johnston" <> wrote:
    > I am talking about the namespace and TR1 as an entity, not its contents
    > which should mostly be moved and possibly tweaked when moving from std::tr1
    > to std::
    > /Leigh


    Not _directly_ related to your concerns, but my policy has been to
    use namespace aliases. I don't use TR1 as much, but for C++0x things
    I'll use "cpp0x" as a namespace alias for "boost" or whatever I'm
    using for my C++0x features. Not a perfect solution, but flipping
    the alias to "std" later will fix a large number of problems.

    --Jonathan
     
    Jonathan Lee, May 28, 2010
    #13
  14. "Leigh Johnston" <> writes:

    > As it stands TR1 is a transient, shard_ptr in TR1 for example does not
    > have move constructors. I *do* use TR1 BTW and once I upgrade to a
    > C++0x compiler I will do a global search and replace of my code
    > replacing "std::tr1" with "std". The FCD makes no mention of "tr1" (I
    > cannot find any mentions at least) so it is unclear that it is a
    > requirement for a C++0x implementation to support the tr1 namespace.
    > If that is the case then TR1 as an entity is a transient aberration,
    > simply a stop gap which we have been using for a few years whilst
    > waiting for C++0x.


    For myself, I can find some senses in which the words you are using have
    meaning in this context. Taking defintions from
    http://wordnetweb.princeton.edu/perl/webwn?s[transience/aberrance]:

    transience: "an impermanence that suggests the inevitability of
    ending or dying"

    aberrance: "a state or condition markedly different from the norm"

    then there is, indeed, some sense in which these apply and in which the
    purpose of tr1 /could/ be said to "fit." I think that it was probably
    always intended that aspects of the TR that proved serviceable would be,
    in some form, incorporated into the Standard at some point, which will
    in fact be the case (with or without modification). In this sense use of
    the tr1 library may be `fleeting' (transient) in cases where its use is
    superceded by implementations made available in C++0x. Furthermore, the
    TR itself is distinct from the Standard and as such is, almost by
    definition, "outside the norm" (aberrant). Neither of these aspects
    appear to be against the purpose or intention of the TR, and yet you
    seem to me to be wanting to weight these terms negatively against the TR
    - it is as if you are wanting to say that the TR should perhaps have
    never come into existence in the first place - so that I am left
    wondering what it is exactly that /you/ mean by `aberrant' and
    `transient'.

    As to the FCD, I wouldn't have thought that it was its place to make
    *any* statement of requirement as to whether an implementation should or
    should not continue to make tr1 available. The TR itself was never part
    of the Standard, and will not be /per se/. This is no different from
    the reverse situation in which (as I understand to be the case) that the
    TR did not have any implications as to whether a C++03 implementation
    should include it or not.

    Regards

    Paul Bibbings
     
    Paul Bibbings, May 28, 2010
    #14
  15. Dann Corbit

    Jorgen Grahn Guest

    On Thu, 2010-05-27, Stuart Golodetz wrote:
    > Jorgen Grahn wrote:
    >> On Wed, 2010-05-26, Stuart Golodetz wrote:
    >>> Öö Tiib wrote:

    >> ...
    >>>> Things like cliext::vector are for MS language C++/CLI. C++/CLI is not
    >>>> C++. It looks from a far a bit like C++ but closer look reveals it is
    >>>> undead being.

    >> ...
    >>
    >>> I don't personally use C++/CLI, because I'm not trying to write .NET
    >>> code (and if I was, I'd be more likely to use C#) but I don't really see
    >>> what the problem is with it existing.

    >>
    >> It's a problem if it has "C++" in its name and yet isn't C++. We don't
    >> want to repeat the Pascal fiasco.

    >
    > *shrugs* C++ has C in its name, and yet isn't C. That's not a problem,
    > surely? C++'s name says what it is - a language originally based on C
    > that added lots of new stuff. C++/CLI's name also says what it is - a
    > variant of C++ designed to work with CLI. Still not seeing the problem.


    And yet we have this discussion because someone had a problem with
    C++/CLI, and mistakenly posted about it in a C++ newsgroup, with
    confusion as a result.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jun 2, 2010
    #15
    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. JV

    cpl VS.NET annoyances

    JV, May 31, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    481
  2. Adrienne Boswell

    OT: Annoyances in PDF

    Adrienne Boswell, Apr 27, 2007, in forum: HTML
    Replies:
    6
    Views:
    322
    Neredbojias
    Apr 28, 2007
  3. Replies:
    38
    Views:
    762
    Sion Arrowsmith
    Apr 30, 2007
  4. Paul McGuire

    My newbie annoyances so far

    Paul McGuire, Apr 27, 2007, in forum: Python
    Replies:
    25
    Views:
    663
    Isaac Gouy
    May 9, 2007
  5. =?iso-8859-1?B?QW5kcuk=?=

    My Python annoyances

    =?iso-8859-1?B?QW5kcuk=?=, Apr 28, 2007, in forum: Python
    Replies:
    40
    Views:
    1,077
    Alex Martelli
    May 6, 2007
Loading...

Share This Page