C++ standard and the STL: separate standards?

[Rui Maciel]

Is there a good reason to define the STL in the same standard document that defines the C++
programming language?


Thanks in advance,
Rui Maciel

 

[Victor Bazarov]

Is there a good reason to define the STL in the same standard document that defines the C++
programming language?

There is no such thing as "STL" AFA standard C++ is concerned. There is
"language proper" - a set of syntactic and semantic rules that define
the actual language and "library" that defines a minimal set of
functions, classes, templates, objects, upon existence of which every
C++ programmer can rely. Since there are interdependencies between
those two parts, it makes sense to keep them in the same document, I
believe.

V

 

[Öö Tiib]

Is there a good reason to define the STL in the same standard document that defines the C++
programming language?

The standard library and language are defined in same document,
because some language features are implemented with keywords and other
language features with functions and templates in standard library.

It is good as one document since otherwise someone may implement
something without implementing standard library and then claim that it
is C++ programming language. C++ is powerful programming language and
best performing programs are often written in it. Therefore vendors of
platforms are tempted to use dirty tricks to achieve that C++ program
developed for their platform does not run on other platforms.

 

[Saeed Amrollahi]

Is there a good reason to define the STL in the same standard document that defines the C++
programming language?

Thanks in advance,
Rui Maciel

Hi
I searched "STL" in the last official C++ standard document (N3092-
Draft International standard)
and found nothing. As you may be know, The Container, Iterator and
Algorithm
part of C++ standard library is officially called STL after the name
used
by Alex Stepanov, The C++ standardization committee accepted the
library with its
genius design as part of C++ standard library. I like to say, the STL
is just
part of C++ standard library. C++ standard library contains the C
standard library, string
bitset, valarray, numerics and exception classes. C++0x added a lot of
things to STL part and
a lot of things not related to STL.

Regards,

 

[Juha Nieminen]

Is there a good reason to define the STL in the same standard document that defines the C++
programming language?

Yes: All compilers will implement it.

 

[Rui Maciel]

Yes: All compilers will implement it.

Compiler makers aren't necessarily forced to follow a standard's every last detail. For example,
C99 is out for a long while and there aren't that many C compilers that implement every single
feature and behavior described in that standard. Moreover, there are plenty of international
standards whose definitions span multiple parts which are published independently.


Rui Maciel

 

[Rui Maciel]

Hi
I searched "STL" in the last official C++ standard document (N3092-
Draft International standard)
and found nothing. As you may be know, The Container, Iterator and
Algorithm
part of C++ standard library is officially called STL after the name
used
by Alex Stepanov, The C++ standardization committee accepted the
library with its
genius design as part of C++ standard library.

This is an example of being needlessly pedantic while failing to address the issue.

I like to say, the STL is just
part of C++ standard library. C++ standard library contains the C
standard library, string
bitset, valarray, numerics and exception classes. C++0x added a lot of
things to STL part and
a lot of things not related to STL.

And this contributes nothing to the discussion, which is the reason why the STL should be defined
in the same standard document as the remaining aspects of the C++ programming language.


Rui Maciel

 

[Rui Maciel]

The standard library and language are defined in same document,
because some language features are implemented with keywords and other
language features with functions and templates in standard library.

Are there any components of the containers, iterators and algorithms that impose any feature that
isn't already described in the remaining C++ standard?

It is good as one document since otherwise someone may implement
something without implementing standard library and then claim that it
is C++ programming language.

Not necessarily. If the C++ programming language standard describes the C++ programming language
as the set of definitions described in, say, "ISO 14882-1 Part 1: core language" and "ISO 14882-2
Part 2: the STL" then the same language definition remains valid.

C++ is powerful programming language and
best performing programs are often written in it. Therefore vendors of
platforms are tempted to use dirty tricks to achieve that C++ program
developed for their platform does not run on other platforms.

That issue is ortogonal to of how a standard is designed.


Rui Maciel

 

[Rui Maciel]

Since there are interdependencies between
those two parts, it makes sense to keep them in the same document, I
believe.

What parts of C++'s core language depends on the definitions of the containers, iterators and
algorithms?


Rui Maciel

 

[Kai-Uwe Bux]

Is there a good reason to define the STL in the same standard document
that defines the C++ programming language?

