In article <7jhgl9$3gu$1@nnrp1.deja.com> sirwillard@my-deja.com writes:
>In article <7jdv30$68a$1@panix.com>,
>  comeau@comeaucomputing.com wrote:
>> In article <7j9h3m$onj$1@nnrp1.deja.com> sirwillard@my-deja.com
>writes:
>>>In article <fxtk8tk7sp6.fsf@isolde.engr.sgi.com>,
>>>  Matt Austern <austern@sgi.com> wrote:
>>>> sirwillard@my-deja.com writes:
>>>>>No, it doesn't stand to reason.  It's quite possible for someone
>>>>>to write a program that doesn't include a single header file from
>>>>>the STL (SGI extensions or no) and still have a name clash at link
>>>>> time.
>>>All that's required is for another library to have used these
>>>internally.
>>>>
>>>>In that case the program does include one of those headers.
>>>>A program is a collection of translation units, and a name appears
>>>>in a program
>>>>only if it appears in at least one translation unit.  A translation
>>>>unit that includes a non-standard include directive, such as
>>>>#include <rope> or #include <windows.h>, is outside the scope of
>>>>the standard.
>>>
>>>No, the program doesn't include one of those headers.  The library
>>>did when it was built, but the program in question never does.
>>>It's not in any translation unit for the program in question.
>>>Thus, it's a link error, not a compile error.
>>
>> You may have a point, but it isn't quite this one.  That is to say,
>> `translation units' make up a `program'.  Nothing else does.
>
>I never argued other wise.

My observation is that you have repeatedly argued otherwise.
Saying the program does not include the header because the library did,
does not follow.  This is not negotiable.  If the library includes
the header, and you involve the library to link the program, then
the effect is that the program has done so.

>> You're trying to say that the library parts of the program
>> are not translation units just because you did not write them,
>> or something like that.  That is not correct.
>
>That is not what I was trying to say.

But it is what you've said.  Ok, let's clear it up....

>A translation unit is the full
>unit of code seen by the compiler, which includes the "root" file and
>all files #included (to all depths).

Something like that, ok.

>However, a library that's linked
>in to the program may well have had it's own translation unit

It should have.

>that included the non-standard std::rope,

Ok still...

>and thus, even though my program does not have std::rope in
>any translation unit,

Aha!  It does.

It does through that fact that you are linking the library into your
program.  Your program is not just your parts.

>you'll still wind up with a link error.

Right.  Since it's used somewhere, but it's definition cannot be resolved
(yet).

>> Now it may be so that a so-called library translation unit used <rope>
>> or <windows.h>, and I think that was your point.  I can appreciate
>> that
>> this wouldn't be fun, and in some cases rather cavalier, but as Matt
>> mentioned this is outside the scope of the standard.
>
>It doesn't need to be.  Simply requiring all extensions to be outside
>of namespace std would eliminate this possibility.

Ok, this is debatable.

I think Matt covered a bit of the pathology involved in his
numerous posts.  As we both mentioned, it would not necessarily
remove your link error.  If it does, then I do not understand
your situation and perhaps it's time to speak in C++ (with tiny
hypothetical examples).

>> Furthermore, it could be as cavalier for a library author to slip
>> something like that into (their part of) a program even if the part
>> _did not_ even use something from std::.  In short then, this is an
>> old problem, not a new one.  I'm not trying to justify or excuse it,
>> just trying to bring out the facts. My own opinion is that this is a
>> mixed bag.  Library authors should be cautious about what they do and
>> include, but as well, users need to be aware too and do things like
>read
>> documentation and other things.
>
>The old problem would (at least mostly) go away with proper usage of
>namespaces.

I don't see how, you'd still need to provide something::rope.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7jp9oa$t7r$1@nnrp1.deja.com> sirwillard@my-deja.com writes:
>In article <fxtzp29jc57.fsf@isolde.engr.sgi.com>,
>  Matt Austern <austern@sgi.com> wrote:
>> sirwillard@my-deja.com writes:
>> There simply is no standard-conformance issue here.
>
>I agree the standard doesn't prevent SGI from declaring a std::rope.
>However, this doesn't mean there's no standards issue here.  The issue,
>IMHO, is that the standard allows for this.

The only issue you've raised repeatedly is that _you don't like_ that
the standard allows for this.  However, Matt has posted 6-7 technical
responses at the least explaining some of the technical issues involved
(as have others)

I assume that you are pursuing this because you would like to see
that Standard changed on this matter.  If so, you should try to counter
the issues raised in some manner.  Just saying you get a link error
is insufficient.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <375DB6FD.95B69E2B@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> sirwillard@my-deja.com wrote:
> Your program includes not only the translation units you wrote, but
also
> the translations units that were compiled to form all non-standard
> libraries you link to. Whether your program is well-formed depends in
> part upon what's in those translation units.

Interesting way to look at things.  However, even if it's the "correct"
way to view it (and for many reasons I can see that it would be), it
doesn't change the fact that adding extensions within the std namespace
can lead to problems.

> Nothing, certainly not namespaces, can protect you from the
consequences
> of violations of the standard that occur in code that you link to.

Leaving it simply as this would mean that one can have no hope for
writing conforming programs.  Put another way, today the SGI std::rope
is a conforming class (even if I disagree with the principle of it
being in namespace std).  Tomorrow, if the standard were to define an
std::rope, then any libraries that used SGI's rope would now be non-
conforming libraries, and SGI itself would be non-conforming code.
However, if rope had never been in namespace std, then SGI's rope would
still be conforming, and so would be any library compiled using it.  If
such practice nearly gaurantees that conforming code today will be non-
conforming tomorrow, then it only makes sense that we don't follow this
practice.  I totally fail to see why the standard doesn't disallow the
practice for this very reason.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com writes:

> > Your program includes not only the translation units you wrote, but
> also
> > the translations units that were compiled to form all non-standard
> > libraries you link to. Whether your program is well-formed depends in
> > part upon what's in those translation units.
>
> Interesting way to look at things.  However, even if it's the "correct"
> way to view it (and for many reasons I can see that it would be), it
> doesn't change the fact that adding extensions within the std namespace
> can lead to problems.

The standard is really quite explicit about this: a program is
composed of translation units linked together (clause 3.5, paragraph
1), and nothing else.  Some of those translation units may be supplied
from a library.  (clause 2.1, paragraph 1, step 8) There's nothing in
the C++ standard that justifies a distinction between translation
units supplied by a library and translation units produced directly
from source files.

There simply is no standard-conformance issue here.  There are other
issues, to be sure, such as convenience for customers, backward
compatibility with earlier designs, potential forward compatibility
with hypothetical future directions and so on.  These are interesting
questions (some of them are more important than others, of course),
but they aren't relevant to discussion of standardization.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <fxtzp29jc57.fsf@isolde.engr.sgi.com>,
  Matt Austern <austern@sgi.com> wrote:
> sirwillard@my-deja.com writes:
> There simply is no standard-conformance issue here.

I agree the standard doesn't prevent SGI from declaring a std::rope.
However, this doesn't mean there's no standards issue here.  The issue,
IMHO, is that the standard allows for this.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com writes:

> In article <fxtzp29jc57.fsf@isolde.engr.sgi.com>,
>   Matt Austern <austern@sgi.com> wrote:
> > sirwillard@my-deja.com writes:
> > There simply is no standard-conformance issue here.
>
> I agree the standard doesn't prevent SGI from declaring a std::rope.

A slight correction, just so that people who came into this discussion
in the middle don't get misled.

The C++ standard permits a non-standard header to declare an
std::rope<>.  (The standard also permits a non-standard header to do
lots of other things.  A non-standard header might, for example,
contain a pragma that changes the current compilation mode in some
way.)

