STL annoyances

D

Dann Corbit

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.
 
Ö

Öö Tiib

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.
 
D

Dann Corbit

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]
 
Ö

Öö Tiib

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

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.
 
J

Juha Nieminen

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.

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.
 
S

SG

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

What "functional" are you guys talking about? From what I can tell C+
[...]
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
 
J

Jorgen Grahn

Öö Tiib wrote: .... ....

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
 
Ö

Öö Tiib

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.
 
J

John H.

Leigh said:
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.
 
P

Paul Bibbings

Leigh Johnston said:
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
 
Ö

Öö Tiib

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.
 
J

Jonathan Lee

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
 
P

Paul Bibbings

Leigh Johnston said:
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
 
J

Jorgen Grahn

*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
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top