If you are asking whether there is a compelling reason not to have the
standard published in two volumes, one of them dealing only with the library
(or let's say excluding headers like <typeinfo>, <new>, or <limits>), then
probably there is not. But that is merely a question of organizing the
clauses and finding an appropriate order. Being in one volume has the
advantage that it is slightly easier to maintain a common index. Now, even
within a single volume, one could have two parts. Come to think of it, the
core language has chapters 1-16 and the library chapters 17-27. After that
follow appendices. So the current standard is already pretty much organized
along those lines.

However, there is good reason to have _one_ committee being in charge of
maintaining and developing the standard for the core language and the same
committee also being in charge of the library. As the introduction of
variadic templates or the discussion about concepts illustrates, library
development and core language development are heavily interrelated.


Best

Kai-Uwe Bux

 

[Bo Persson]

What parts of C++'s core language depends on the definitions of the
containers, iterators and algorithms?

The compiler is allowed, but not required, to directly implement parts
or all of the library. The library chapters of the standard defines an
interface, not an implementation.

More direct interdependencies are that the new statement

x* = new x;

depends on operator new() and operator delete() defined by the library
(as well as some exception types).

The core feature dynamic_cast may throw a bad_cast exception, defined
in the library part. Would be hard, if that was defined by a separate
standard.


How does returning from main() call functions registered by atexit()?
Who flushes the files at program termination?



Bo Persson

 

[Rui Maciel]

If you are asking whether there is a compelling reason not to have the
standard published in two volumes, one of them dealing only with the
library (or let's say excluding headers like <typeinfo>, <new>, or
<limits>), then probably there is not. But that is merely a question of
organizing the clauses and finding an appropriate order. Being in one
volume has the advantage that it is slightly easier to maintain a common
index. Now, even within a single volume, one could have two parts. Come to
think of it, the core language has chapters 1-16 and the library chapters
17-27. After that follow appendices. So the current standard is already
pretty much organized along those lines.

However, there is good reason to have _one_ committee being in charge of
maintaining and developing the standard for the core language and the same
committee also being in charge of the library. As the introduction of
variadic templates or the discussion about concepts illustrates, library
development and core language development are heavily interrelated.

Thanks for the insightful post, Kai-Uwe. The reason I've brought up this subject is the time it
is taking for the new C++ standard to be completed. As this process is taking over a decade to
release a new standard, at first glance (and while completely ignoring how the process is being
conducted) it is reasonable to ask if things wouldn't run a bit smoother if this project was
divided in multiple, quasi-independent standardization projects. Moreover, if the standard was
divided in multiple parts then that would simplify the addition and renovation of separate
language components.


Rui Maciel

 

[Jerry Coffin]

Is there a good reason to define the STL in the same standard document that
defines the C++ programming language?

Yes. The specification for the standard library has to track quite
closely with the language itself. Just for example, you couldn't very
well release a specification for the standard library that required
functions to take r-value references as parameters before the spec
for the language included r-value references.

In the other direction, figuring out how to specify and implement the
standard library is a large part of what drives refinement of the
language specification. Looking at r-value references again, the
general idea was fairly apparent years ago -- but a lot of the
details were ironed out based on figuring out exactly how to use them
(and *not* use them) in the standard library. Without this feedback
loop, the circuit would be unstable (so to speak).

As such, the two would remain (fairly) tightly coupled even if they
were officially separated. The separation itself would lead to little
(if any) gain in efficiency, nor would it allow a significantly
increased independence between specifying the language and the
library.

 

[Keith H Duggar]

Is there a good reason to define the STL in the same standard
document that defines the C++ programming language?

Yes; If it weren't then C++ haters would propagandize that "STL
isn't part of C++", "C++ doesn't have a template library!", etc
which would confuse n00b sheep and lead them astray of success.

KHD

 

[Öö Tiib]

Are there any components of the containers, iterators and algorithms that impose any feature that
isn't already described in the remaining C++ standard?

No. But you need input/output part of library to make your C++
software capable to communicate with outside world. Or do you want to
leave it implementation specific? Even if you consider argv and argc
as input then sole int returned by main smells anyway like shit?
Traits, memory management and exceptions impose such language features
that are only accessible using standard library (if you do not want to
use some platform/implementation specific methods). It will go even
further once threads, synchronization primitives and so on are added
into standard.

Not necessarily.  If the C++ programming language standard describes the C++ programming language
as the set of definitions described in, say, "ISO 14882-1 Part 1: core language" and "ISO 14882-2
Part 2: the STL" then the same language definition remains valid.

C++ library is *not* STL.

Standard describes only interface and behavior of C++ library. The
library has to be implemented by compiler vendor. Compiler vendor may
of course take some existing portable implementation but it will have
then all the portability overhead in it too and so it is most likely
bad way to go.

STL however is a real piece of software. STL is made by two smart
enthusiasts. Alexander Stepanov and Meng Lee. They first made it for
some software house they worked for like AT&T or HP and later released
it into public domain, where other enthusiasts have been improving it.
Someone proposed to standard commitee to include *parts* of that STL
interface into standard library and committee pondered it and
accepted. STL is somewhat like boost. Boost is only bigger portable
implementation of useful libraries and it is made by lot more
enthusiasts. Some pieces of boost have also been proposed as parts for
standard library and like we all see these are on the way to standard.

That issue is ortogonal to of how a standard is designed.

Yes. But splitting language standard into small pieces helps to muddy
it up and we all will lose in the process. If you want them to be
separate then take the draft print it out and put the pages describing
library (§17-§27) into other pile. Then you will have them separated.