The standard headers, however, may not contain such extra identifiers.
The <string> header, for example, may not declare an std::rope<> class,
or even a _My_Extension_Namespace::rope<> class.

In practice this requirement is often violated, especially in the C
library headers.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com wrote:

> I agree the standard doesn't prevent SGI from declaring a std::rope.
> However, this doesn't mean there's no standards issue here.  The issue,
> IMHO, is that the standard allows for this.

Hint: there is nothing the standard can do about
non standard extentions.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com wrote:
>
> In article <fxtk8tk7sp6.fsf@isolde.engr.sgi.com>,
>   Matt Austern <austern@sgi.com> wrote:
> > sirwillard@my-deja.com writes:
> >
> > > No, it doesn't stand to reason.  It's quite possible for someone to
> > > write a program that doesn't include a single header file from the
> STL
> > > (SGI extensions or no) and still have a name clash at link time.
> All
> > > that's required is for another library to have used these
> internally.
> >
> > In that case the program does include one of those headers.  A program
> > is a collection of translation units, and a name appears in a program
> > only if it appears in at least one translation unit.  A translation
> > unit that includes a non-standard include directive, such as
> > #include <rope> or #include <windows.h>, is outside the scope of the
> > standard.
>
> No, the program doesn't include one of those headers.  The library did
> when it was built, but the program in question never does.  It's not in
> any translation unit for the program in question.  Thus, it's a link
> error, not a compile error.

If you link your code with someone else's, (whether or not that code is
organized into libraries), it is the combination of your code and their
code which constitutes the entire program. If their code violates the
standard, then your program violates the standard.

The standard defines a C++ program as consisting of a group of C++
translation units, which must contain exactly one definition of every
non-inline function or object that is used in the program. If that
function or object is actually defined in a module not written in C++,
then the behavior is not defined by the C++ standard (which is only
reasonable).
There is an implication that paired C/C++ implementations should be link
compatible, if modules are connected using interfaces that are properly
declared as 'extern "C"' in the C++ code. However, the standard does not
actually require that 'extern "C"' functions or objects be creatable by
any means other than defining them in C++ code and translating them
using the C++ implementation.

If the third-party modules were written in C++, then the source code of
those modules counts as user-written code. This includes any
non-standard headers #included into the code, even if those headers were
provided along with the C++ implementation itself. If such a header does
something which would be undefined behavior for user-written code, such
as adding a rope<> class to namespace std, then the program is not
strictly conforming. Any problems that might arise from that fact are
the fault of the non-standard header, or of the library that #included
it, or of the program that links to the library. They don't detract from
the conformance of the C++ implementation itself.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7j9h3m$onj$1@nnrp1.deja.com> sirwillard@my-deja.com writes:
>In article <fxtk8tk7sp6.fsf@isolde.engr.sgi.com>,
>  Matt Austern <austern@sgi.com> wrote:
>> sirwillard@my-deja.com writes:
>>
>> > No, it doesn't stand to reason.  It's quite possible for someone to
>> > write a program that doesn't include a single header file from the
>STL
>> > (SGI extensions or no) and still have a name clash at link time.
>All
>> > that's required is for another library to have used these
>internally.
>>
>> In that case the program does include one of those headers.  A program
>> is a collection of translation units, and a name appears in a program
>> only if it appears in at least one translation unit.  A translation
>> unit that includes a non-standard include directive, such as
>> #include <rope> or #include <windows.h>, is outside the scope of the
>> standard.
>
>No, the program doesn't include one of those headers.  The library did
>when it was built, but the program in question never does.  It's not in
>any translation unit for the program in question.  Thus, it's a link
>error, not a compile error.

You may have a point, but it isn't quite this one.  That is to say,
`translation units' make up a `program'.  Nothing else does.

You're trying to say that the library parts of the program
are not translation units just because you did not write them,
or something like that.  That is not correct.

Now it may be so that a so-called library translation unit used <rope>
or <windows.h>, and I think that was your point.  I can appreciate that
this wouldn't be fun, and in some cases rather cavalier, but as Matt
mentioned this is outside the scope of the standard.

Furthermore, it could be as cavalier for a library author to slip
something like that into (their part of) a program even if the part
_did not_ even use something from std::.  In short then, this is an
old problem, not a new one.  I'm not trying to justify or excuse it,
just trying to bring out the facts. My own opinion is that this is a
mixed bag.  Library authors should be cautious about what they do and
include, but as well, users need to be aware too and do things like read
documentation and other things.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com wrote:
>
> In article <fxtk8tk7sp6.fsf@isolde.engr.sgi.com>,
>   Matt Austern <austern@sgi.com> wrote:

> > In that case the program does include one of those headers.  A program
> > is a collection of translation units, and a name appears in a program
> > only if it appears in at least one translation unit.  A translation
> > unit that includes a non-standard include directive, such as
> > #include <rope> or #include <windows.h>, is outside the scope of the
> > standard.
>
> No, the program doesn't include one of those headers.  The library did
> when it was built,

The SGI STL comes only in header files, no .cpp file, no binary
(no library). So your comment applies to ... nothing.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37592CFD.1106A47F@wizard.net> James Kuyper <kuyper@wizard.net> writes:
>There is an implication that paired C/C++ implementations should be link
>compatible, if modules are connected using interfaces that are properly
>declared as 'extern "C"' in the C++ code. However, the standard does not
>actually require that 'extern "C"' functions or objects be creatable by
>any means other than defining them in C++ code and translating them
>using the C++ implementation.

Linkage specification have always been a bit funny to me.  However,
also to me, they've never been a guarantee, so, I don't think that there
are any "should"s here.  The only implication to this "hook" is that
it is but a "fighting chance".  So if a so-called paired implementation is
link compatible, so be it.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

comeau@panix.com (Greg Comeau) writes:

>In article <37592CFD.1106A47F@wizard.net> James Kuyper <kuyper@wizard.net> writes:
>>There is an implication that paired C/C++ implementations should be link
>>compatible, if modules are connected using interfaces that are properly
>>declared as 'extern "C"' in the C++ code. However, the standard does not
>>actually require that 'extern "C"' functions or objects be creatable by
>>any means other than defining them in C++ code and translating them
>>using the C++ implementation.

>Linkage specification have always been a bit funny to me.  However,
>also to me, they've never been a guarantee, so, I don't think that there
>are any "should"s here.  The only implication to this "hook" is that
>it is but a "fighting chance".  So if a so-called paired implementation is
>link compatible, so be it.

Because of the close ties of C and C++, and because of the special
status of C linkage (it must be supported), there's an implication
that a given C++ implementation can be linked with code from at
least one C implementation on the same system.

But there isn't any good way to say that in the standard -- or at
least no one found a good way to say it. You wind up with the C++
standard placing some requirements on a C implementation, or
requiring a compatible C implementation to exist, neither of
which really belongs in a C++ standard. (Suppose a system has
no standard-conforming C compiler. Do we require that the C++
implementation supply a C compiler in order to conform to
the C++ standard?)

