Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > STL annoyances

Reply
Thread Tools

STL annoyances

 
 
Dann Corbit
Guest
Posts: n/a
 
      05-26-2010
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.
 
Reply With Quote
 
 
 
 
Öö Tiib
Guest
Posts: n/a
 
      05-26-2010
On 26 mai, 23:28, Dann Corbit <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
Dann Corbit
Guest
Posts: n/a
 
      05-26-2010
In article <39864029-51f1-4a24-87b6-
http://www.velocityreviews.com/forums/(E-Mail Removed)>, (E-Mail Removed) says...
>
> On 26 mai, 23:28, Dann Corbit <(E-Mail Removed)> 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]
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      05-26-2010
On 27 mai, 00:07, Dann Corbit <(E-Mail Removed)> 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.
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      05-26-2010
On 27 mai, 00:01, "Leigh Johnston" <(E-Mail Removed)> wrote:
> "Öö Tiib" <(E-Mail Removed)> 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.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      05-27-2010
Dann Corbit <(E-Mail Removed)> 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.
 
Reply With Quote
 
SG
Guest
Posts: n/a
 
      05-27-2010
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/libstd...01ch03s02.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
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      05-27-2010
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 .
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      05-27-2010
On 27 mai, 01:12, Stuart Golodetz
<(E-Mail Removed)> 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.
 
Reply With Quote
 
John H.
Guest
Posts: n/a
 
      05-27-2010
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
cpl VS.NET annoyances JV ASP .Net 0 05-31-2005 09:05 PM
2 small annoyances RAH Computer Support 1 10-29-2004 01:11 AM
Windows Media Annoyances rnd Computer Support 1 04-08-2004 05:59 PM
A Couple of XP Annoyances Sam Computer Support 2 02-12-2004 02:05 PM
Canon: annoyances of a defective product & service policy John Faughnan Digital Photography 1 08-08-2003 11:19 PM



Advertisments