In addition, you sometimes find incompatible C implementations on
the same platform as the C++ compiler -- the C++ compiler might be
compatible with one, but it's asking a lot for it to be compatible
with all C implementations that might exist.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7jfjnc$mtv$1@engnews1.eng.sun.com> clamage@eng.sun.com (Steve Clamage) writes:
>
>comeau@panix.com (Greg Comeau) writes:
>
>>In article <37592CFD.1106A47F@wizard.net> James Kuyper <kuyper@wizard.net> writes:
>>>There is an implication that paired C/C++ implementations should be link
>>>compatible, if modules are connected using interfaces that are properly
>>>declared as 'extern "C"' in the C++ code. However, the standard does not
>>>actually require that 'extern "C"' functions or objects be creatable by
>>>any means other than defining them in C++ code and translating them
>>>using the C++ implementation.
>
>>Linkage specification have always been a bit funny to me.  However,
>>also to me, they've never been a guarantee, so, I don't think that there
>>are any "should"s here.  The only implication to this "hook" is that
>>it is but a "fighting chance".  So if a so-called paired implementation is
>>link compatible, so be it.
>
>Because of the close ties of C and C++, and because of the special
>status of C linkage (it must be supported), there's an implication
>that a given C++ implementation can be linked with code from at
>least one C implementation on the same system.
>
>But there isn't any good way to say that in the standard -- or at
>least no one found a good way to say it. You wind up with the C++
>standard placing some requirements on a C implementation, or
>requiring a compatible C implementation to exist, neither of
>which really belongs in a C++ standard. (Suppose a system has
>no standard-conforming C compiler. Do we require that the C++
>implementation supply a C compiler in order to conform to
>the C++ standard?)
>
>In addition, you sometimes find incompatible C implementations on
>the same platform as the C++ compiler -- the C++ compiler might be
>compatible with one, but it's asking a lot for it to be compatible
>with all C implementations that might exist.

I agree the words are to the effect that C linkage must be supported.
But that there is not a way to really say it and/or that it's beyond
the scope of Standard C++ is why I'd rather just say it's fighting chance
rather than an implication....  for instance, even saying
"on the same system" is odd.  I think what's important it that the
opportunity is there.  Just like PODs give us that fighting chance
connection into the C object memory model, linkage specifications
(via extern "C" and such) give us that fighting chance connection
into the C linkage convention model, which just so happens to be
at least implementation-defined for each respective C compiler.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:

> Matt Austern wrote:
>
> > Namespace std is a red herring.
>
> I don't think it is.
>
> > Extra names in standard headers are
> > forbidden regardless of what namespace they're in (unless they are
> > names reserved for the implementation, of course), and extra names in
> > nonstandard headers are not a standard conformance issue.
>
> Obviously.
>
> But what about putting non standard names in another namespace,
> making clear that they aren't standard, making it possible to
> standardize on a std::rope class incompatible with yours ?

That would be conforming too.

I'm trying to separate out two different questions: what does the
standard require, and what choice would be better.  The latter
discussion is interesting, and there are many possible ways to answer
it.  (Backward compatibility, compatibility with hypothetical future
requirements, aesthetic elegance, convenience for customers,...)  I
don't think, though, that it's an appropriate discussion for a
standardization newsgroup.

My position is that SGI's <rope> header satisfies every requirement
that the C++ standard imposes on a <rope> header.

Perhaps I should also clarify what I mean by "red herring".  I mean
that, as far as requirements imposed by the standard on vendor
extensions, the namespace of those extensions is essentially
irrelevant.  Putting them into a vendor-defined namespace is neither
necessary nor sufficient.  It's not necessary if the extensions go
into a non-standard header, since a non-standard header falls outside
the scope of the standard.  And it's not sufficient to put extensions
in a vendor-defined namespace; a class called "rope" can't be defined
in a standard header at all, no matter what namespace it goes in.
Imagine, for example, that we had defined a class SGI::rope in the
standard header <string>. If we had done that we would have broken the
following conforming program:
    #define rope 137
    #include <string>
    int main() {}
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

clamage@eng.sun.com (Steve Clamage) writes:
>Because of the close ties of C and C++, and because of the special
>status of C linkage (it must be supported), there's an implication
>that a given C++ implementation can be linked with code from at
>least one C implementation on the same system.
>
>But there isn't any good way to say that in the standard -- or at
>least no one found a good way to say it.

For the record, I would like to again point out that there _are_
good ways to say that.  In particular, it would be straightforward
for the standard to define a notion of a "conforming combined C/C++
implementation" and to document appropriate requirements for
conforming combined C/C++ implementations.

I said this at the time, but obviously I did not explain my ideas
with sufficient clarity or persuasiveness to convince enough of
of the C++ committee.  Or perhaps those who agreed with me simply
didn't consider the issue important enough to be worth worrying about.

>You wind up with the C++
>standard placing some requirements on a C implementation, or
>requiring a compatible C implementation to exist, neither of
>which really belongs in a C++ standard.

This is not true.

If my suggestions had been followed, then the C++ standard would have placed
requirements on
 (a) C++ implementations
     [if they claim to be conforming C++ implementations]
and
 (b) combined C/C++ implementations
     [if they claim to be conforming combined C/C++ implementations].

The C++ standard would not have required that a compatible C implementation
exist for any C++ implementation, and nor would it have placed any
requirements on a C implementation, unless that C implementation happens
to be part of a combined C/C++ implementation which claims to be a
conforming combined C/C++ implementation.

Note that it would also be possible for the requirements on combined
C/C++ implementations to be published as a separate document, rather than
as part of the C++ standard.  So this is something that the committee
could fix now, if it had the inclination, rather than something for which
we would have to wait until the next version of the C++ standard.

>(Suppose a system has
>no standard-conforming C compiler. Do we require that the C++
>implementation supply a C compiler in order to conform to
>the C++ standard?)

No.

>In addition, you sometimes find incompatible C implementations on
>the same platform as the C++ compiler -- the C++ compiler might be
>compatible with one, but it's asking a lot for it to be compatible
>with all C implementations that might exist.

Sure.  With my suggestion, the standard would not require that the C++
compiler be compatible with all or in fact with any C implementation
on a given platform.  If no vendor makes any claims about any particular
combination being a "conforming combined C/C++ implementation", then
the standard would impose no requirements about compatibility between
conforming C implementations and conforming C++ implementations on that
platform.  The requirements on compatibility would be imposed only if
someone claims that a particular combination is a "conforming combined
C/C++ implementation".

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

comeau@panix.com (Greg Comeau) writes:
>
> Now it may be so that a so-called library translation unit used
> <rope> or <windows.h>, ...  I can appreciate that this wouldn't be
> fun, and in some cases rather cavalier, but as Matt mentioned this
> is outside the scope of the standard.
>
> ...Library authors should be cautious about what they do and
> include, but as well, users need to be aware too and do things like
> read documentation and other things.

Agree. I would summarise the situation like this: The approach taken
by the SGI STL of adding extensions to the std namespace via
non-standard headers is perfectly legal as far as the ISO standard is
concerned. Nevertheless, independent of the compliance issue, one can
question whether this approach was ideal.

Personally, I would have preferred if these extensions had been put
into another namespace. But it is not a question of compliance.

Joachim

--
joachim@kraut.bc.ca      (http://www.kraut.bc.ca)
joachim@mercury.bc.ca    (http://www.mercury.bc.ca)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7jdv30$68a$1@panix.com>,
  comeau@comeaucomputing.com wrote:
> In article <7j9h3m$onj$1@nnrp1.deja.com> sirwillard@my-deja.com
writes:
> >In article <fxtk8tk7sp6.fsf@isolde.engr.sgi.com>,
> >  Matt Austern <austern@sgi.com> wrote:
> >> sirwillard@my-deja.com writes:
> >>
> >> > No, it doesn't stand to reason.  It's quite possible for someone
to
> >> > write a program that doesn't include a single header file from
the
> >STL
> >> > (SGI extensions or no) and still have a name clash at link time.
> >All
> >> > that's required is for another library to have used these
> >internally.
> >>
> >> In that case the program does include one of those headers.  A
program
> >> is a collection of translation units, and a name appears in a
program
> >> only if it appears in at least one translation unit.  A translation
> >> unit that includes a non-standard include directive, such as
> >> #include <rope> or #include <windows.h>, is outside the scope of
the
> >> standard.
> >
> >No, the program doesn't include one of those headers.  The library
did
> >when it was built, but the program in question never does.  It's not
in
> >any translation unit for the program in question.  Thus, it's a link
> >error, not a compile error.
>
> You may have a point, but it isn't quite this one.  That is to say,
> `translation units' make up a `program'.  Nothing else does.

I never argued other wise.

> You're trying to say that the library parts of the program
> are not translation units just because you did not write them,
> or something like that.  That is not correct.

That is not what I was trying to say.  A translation unit is the full
unit of code seen by the compiler, which includes the "root" file and
all files #included (to all depths).  However, a library that's linked
in to the program may well have had it's own translation unit that
included the non-standard std::rope, and thus, even though my program
does not have std::rope in any translation unit, you'll still wind up
with a link error.

> Now it may be so that a so-called library translation unit used <rope>
> or <windows.h>, and I think that was your point.  I can appreciate
that
> this wouldn't be fun, and in some cases rather cavalier, but as Matt
> mentioned this is outside the scope of the standard.

It doesn't need to be.  Simply requiring all extensions to be outside
of namespace std would eliminate this possibility.

> Furthermore, it could be as cavalier for a library author to slip
> something like that into (their part of) a program even if the part
> _did not_ even use something from std::.  In short then, this is an
> old problem, not a new one.  I'm not trying to justify or excuse it,
> just trying to bring out the facts. My own opinion is that this is a
> mixed bag.  Library authors should be cautious about what they do and
> include, but as well, users need to be aware too and do things like
read
> documentation and other things.

The old problem would (at least mostly) go away with proper usage of
namespaces.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com wrote:
>
> In article <7jdv30$68a$1@panix.com>,
>   comeau@comeaucomputing.com wrote:
....
> > You're trying to say that the library parts of the program
> > are not translation units just because you did not write them,
> > or something like that.  That is not correct.
>
> That is not what I was trying to say.  A translation unit is the full
> unit of code seen by the compiler, which includes the "root" file and
> all files #included (to all depths).  However, a library that's linked
> in to the program may well have had it's own translation unit that
> included the non-standard std::rope, and thus, even though my program
> does not have std::rope in any translation unit, you'll still wind up
> with a link error.

Your program includes not only the translation units you wrote, but also
the translations units that were compiled to form all non-standard
libraries you link to. Whether your program is well-formed depends in
part upon what's in those translation units.

....
> > Furthermore, it could be as cavalier for a library author to slip
> > something like that into (their part of) a program even if the part
> > _did not_ even use something from std::.  In short then, this is an
> > old problem, not a new one.  I'm not trying to justify or excuse it,
> > just trying to bring out the facts. My own opinion is that this is a
> > mixed bag.  Library authors should be cautious about what they do and
> > include, but as well, users need to be aware too and do things like
> read
> > documentation and other things.
>
> The old problem would (at least mostly) go away with proper usage of
> namespaces.

Nothing, certainly not namespaces, can protect you from the consequences
of violations of the standard that occur in code that you link to.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com wrote:
> >
> > The SGI rope class is defined in the header <rope>. Your
> > example code doesn't #include this header. So your example code
> > doesn't have a visible rope.
>
> I don't have the original post available to see the example code.
> However, in practice things aren't as easy as you've made them out to
> be.  A module may have made use of the rope class and could cause us
> link errors if there's another implementation of std::rope.  No visible
> rope in our code, but still a name clash at link time.

Interesting. Which of the two std::rope do you think is evil ? What name
clash are
you talking about ? If you did not put "#include <rope>" in any of your
code, it is equivalent to its non-existense, you do not get any clashes.

>
> > Note that namespaces are _not_ like modules in some other languages.
> > By using a namespace, you don't get everything which was ever written
> > in that namespace, but only those things which were explicitly
> > declared in this namespace in the current translation unit.
>
> True, but this doesn't eliminate name clashes at link time, which can
> occur under the conditions we've got here.
>
> > If SGI had decided to put their rope class together with the string
> > class in <string>, then the situation would be different. However,
> > they haven't done that. You get their rope only by #including the
> > header <rope>, and doing so is non-standard.
>
> As stated above, a #include <rope> is not the only way to get an
> instance of std::rope at link time.

Please explain how this another way works.

>
> > The only complaint one can do is that they used a name for the
> > header which the standard body would probably choose as well, should
> > ropes ever get into the standard. A header name <rope.h> or <rope.sgi>
> > would probably have been better.

I do believe that <rope> would have the same interface if it is going to
become
part of the standard. So you'll be OK, do not worry.

>
> Better, but it doesn't eliminate the possibility of a name clash at
> link time if the standard ever defines a rope class in the future.  I
> think extensions that are contained in the std namespace are flat out a
> bad idea, whether the standard allows for them now or not (and the last
> time I brought this up I seemed to get conflicting opinions on whether
> this was allowed).

Which of the two ideas do you think the worst :

1) using <rope> defining std::rope, being aware it is non-standard and
thus using specific
implementation. This way, should rope ever go to standard, you do not
have to
modify your code.
2) using <rope> defining sgistd::rope, being aware of the same as above,
and being forced to change your code after rope is being adopted to the
standard.


Best regards,

-----------------------------------------------------
Boris Fomitchev   |  Boris.Fomitchev@Eng.Sun.Com
-----------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <fxtpv3e7f03.fsf@isolde.engr.sgi.com>,
  Matt Austern <austern@sgi.com> wrote:
> sirwillard@my-deja.com writes:
>
> > Better, but it doesn't eliminate the possibility of a name clash at
> > link time if the standard ever defines a rope class in the future.
I
> > think extensions that are contained in the std namespace are flat
out a
> > bad idea, whether the standard allows for them now or not (and the
last
> > time I brought this up I seemed to get conflicting opinions on
whether
> > this was allowed).
>
> This is covered by the "as if" rule.  A conforming implementation is
> permitted to do anything whatsoever, provided that a well-formed
> program is unable to tell the difference.
>
> The standard says nothing about what is supposed to happen if a
> program contains the line "#include <rope>" in any translation unit,
> just as it says nothing about what is supposed to happen if a program
> contains the line "#include <sys/ioctl.h>" or "#include <windows.h>".
> Implementations are not required to provide those extra headers, nor
> are they forbidden from providing them.

I hardly see this as being covered by the "as if" rule.  We aren't
discussing whether or not it's valid to provide extra functionality or
extra headers.  We are discussing the "proper" usage of namespaces.
The namespace concept was developed specifically to eliminate name
conflicts such as we have the potential for in this case.  If you don't
own the namespace (and I'd consider std to be owned by the standards
committee, not the implementors of a library) you shouldn't be adding
to it.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matt Austern wrote:
>
> sirwillard@my-deja.com writes:
>
> > I think extensions that are contained in the
> > std namespace are flat out a bad idea, whether
> > the standard allows for them now or not (and the last
> > time I brought this up I seemed to get conflicting
> > opinions on whether this was allowed).
>
> This is covered by the "as if" rule.
>
> The standard says nothing about what is supposed to
> happen if a program contains the line "#include <rope>"

You missed the point. This is not about if a standard
conforming library can have extensions in additional
include files (which they can).

The point is that it is a bad idea to put extensions in
the std namespace. If a later standard (in 2005, or so)
add a name std::rope to the standard library, then all
applications using the extension will become broken.

Personally we have put all the things we think should
have been in the standard library, but are not in the
namespace nonstd. For example:
 - nonstd::fdstream (file descriptor stream, for sockets)
 - nonstd::rc (reference counted smart pointer template)
 - nonstd::cow (copy on write template class)

Adding non-standard classes and names to the std namespace
in a library API interface is such a bad idea that it
should be banned by the standard. (Is it?)
I think that it is a much better idea to but extensions
in namespace nonstd, or in a namespace with the company
name.

/Tom

--
--------------------------------------------------------------------------
NOTE:     New email address: Tom.Bjorkholm@etx.ericsson.se
     Obsolete email address: Tom.Bjorkholm@ebc.ericsson.se
--------------------------------------------------------------------------
Tom Bjorkholm            Ericsson Telecom AB
Sr. Software Designer    Nacka Strand, 131 89 Stockholm, Sweden
C++ and UN*X             phone: +46-8-4221348, fax:+46-8-4222080
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tom Bj=F6rkholm wrote:

> Adding non-standard classes and names to the std namespace
> in a library API interface is such a bad idea that it
> should be banned by the standard. (Is it?)

I have another question:

Do the standard allow compilers to be non standard ?

*hint* *hint*

--=20

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com writes:
>
> If you don't own the namespace (and I'd consider std to be owned by
> the standards committee, not the implementors of a library) you
> shouldn't be adding to it.

This thread is specificly about the extensions in the SGI STL
implementation. These extensions are accessible ONLY if you include
SGI's non-standard headers. The non-standard names are added to the
std namespace ONLY if you include these non-standard headers. It
follows that all programs which use only standard features work
without any risk of name clashes.

Joachim

--
joachim@kraut.bc.ca      (http://www.kraut.bc.ca)
joachim@mercury.bc.ca    (http://www.mercury.bc.ca)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com writes:

> > The standard says nothing about what is supposed to happen if a
> > program contains the line "#include <rope>" in any translation unit,
> > just as it says nothing about what is supposed to happen if a program
> > contains the line "#include <sys/ioctl.h>" or "#include <windows.h>".
> > Implementations are not required to provide those extra headers, nor
> > are they forbidden from providing them.
>
> I hardly see this as being covered by the "as if" rule.  We aren't
> discussing whether or not it's valid to provide extra functionality or
> extra headers.

Sure it is.  There is no way that a program relying entirely on
standard facilities can tell what the contents of namespace <rope>
are, since it is not a standard header.  The standard simply does not
apply to nonstandard headers.

As a familar example, consider the Unix <sys/ioctl.h> header.  It
defines lots of macros that, according the the C and C++ standard, are
in the user's macro namespace.  (A far more serious name clash than a
mere class name!)  Defining those macros in a standard header like
<cstdio> would be highly improper, but it's perfectly fine to define
them in a nonstandard header like <sys/ioctl.h>.  Once a program
includes a nonstandard header, it is outside the scope of the
standard.

Namespace std is a red herring.  Extra names in standard headers are
forbidden regardless of what namespace they're in (unless they are
names reserved for the implementation, of course), and extra names in
nonstandard headers are not a standard conformance issue.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <ucpv3dayzg.fsf@soft.mercury.bc.ca>,
  Joachim Achtzehnter <joachim@kraut.bc.ca> wrote:
>
> sirwillard@my-deja.com writes:
> >
> > If you don't own the namespace (and I'd consider std to be owned by
> > the standards committee, not the implementors of a library) you
> > shouldn't be adding to it.
>
> This thread is specificly about the extensions in the SGI STL
> implementation. These extensions are accessible ONLY if you include
> SGI's non-standard headers. The non-standard names are added to the
> std namespace ONLY if you include these non-standard headers. It
> follows that all programs which use only standard features work
> without any risk of name clashes.

No, it doesn't stand to reason.  It's quite possible for someone to
write a program that doesn't include a single header file from the STL
(SGI extensions or no) and still have a name clash at link time.  All
that's required is for another library to have used these internally.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com writes:

> No, it doesn't stand to reason.  It's quite possible for someone to
> write a program that doesn't include a single header file from the STL
> (SGI extensions or no) and still have a name clash at link time.  All
> that's required is for another library to have used these internally.

In that case the program does include one of those headers.  A program
is a collection of translation units, and a name appears in a program
only if it appears in at least one translation unit.  A translation
unit that includes a non-standard include directive, such as
#include <rope> or #include <windows.h>, is outside the scope of the
standard.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matt Austern wrote:

> Namespace std is a red herring.

I don't think it is.

> Extra names in standard headers are
> forbidden regardless of what namespace they're in (unless they are
> names reserved for the implementation, of course), and extra names in
> nonstandard headers are not a standard conformance issue.

Obviously.

But what about putting non standard names in another namespace,
making clear that they aren't standard, making it possible to
standardize on a std::rope class incompatible with yours ?

Frankly, I am under the impression that, as almost every other
compiler/library, you (not you personally, of course) are trying
to lock users with subtle mixture between standard and non
standard stuff.

Not that your attitude is any worse than the one of other tool
providers.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Boris Fomitchev wrote:
> Which of the two ideas do you think the worst :
>
> 1) using <rope> defining std::rope, being aware it is non-standard and
> thus using specific implementation. This way, should rope ever go to
> standard, you do not have to modify your code.
>
> 2) using <rope> defining sgistd::rope, being aware of the same as
> above, and being forced to change your code after rope is being
> adopted to the standard.

But what if the next version of ISO C++ does indeed adopt a <rope>
header containing std::rope, but which is incompatible with the
std::rope that you're currently using?  This possibility is quite
likely, given the history behind the iostream and STL classes and
all the changes they went through before their final form was adopted.

Thus, the better alternative:
 3) using <sgi/rope> defining sgi::rope, which may or may not resemble
 a possible future std::rope class, but which is safe from breaking if
 and when std::rope is added to ISO C++.

-- David R. Tribble, dtribble@technologist.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Boris Fomitchev (Boris.Fomitchev@sun.com) wrote:
: 1) using <rope> defining std::rope, being aware it is non-standard and
: thus using specific
: implementation. This way, should rope ever go to standard, you do not
: have to
: modify your code.

This is not precisely true as one will likely have to change the build
environment to get the SGI rope class out of the way before the code will
compile. I am hot sure how this is handled in current build environments
that are trying to use the SGI STL layered over a vendor supplied standard
library. Given that SGI STL is using namespace std, I imagine that this is
somewhat error prone and one must ensure that the SGI STL subsumes *all*
names that may be linked to by the vendor supplied library. Given that the
vendor is allowed to add names within their own namespace, this is
difficult to guarantee. Sooner or later you are going to get a link error.

: 2) using <rope> defining sgistd::rope, being aware of the same as above,
: and being forced to change your code after rope is being adopted to the
: standard.

I can then choose to change to the vendor supplied rope class independently
of the compiler upgrade. Which is a a good thing. (I.e. I can use the SGI
rope class or the vendor supplied rope class by switching the namespace.)

-Z-


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <fxtk8tk7sp6.fsf@isolde.engr.sgi.com>,
  Matt Austern <austern@sgi.com> wrote:
> sirwillard@my-deja.com writes:
>
> > No, it doesn't stand to reason.  It's quite possible for someone to
> > write a program that doesn't include a single header file from the
STL
> > (SGI extensions or no) and still have a name clash at link time.
All
> > that's required is for another library to have used these
internally.
>
> In that case the program does include one of those headers.  A program
> is a collection of translation units, and a name appears in a program
> only if it appears in at least one translation unit.  A translation
> unit that includes a non-standard include directive, such as
> #include <rope> or #include <windows.h>, is outside the scope of the
> standard.

No, the program doesn't include one of those headers.  The library did
when it was built, but the program in question never does.  It's not in
any translation unit for the program in question.  Thus, it's a link
error, not a compile error.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <374D4198.F1590BCC@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> gbush@my-dejanews.com wrote:
> >
> > In article <3729197F.4A47@wanadoo.fr>,
> >   Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> > > Please tell me why. I don't see any problem with this program,
> > > the only visible 'rope' name is in mynamespace.
> > I don't have SGI implementation, but as far as I could get from the
previous
> > posts it contains "rope" class in std namespace. For the purpose of
this
> > discussion it doesn't matter what non-standard class was added to
std. Call it
> > std::whatever if you wish. That simply means that any conforming
program that
> > has "whatever" class has good chance to fail on compiler with
extensions. That
> > makes such compiler non-conforming.
>
> The SGI rope class is defined in the header <rope>. Your
> example code doesn't #include this header. So your example code
> doesn't have a visible rope.

I don't have the original post available to see the example code.
However, in practice things aren't as easy as you've made them out to
be.  A module may have made use of the rope class and could cause us
link errors if there's another implementation of std::rope.  No visible
rope in our code, but still a name clash at link time.

> Note that namespaces are _not_ like modules in some other languages.
> By using a namespace, you don't get everything which was ever written
> in that namespace, but only those things which were explicitly
> declared in this namespace in the current translation unit.

True, but this doesn't eliminate name clashes at link time, which can
occur under the conditions we've got here.

> If SGI had decided to put their rope class together with the string
> class in <string>, then the situation would be different. However,
> they haven't done that. You get their rope only by #including the
> header <rope>, and doing so is non-standard.

As stated above, a #include <rope> is not the only way to get an
instance of std::rope at link time.

> The only complaint one can do is that they used a name for the
> header which the standard body would probably choose as well, should
> ropes ever get into the standard. A header name <rope.h> or <rope.sgi>
> would probably have been better.

Better, but it doesn't eliminate the possibility of a name clash at
link time if the standard ever defines a rope class in the future.  I
think extensions that are contained in the std namespace are flat out a
bad idea, whether the standard allows for them now or not (and the last
time I brought this up I seemed to get conflicting opinions on whether
this was allowed).


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com writes:

> Better, but it doesn't eliminate the possibility of a name clash at
> link time if the standard ever defines a rope class in the future.  I
> think extensions that are contained in the std namespace are flat out a
> bad idea, whether the standard allows for them now or not (and the last
> time I brought this up I seemed to get conflicting opinions on whether
> this was allowed).

This is covered by the "as if" rule.  A conforming implementation is
permitted to do anything whatsoever, provided that a well-formed
program is unable to tell the difference.

The standard says nothing about what is supposed to happen if a
program contains the line "#include <rope>" in any translation unit,
just as it says nothing about what is supposed to happen if a program
contains the line "#include <sys/ioctl.h>" or "#include <windows.h>".
Implementations are not required to provide those extra headers, nor
are they forbidden from providing them.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

gbush@my-dejanews.com wrote:
>
> In article <3729197F.4A47@wanadoo.fr>,
>   Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> > Please tell me why. I don't see any problem with this program,
> > the only visible 'rope' name is in mynamespace.
> I don't have SGI implementation, but as far as I could get from the previous
> posts it contains "rope" class in std namespace. For the purpose of this
> discussion it doesn't matter what non-standard class was added to std. Call it
> std::whatever if you wish. That simply means that any conforming program that
> has "whatever" class has good chance to fail on compiler with extensions. That
> makes such compiler non-conforming.

The SGI rope class is defined in the header <rope>. Your
example code doesn't #include this header. So your example code
doesn't have a visible rope.
Note that namespaces are _not_ like modules in some other languages.
By using a namespace, you don't get everything which was ever written
in that namespace, but only those things which were explicitly
declared in this namespace in the current translation unit.

If SGI had decided to put their rope class together with the string
class in <string>, then the situation would be different. However,
they haven't done that. You get their rope only by #including the
header <rope>, and doing so is non-standard.
The only complaint one can do is that they used a name for the
header which the standard body would probably choose as well, should
ropes ever get into the standard. A header name <rope.h> or <rope.sgi>
would probably have been better.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7g7dc5$cmt$1@nnrp1.dejanews.com>, sirwillard@my-dejanews.com
says...
> I really fail to see why people have such praise for this library.

In my case, the Rogue-Wave lib that shipped with BC++ 5 was causing me a
lot of grief.  When I switched to SGI (actually the further doctored
version for specific platforms), my life became easier.

Ed


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-dejanews.com wrote:

> SGI's implementation has two major problems, as I see it.  Firstly, they have
> a lot of extensions, such as the rope and hash_map classes.

So don't use them.

The problem I see is the documentation, which doesn't make clear
which parts are standard, and thus doesn't help those who want to
write portable code.

> Secondly, SGI's implementation fails to provide the templated versions of the
> iostream libraries.
[...]
> I really fail to see why people have such praise for this library.

Well, we have a free, good library, why do you complain ? Why would
SGI have to give you a complete implementation for free ? (SGI does
have a more complete library implementation than the SGI STL - if you
buy the SGI compiler you'll get it.)

> So I can't use their library as a
> drop in replacement for that provided by my compiler.

You might use it as a partial replacement. If the non-STL
part of your implementation doesn't make special non standard
assumptions about the STL, it should work fine (of course it
is allowed to make such assumptions - but I don't know any
implementation which does).

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-dejanews.com wrote:

> Recommending one not use the
> extensions is a silly response to this issue.

Hum...

> I'll have to look here, but on SGI's FAQ page they clearly state that strings
> are not compatible with the VC++ templated iostreams.

They absolutly don't say that.

> Even if the above is true, this is a feature not provided by the SGI
> implementation, which I would assume makes them non-compliant with the
> standard.

Again, this is a _partial_ implementation.

> Again, your recommendation (to use the VC++ iostreams) is a silly
> response to this issue.

Hum... is it a personnal attack ?

> Non-compliance in a library that claims compliance (and I don't mean simple
> bugs

To me bugs are serious violations of the standards !

> or work arounds for compiler limitations, these are more serious
> violations of the standard)

Which ones ? (except the some small extentions ?)

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3727BFA1.5631@wanadoo.fr>,
  Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:

> > or work arounds for compiler limitations, these are more serious
> > violations of the standard)
>
> Which ones ? (except the some small extentions ?)

Well, the standard doesn't say a word about threads.  So I guess you
would have to consider the thread safety of the SGI library an
extension.  Personally, of course, I don't seen anything wrong with
extensions *if* they don't interfere with conformant use.  Thus, the
fact that the SGI library is thread-safe doesn't prevent me from using
it without threads.  And the fact that they include hash_map doesn't
prevent me from using it in programs that don't use hash_map.

The lack of an iostream is a weakness.  But not as much of one as the
lack of a compiler.  Frankly, if SGI claims that their implementation of
the STL is a complete and fully conformant C++ implementation, they are
lying.  But I don't think that they claim this.  All they claim is that
what they have implemented is conformant (but not complete).

Their choice of what to implement also seems reasonable.  They implement
the chapters that can be fully implemented fully in C++, without
dependancies on the underlying machine or OS.  The compiler itself, of
course, is manifestly dependant on the underlying machine, and iostream
on the OS.

This isn't to say that you can't complain.  SGI also provides a complete
implementation.  Not for PC's, of course -- they've chosen to target a
different market.  And they don't claim it to be 100% conformant,
either.  But they do claim it to be complete, and if it came without an
iostream, I think you would certainly have grounds to complain.  (But I
don't think that this is the case.)

--
James Kanze                         mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orientie objet/
                        Beratung in objekt orientierter Datenverarbeitung
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany  Tel. +49 (069) 63 19 86 27

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <p6qn1zs338u.fsf@pandora.inst-inf-1.hu-berlin.de>,
  Martin von Loewis <loewis@informatik.hu-berlin.de> wrote:
> No, an implementation is free to offer extensions, and to accept code
> which should be rejected, as long as it diagnoses usage of the
> extension somehow. Implementors are free to put into std:: whatever
> they want to; the namespace std:: is completely reserved to
> implementations.
>
I don't know how you can substantiate this claim. I don't see it in standard.
Moreover, imagine this conforming program:
namespace mynamespace
{
 template<clas T>
 class rope;
 ...
}
...
using namespace mynamespace;
using namespace std;
rope<int> r;
...
This program will pass comforming compiler and will choke on the one with
extensions.

Gene.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Martin von Loewis <loewis@informatik.hu-berlin.de> writes:

>... Implementors are free to put into std:: whatever
>they want to; the namespace std:: is completely reserved to
>implementations.

That is not correct. An implementation can add things to namespace
std if they do not violate requirements of the standard. In
particular, if a user program has defined behavior under the
standard, additions to namespace std must not change that
behavior.

For example, a user is entitled to write code like this:
 #include <map>
 using namespace std;
 ...
 template<...> class hash_map { ... };
If the implementation put its own template hash_map into the <map>
header in namespace std, the valid user program might fail to
compile, or exhibit different behavior due to specializations
in the <map> header.

The implementation could provide an option to turn off the
extensions, put hash_map in a separate header, or in a
different namespace. Or it could use a name for hash_map
that is reserved to the implemenation, such as __hash_map.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3727BFA1.5631@wanadoo.fr>,
  Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> sirwillard@my-dejanews.com wrote:
>
> > Recommending one not use the
> > extensions is a silly response to this issue.
>
> Hum...
>
> > I'll have to look here, but on SGI's FAQ page they clearly state that
strings
> > are not compatible with the VC++ templated iostreams.
>
> They absolutly don't say that.

Depending on how you want to take it, yes they do.

"Are there any compatibility issues with Visual C++? Visual C++ provides its
own STL implementation, and some of the other Microsoft C++ library headers
may rely on that implementation. In particular, the SGI STL has not been
tested in combinarion with Microsoft's new <iostream> header. It has been
used successfully with the older <iostream.h> header."

Straight out it doesn't work.  However, the STLport derivatives do, at least
to some extent, though there are some issues.

> > Even if the above is true, this is a feature not provided by the SGI
> > implementation, which I would assume makes them non-compliant with the
> > standard.
>
> Again, this is a _partial_ implementation.
>
> > Again, your recommendation (to use the VC++ iostreams) is a silly
> > response to this issue.
>
> Hum... is it a personnal attack ?

Is what a personal attack?

> > Non-compliance in a library that claims compliance (and I don't mean simple
> > bugs
>
> To me bugs are serious violations of the standards !

Then you'll never find a compliant compiler or library.

> > or work arounds for compiler limitations, these are more serious
> > violations of the standard)
>
> Which ones ? (except the some small extentions ?)

I'm not sure why you ask this.  You addressed (not to my satisfaction, but
still...) both issues.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Dixitque loewis@informatik.hu-berlin.de (Martin von Loewis) in
comp.std.c++:
>No, an implementation is free to offer extensions, and to accept code
>which should be rejected, as long as it diagnoses usage of the
>extension somehow. Implementors are free to put into std:: whatever
>they want to; the namespace std:: is completely reserved to
>implementations.

I don't mean to disparage the SGI implementation, but I do have a
question about the above.

True, an implementation can offer extensions. But wouldn't it be true to
say that SGI STL is not an implementation, it is a piece of one? Seems to
me that when we use SGI STL with Brand X compiler, perhaps to replace a
poor STL implementation supplied by that compiler maker, the SGI version
is not part of "the implementation" as conceived by the standard, but is
user code. Therefore the things that SGI STL puts in namespace std that
don't belong there could cause undefined behavior, perhaps by conflicting
with an implementation's own extensions, just as I cause undefined
behavior if I define class frambule in namespace std.

Please note I am NOT arguing against use of SGI STL. The point I raise is
probably more theoretical than real, but then I find theory easier to
cope with than reality. :-)

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                                    http://www.mindspring.com/~brahms/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stan Brown wrote:
....
> I don't mean to disparage the SGI implementation, but I do have a
> question about the above.
>
> True, an implementation can offer extensions. But wouldn't it be true to
> say that SGI STL is not an implementation, it is a piece of one? Seems to
> me that when we use SGI STL with Brand X compiler, perhaps to replace a
> poor STL implementation supplied by that compiler maker, the SGI version
> is not part of "the implementation" as conceived by the standard, but is
> user code. Therefore the things that SGI STL puts in namespace std that
> don't belong there could cause undefined behavior, perhaps by conflicting
> with an implementation's own extensions, just as I cause undefined
> behavior if I define class frambule in namespace std.

No. It it compiler X plus the SGI STL which is a less than fully
conforming implementation of C++. SGI STL wouldn't be useful if it
weren't using part of the namespace that the standard reserves to the
implementation.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-dejanews.com wrote:
>
> In article <3727BFA1.5631@wanadoo.fr>,
>   Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> > sirwillard@my-dejanews.com wrote:
> >
> > > Recommending one not use the
> > > extensions is a silly response to this issue.
                      ^^^^^

> Depending on how you want to take it, yes they do.
>
> "Are there any compatibility issues with Visual C++? Visual C++ provides its
> own STL implementation, and some of the other Microsoft C++ library headers
> may rely on that implementation. In particular, the SGI STL has not been
> tested in combinarion with Microsoft's new <iostream> header. It has been
> used successfully with the older <iostream.h> header."

It says that they don't guaranty that it works, and that anyway they
don't know. It may be correct, incorrect, completely wrong, but that's
not the problem: it doesn't say that it is guarantied not to work.

> Straight out it doesn't work.

Irrelevant wrt my point

> > > Again, your recommendation (to use the VC++ iostreams) is a silly
                                                                  ^^^^^
> > > response to this issue.
> >
> > Hum... is it a personnal attack ?
>
> Is what a personal attack?

To say that my recommendations are silly.

> Then you'll never find a compliant compiler or library.

Perhaps

> > > or work arounds for compiler limitations, these are more serious
> > > violations of the standard)
> >
> > Which ones ? (except the some small extentions ?)
>
> I'm not sure why you ask this.  You addressed (not to my satisfaction, but
> still...) both issues.

I meant: do you have other issues ?

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

gbush@my-dejanews.com wrote:

> I don't know how you can substantiate this claim. I don't see it in standard.

Well, indirectly...

> Moreover, imagine this conforming program:
> namespace mynamespace
> {
>  template<clas T>
>  class rope;
>  ...
> }
> ...
> using namespace mynamespace;
> using namespace std;
> rope<int> r;
> ...
> This program will pass comforming compiler and will choke on the one with
> extensions.

Please tell me why. I don't see any problem with this program,
the only visible 'rope' name is in mynamespace.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

There's been much talk on the usenet groups about how the SGI implementation
of the STL is far superior to most others available.  I'm now in a position
where I need to question this, and ask for other's opinions on this library.

I've been happily using Dinkumware's version, since I run VC++, up until
today. We've found that the version of Dinkumware's library as shipped by
VC++ 6 is not thread safe (among other minor issues).  They've provided fixes
on their web site, but unfortunately, these fixes only work with programs
statically linked to the C RTL, and we can not do this.  They also have an
updated library available, which I assume addresses this issue (?), but the
update comes at a cost which may be a waste of money if the next version of
VC++ includes this library.  So, off I went in search of alternatives that
would be cost effective for us.  Thus my recent look at SGI's implementation,
which has once again brought up questions in my mind.

SGI's implementation has two major problems, as I see it.  Firstly, they have
a lot of extensions, such as the rope and hash_map classes.  There's nothing
wrong with extensions, but doesn't the standard require that such extensions
not be placed in the std namespace?  If not, aren't there going to be serious
conflicts if the standard ever includes similar extensions?  Having non-
standard names in the std namespace makes me queasy.

Secondly, SGI's implementation fails to provide the templated versions of the
iostream libraries.  Admittedly they claim this as an "STL" library and not
an "STD" library, and so they are not necessarily bound by the standard in
providing these classes.  However, the fact that they place things in the std
namespace would suggest they should be following the standard in this regard.
Should we be happy with vendors providing libraries that provide only a
portion of the library as defined by the standard, yet place what they do
provide in the std namespace?  I know that I'm not.  I need the features
provided by the iostream libraries as defined in the standard, and there's no
way to do so using SGI's implementation.  So I can't use their library as a
drop in replacement for that provided by my compiler.

I really fail to see why people have such praise for this library.  There are
a number of areas in which they've seemed to just say "the standard be
damned", even though their web site claims that they follow the standard
closely (what's their definition of "closely"?).

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-dejanews.com writes:
>
> SGI's implementation has two major problems, as I see it.  Firstly,
> they have a lot of extensions, such as the rope and hash_map
> classes.  There's nothing wrong with extensions, but doesn't the
> standard require that such extensions not be placed in the std
> namespace?  If not, aren't there going to be serious conflicts if
> the standard ever includes similar extensions?  Having non- standard
> names in the std namespace makes me queasy.

It may have been better if these extensions had been placed in a
different namespace, I agree. However, if you feel so strongly about
this point, you can always decide not to use hash_map or rope, or to
arrange things in such a way that your code does not assume these
extansion are in the std:: namespace.

> Secondly, SGI's implementation fails to provide the templated
> versions of the iostream libraries.

Don't know about VC++ 6, but with VC++ 5 we use the SGI STL together
with the templated iostreams that are included with the compiler. You
may want to take a look at the STL Adaptation home page for
information about getting the SGI STL to work on various platforms:

  http://www.stlport.org/

> I need the features provided by the iostream libraries as defined in
> the standard, and there's no way to do so using SGI's
> implementation.

Don't believe this is true, see above.

> I really fail to see why people have such praise for this library.
> There are a number of areas in which they've seemed to just say "the
> standard be damned"

Don't understand how you can come to this conclusion. You have raised
two issues: One was a complaint that extensions are in namespace
std. This may be undesirable, but I don't see how this can be a big
deal. The second point about iostreams, well the STL authors had to
draw the line somewhere, should they have included a complete C
library as well? And as I said, I am almost certain that you can in
fact integrate the SGI STL with the compiler's iostreams.

People praise this library because it is solid, fast, threadsafe, and
the parts of the library that are standardized in ISO C++ conform
closely to the standard.

Joachim

--
joachim@kraut.bc.ca      (http://www.kraut.bc.ca)
joachim@mercury.bc.ca    (http://www.mercury.bc.ca)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-dejanews.com writes:

> SGI's implementation has two major problems, as I see it.  Firstly, they have
> a lot of extensions, such as the rope and hash_map classes.  There's nothing
> wrong with extensions, but doesn't the standard require that such extensions
> not be placed in the std namespace?

No, an implementation is free to offer extensions, and to accept code
which should be rejected, as long as it diagnoses usage of the
extension somehow. Implementors are free to put into std:: whatever
they want to; the namespace std:: is completely reserved to
implementations.

Now, I don't know how this affects extension libraries, as far as
standards compliance is concerned. For example, it would be
inconvenient if usage of Posix headers requires a diagnosis.

> Should we be happy with vendors providing libraries that provide only a
> portion of the library as defined by the standard, yet place what they do
> provide in the std namespace?

Maybe the library is not meant for you: it certainly fits nicely into
more complete C++ libraries. For example, the GNU C++ compiler
includes a copy of SGI STL (in addition to its own iostreams
implementation), and I guess the SGI compiler comes with a copy of the
very same code.

> I need the features provided by the iostream libraries as defined in
> the standard, and there's no way to do so using SGI's
> implementation.

Why not? Just replace your vendor's STL implementation with the SGI
one, and leave the other parts of the standard library as-is.

Of course, these other parts might make use of STL, so you need to
recompile the rest of the library as well, with the new STL.

> I really fail to see why people have such praise for this library.  There are
> a number of areas in which they've seemed to just say "the standard be
> damned", even though their web site claims that they follow the standard
> closely (what's their definition of "closely"?).

They don't implement every feature (for example, they don't offer a
compiler together with STL, either). Those parts which they do
implement are meant to be "closely following". It is quite clear to me
what this means.

Regards,
Martin
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <ucbtg8s9p2.fsf@soft.mercury.bc.ca>,
  Joachim Achtzehnter <joachim@kraut.bc.ca> wrote:
>
> sirwillard@my-dejanews.com writes:
> >
> > SGI's implementation has two major problems, as I see it.  Firstly,
> > they have a lot of extensions, such as the rope and hash_map
> > classes.  There's nothing wrong with extensions, but doesn't the
> > standard require that such extensions not be placed in the std
> > namespace?  If not, aren't there going to be serious conflicts if
> > the standard ever includes similar extensions?  Having non- standard
> > names in the std namespace makes me queasy.
>
> It may have been better if these extensions had been placed in a
> different namespace, I agree. However, if you feel so strongly about
> this point, you can always decide not to use hash_map or rope, or to
> arrange things in such a way that your code does not assume these
> extansion are in the std:: namespace.

It's not a matter of it being "better", in order to be conforming shouldn't
they have done this?  I don't have the standard available to me, but I can't
see how having the standard define the std namespace is useful at all if
vendors are free to pollute it with their own extensions.  I fully believe SGI
is in non-compliance by having done this.  Recommending one not use the
extensions is a silly response to this issue.

> > Secondly, SGI's implementation fails to provide the templated
> > versions of the iostream libraries.
>
> Don't know about VC++ 6, but with VC++ 5 we use the SGI STL together
> with the templated iostreams that are included with the compiler. You
> may want to take a look at the STL Adaptation home page for
> information about getting the SGI STL to work on various platforms:
>
>   http://www.stlport.org/

I'll have to look here, but on SGI's FAQ page they clearly state that strings
are not compatible with the VC++ templated iostreams.  Unless they are
mistaken on their own page they are not complaint with the Dinkumware
iostreams as you contend here. Even if there's a work around on the port
page, this is still something I'd consider a serious issue.

> > I need the features provided by the iostream libraries as defined in
> > the standard, and there's no way to do so using SGI's
> > implementation.
>
> Don't believe this is true, see above.

Even if the above is true, this is a feature not provided by the SGI
implementation, which I would assume makes them non-compliant with the
standard.  Again, your recommendation (to use the VC++ iostreams) is a silly
response to this issue.

> > I really fail to see why people have such praise for this library.
> > There are a number of areas in which they've seemed to just say "the
> > standard be damned"
>
> Don't understand how you can come to this conclusion. You have raised
> two issues: One was a complaint that extensions are in namespace
> std. This may be undesirable, but I don't see how this can be a big
> deal. The second point about iostreams, well the STL authors had to
> draw the line somewhere, should they have included a complete C
> library as well? And as I said, I am almost certain that you can in
> fact integrate the SGI STL with the compiler's iostreams.

Non-compliance in a library that claims compliance (and I don't mean simple
bugs or work arounds for compiler limitations, these are more serious
violations of the standard) and, more importantly IMHO, uses the std namespace
is not "undesirable".  It's flat out wrong.  As for "drawing the line
somewhere"... that line shouldn't have been drawn where it was, and to do so
seems a violation of the standard.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]