John Max Skaller (maxtal@Physics.usyd.edu.au) wrote:
: In article <3k1p9o$drf@jupiter.SJSU.EDU>,
: Cay Horstmann <horstman@sjsumcs.sjsu.edu> wrote:
: >
: >Early libraries like NIH didn't succeed because they had NO
: >parameterization. STL may have too much.

:  Yes. But that is a good thing for a Standard Library
: because it is possible to _use_ STL to build a more constrained
: system for end users.

:  This is _much_ better than a system constrained so that
: end users get 90% of their work done safely and conveniently
: and spend the other 90% of their time trying to work around
: the constraints when they aren't appropriate.

No. I don't think that is a good idea for a standard library to be completely
general (and I am not sure it is the goal that Stepanov and Lee had in
mind). A standard library ought to strike a balance between usability and
generality that is comfortable for the majority of users.

If the library is too general, users will spend a lot of time creating
mutually incompatible specializations of mediocre quality. Look at X where
the mantra is "we give mechanism but no policy". On my Unix
system, as a result I have the choice of 4 window managers, each of which
is quite lousy compared to (gasp) the Windows 3.1 interface. This mess
necessitated a new standard (CDE) that strikes a better balance between
generality and usability.

Cay

In article <3kbkt3$mln@hustle.rahul.net>, "Ronald F. Guilmette" <rfg@rahul.net> writes:
|> In article <3k1p9o$drf@jupiter.SJSU.EDU>,
|> Cay Horstmann <horstman@sjsumcs.sjsu.edu> wrote:
|> >John Barton (jjb@watson.ibm.com) wrote:
|> >
|> >:     Templates provide strong, early type and syntax checking every bit
|> >: as much as inheritance and virtual functions.  Please do not propagate
|> >: the idea the templates in some way ignore type checking.
|> >
|> >Well, in C++ this is only partially true. IF in fact your program is
|> >correct, then the compiler (assuming it is conforming) will compile it.
|> >If it isn't, you will get totally crazy error messages from somewhere deep
|> >in the instantiation process. Surely every STL user has run into that.
|> >
|> >That is because C++ templates do not specify any requirements for the
|> >instantiation types. The rule is that T is a legal type if we try it and
|> >it doesn't break. Other programming languages manage to do better in this
|> >regard.
|>
|> Cay has provided a very good summary.

   No, I think Cay has summarized his experience with poor quality
error messages in the C++ implementations he has used.  I have used
templates extensively and I complained to my compiler vendor daily for
months on end about template problems.  (Ok, I had an especially easy
way to complain since I knew the developers).  Many of the problems were
solved, making templates much easier to use in our compiler.  If we quit
blaming the language and start blaming the compilers, we will get much
further on this issue.

|>
|> In the early days of templates (i.e. the cfront implementation) we didn't
|> even get any syntax checking of templates until instantiation time.  This
|> caused me (among others) to decry C++ templates as merely ``glorified macros''.
|>
|> Now it seems that the forthcoming standard _will_ (thank God) require
|> compilers to perform at least syntax checking of template definitions
|> when they are first scanned/compiled.  But there will still be no
|> requirement for detailed semantic checking of template definitions
|> in the absence of corresponding instantiations... nor could there be,
|> given the nature of C++ templates.
|>
|> As Cay has said, the only rule is ``If, when you instantiate it, it is
|> semantically incorrect, then it is semantically incorrect.''
|>
|> --
|>
|> -- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
|> ---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
|> -------------------------------------------- Suites and Bullet-Proof Shoes -

--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

In article <3k1p9o$drf@jupiter.SJSU.EDU>,
Cay Horstmann <horstman@sjsumcs.sjsu.edu> wrote:
>John Barton (jjb@watson.ibm.com) wrote:
>
>:     Templates provide strong, early type and syntax checking every bit
>: as much as inheritance and virtual functions.  Please do not propagate
>: the idea the templates in some way ignore type checking.
>
>Well, in C++ this is only partially true. IF in fact your program is
>correct, then the compiler (assuming it is conforming) will compile it.
>If it isn't, you will get totally crazy error messages from somewhere deep
>in the instantiation process. Surely every STL user has run into that.
>
>That is because C++ templates do not specify any requirements for the
>instantiation types. The rule is that T is a legal type if we try it and
>it doesn't break. Other programming languages manage to do better in this
>regard.

Cay has provided a very good summary.

In the early days of templates (i.e. the cfront implementation) we didn't
even get any syntax checking of templates until instantiation time.  This
caused me (among others) to decry C++ templates as merely ``glorified macros''.

Now it seems that the forthcoming standard _will_ (thank God) require
compilers to perform at least syntax checking of template definitions
when they are first scanned/compiled.  But there will still be no
requirement for detailed semantic checking of template definitions
in the absence of corresponding instantiations... nor could there be,
given the nature of C++ templates.

As Cay has said, the only rule is ``If, when you instantiate it, it is
semantically incorrect, then it is semantically incorrect.''

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -

In article <MATT.95Mar13221305@physics2.berkeley.edu>,
Matt Austern <matt@physics.berkeley.edu> wrote:
>Yep.  I think we've all had painful experiences with templates, trying
>to figure out just why we got that mysterious error message at link
>time, what it's doing coming from debugged library code that came from
>the compiler vendor, and what in the world it has to do with the code
>we wrote.
>
>Part of this is because templates are immature: compiler vendors
>haven't yet learned how to implement templates in such a way that
>you get sensible error messages.  Only part, though.  Part of it
>has to do with the language itself.

I think that you are not giving the implementors enough credit here.

At the recnt Austin meeting of X3J16/WG21, it was noted that there are
still some very serious problems with the lanaguge definition when it
comes to the model for instantiation of templates.

I'm not saying that the implementors couldn't do better.  Undoubtedly
some could.  But if what I was told is true, there are remaining problems
in the languages definition itself which make some aspects of template
instantiation essentially insoluable.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -

In article <3k1p9o$drf@jupiter.SJSU.EDU>,
Cay Horstmann <horstman@sjsumcs.sjsu.edu> wrote:
>
>Early libraries like NIH didn't succeed because they had NO
>parameterization. STL may have too much.

 Yes. But that is a good thing for a Standard Library
because it is possible to _use_ STL to build a more constrained
system for end users.

 This is _much_ better than a system constrained so that
end users get 90% of their work done safely and conveniently
and spend the other 90% of their time trying to work around
the constraints when they aren't appropriate.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

John Barton (jjb@watson.ibm.com) wrote:

:     Templates provide strong, early type and syntax checking every bit
: as much as inheritance and virtual functions.  Please do not propagate
: the idea the templates in some way ignore type checking.

Well, in C++ this is only partially true. IF in fact your program is
correct, then the compiler (assuming it is conforming) will compile it.
If it isn't, you will get totally crazy error messages from somewhere deep
in the instantiation process. Surely every STL user has run into that.

That is because C++ templates do not specify any requirements for the
instantiation types. The rule is that T is a legal type if we try it and
it doesn't break. Other programming languages manage to do better in this
regard.

I think this is an important drawback of templates, and for the library
users' sake, it makes sense not to overuse them.

Consider STL's templates. Parameterization on the container type is
necessary and beneficial. Parameterization on the comparison function is
less convincing. You have an infinitesimal gain in efficiency, combined
with huge code bloat and crazy error messages when the comparison type
isn't just right. Parameterization on the iterators is pretty dangerous
since the compiler CANNOT DO INTELLIGENT COMPILE-TIME CHECKING. (No
flames--I know the excuse is that the algorithms have to work for C arrays
as well.)

Early libraries like NIH didn't succeed because they had NO
parameterization. STL may have too much.

Cay
horstman@cs.sjsu.edu

In article <3k1p9o$drf@jupiter.SJSU.EDU> horstman@sjsumcs.sjsu.edu (Cay Horstmann) writes:

> That is because C++ templates do not specify any requirements for the
> instantiation types. The rule is that T is a legal type if we try it and
> it doesn't break. Other programming languages manage to do better in this
> regard.

Yep.  I think we've all had painful experiences with templates, trying
to figure out just why we got that mysterious error message at link
time, what it's doing coming from debugged library code that came from
the compiler vendor, and what in the world it has to do with the code
we wrote.

Part of this is because templates are immature: compiler vendors
haven't yet learned how to implement templates in such a way that
you get sensible error messages.  Only part, though.  Part of it
has to do with the language itself.

I'd really like to see some sort of constrained genericity for C++
templates (like Eiffel has), or else something like gcc's signatures.

--

                               --matt

John Max Skaller (maxtal@Physics.usyd.edu.au) wrote:
: In article <3jktcc$m17@panix3.panix.com>,
: Timothy Murphy <tmurphy@panix.com> wrote:
: >
: >   I'm not arguing that STL is poorly defined.  In fact, I find it very
: >well thought out and quite beautiful.  It does however represent a
: >quite extreme style of programming:

:  Of course it does. It has a very specific architecture.

: >It provides no run-time polymorphism
: >whatsoever and has the tendency to turn your entire program into a
: >collection of templates.

:  That is the modern use of C++. Template polymorphism
: is not only FASTER than dynamic binding, it is considerably
: more powerful.

   Templates are not better or worse than virtual functions; they're
different.  I appreciate and use both approaches to polymorphism.
Templates alone cannot handle heterogeneous aggregates.

: >Inheritance and virtual functions provide strong,
: >early type and syntax checking as well as run-time capability that
: >is completely absent with templates.

:  Inheritance based libraries in strongly statically typed
: NAME based systems have been found in practice to be impossible to
: use on a component by component basis.

   I have half-developed an extremely refined container heterarchy all
of whose non-leaf classes are _abstract_ and found it quite usable.  The
only real problems I have had have been with compiler implementations:
cfront botches method dispatch on intermediate classes; cfront and GNU
(and perhaps others) put pointers to virtual bases inside the body of
an object.  The latter practice produces _huge_ objects in heterarchies
of any depth; object size is roughly quadratic in the depth/breadth of
a heterarchy.  Are there any extant compilers sane enough to instead
use implicit vtable entries containing offsets to virtual bases?
This would make refined heterarchies much more efficient.

:  That is, such libraries are monolithic and invasive
: and do not cooperate with each other. This is not true in dynamic
: signature based systems (like Smalltalk) which use a messaging
: protocol.

   Why not include signatures (a la GNU) in C++?  They are easy to
understand, easy to use, and easy to implement.  They have obvious
applicability to the "gluing" of indepedently developed libraries.

: >Total omission of run-time
: >polymorphism in _the_ standard container library is an undeniably
: >extreme posture.

:  Yes. It leaves the use of dynamic binding where it
: belongs -- in the hands of users who can trade off the
: invasiveness and loss of interoperability with the needs
: of particular applications.

:  That seems to be correct to me.

: >Pushed far enough, templates produce enormous
: >executables, huge compile times, and can easily break all extant
: >compilers.

:  Pushed far enough -- using full mixin technology --
: virtual function polymorphism proves completely inadequate
: both functionally and structurally.

:  VFpmorphism cannot bind on more than one argument
: (the object) and so is useless for many practical
: problems (which tend to deal with relationships -- i.e.
: require binding on more than one argument).

   No one tool is the solution to all problems.  Virtual functions and
templates both have serious advantages and limitations.

: ...

---tim

In article <3jns3q$n19@panix3.panix.com>,
Timothy Murphy <tmurphy@panix.com> wrote:
>John Max Skaller (maxtal@Physics.usyd.edu.au) wrote:
>
>:  That is the modern use of C++. Template polymorphism
>: is not only FASTER than dynamic binding, it is considerably
>: more powerful.
>
>   Templates are not better or worse than virtual functions; they're
>different.  I appreciate and use both approaches to polymorphism.

 Me too.

>Templates alone cannot handle heterogeneous aggregates.

 Neither can virtual functions. Heterogeneity requires
discriminated unions (static form) or direct access to
RTTI (dynamic cast, etc).

>:  Inheritance based libraries in strongly statically typed
>: NAME based systems have been found in practice to be impossible to
>: use on a component by component basis.
>
>   I have half-developed an extremely refined container heterarchy all
>of whose non-leaf classes are _abstract_ and found it quite usable.

 Of course you did. You built it to your requirements.
Similarly I find my graphics library quite useable.

 The issue is whether your library is like a toolkit,
from which you can select components without dragging a whole
lot of extra structure in.

 With templates, and STL in particular, a routine
like "copy" just requires you supply arguments which
have particular syntactic forms (signatures) defined.
You can define those forms as you please.

 With a VF based library, the algorithms work
on classes derived from a _specific_ abstract class,
and you have to derive an instance from _that_ class.

 For example I have "copyRect" which copies a rectangle
from one image to another. In particular, from any class
derived from ROImg (Read Only Image) to any class derived
from RWImg (Read Write Image).

 So you can't use my copyRect routine unless your
image classes are derived from classes in my library.

 There is not doubt this tight coupling has advantages:
safety is one of them. But the result is a more closed
architecture than the kind STL provides.

>The
>only real problems I have had have been with compiler implementations:
>cfront botches method dispatch on intermediate classes; cfront and GNU
>(and perhaps others) put pointers to virtual bases inside the body of
>an object.  The latter practice produces _huge_ objects in heterarchies
>of any depth; object size is roughly quadratic in the depth/breadth of
>a heterarchy.  Are there any extant compilers sane enough to instead
>use implicit vtable entries containing offsets to virtual bases?
>This would make refined heterarchies much more efficient.

 AFAIK Sun 4.0 does this. For images, I don't care.
The images of concern are of megabyte order.

>:  That is, such libraries are monolithic and invasive
>: and do not cooperate with each other. This is not true in dynamic
>: signature based systems (like Smalltalk) which use a messaging
>: protocol.
>
>   Why not include signatures (a la GNU) in C++?

 The real problem is that there probably isn't "space"
in Standard C++ for templates, virtual functions, _and_ signatures.

 Signatures are very interesting, providing compact code
at the expense of loss of efficiency due to run-time binding,
and losing the safety of name bound typing to widen the
domain of applicability.

>They are easy to
>understand, easy to use, and easy to implement.  They have obvious
>applicability to the "gluing" of indepedently developed libraries.

 Yes, they're half way between templates and virtual
functions. Closely related to pointers to members.

>:  VFpmorphism cannot bind on more than one argument
>: (the object) and so is useless for many practical
>: problems (which tend to deal with relationships -- i.e.
>: require binding on more than one argument).
>
>   No one tool is the solution to all problems.  Virtual functions and
>templates both have serious advantages and limitations.

 Of course. But the issue here is what is appropriate for
the C++ Standard Library, which is not intended to solve all problems,
or even provide tools appropriate for all problems.

 Instead, it needs to provide a "space" in which other people
can write tools which cooperate -- to achieve reusability.

 STL provides that "space" in a very general and open way:
it acts not as an instance of C++ but a extension of the language
itself. As such it is less general than full C++, but not _too_
specific -- which excessive VF p'morphism seems to imply, due to
the tight coupling inheritance imparts to systems.

 For example I may use STL to implement some of the
algorithms of my graphics library. I have, for example,
a need to maintain a set of polygons with some associated
information. The interactive editor used to build that
set could benefit greatly from the STL algorithms and containers.

 The polygons themselves, however, are not data structures
but objects in the OO sense.

SUMMARY: to build OO systems quickly, you need a high level language.
C++ is not a high level language. C++ with STL isn't either, but
it is somewhat more "complete" and higher level than raw C++.

STL is only one step away from C++. Thats why it is the correct
thing to add to the Standard Library.

My graphics library is 10 steps more specific. Which is why it
_isn't_ a good thing to add to the Standard Library.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3jktcc$m17@panix3.panix.com>, tmurphy@panix.com (Timothy Murphy) writes:
|>
|> mat@mole-end.matawan.nj.us wrote:
|> : In article <3jfiis$m4h@panix3.panix.com>, tmurphy@panix.com (Timothy Murphy) writes:
|> : >
[ some material on the main topic deleted.]
|>
|>    I'm not arguing that STL is poorly defined.  In fact, I find it very
|> well thought out and quite beautiful.  It does however represent a
|> quite extreme style of programming:  It provides no run-time polymorphism
|> whatsoever and has the tendency to turn your entire program into a
|> collection of templates.  Inheritance and virtual functions provide strong,
|> early type and syntax checking as well as run-time capability that
|> is completely absent with templates.

    Templates provide strong, early type and syntax checking every bit
as much as inheritance and virtual functions.  Please do not propagate
the idea the templates in some way ignore type checking.  There are
only two things that you can do with inheritance and virtual functions
that you cannot do with templates.  First you can mix different objects
types on a single list by holding base-class-type pointers to the objects.
Second, you can work with C++ compiler tools designed for compiling C.

|>                                        Total omission of run-time
|> polymorphism in _the_ standard container library is an undeniably
|> extreme posture.  Pushed far enough, templates produce enormous
|> executables, huge compile times, and can easily break all extant
|> compilers.

   Container libraries based on inheritance and virtual functions have
been around for a long time.  None has found widespread acceptance.
Perhaps a free, widely supported library would change this.  It is also
possible that too many compromises are required to use these container
libraries.  They do not provide enough benifit for their costs.

|>
|>    Many people programmed for many years quite happily in C before it
|> was enshrined in an international standard.

--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

In article <3jfiis$m4h@panix3.panix.com>, tmurphy@panix.com (Timothy Murphy) writes:
>
> Libraries.
>
>    Looking at the draft specification of 20 September 1994, it seems to
> me that specification of most of the libraries is wildly premature.
> At least in the realm of Unix compilers, I have yet to see a working
> implementation of STL, strings, the new stream stuff ... Two thirds
> of the document is devoted to the library specification and I think
> that there is simply not enough experience in the user committee for
> these libraries to be enshrined in an ANSI specification.  I, for one,
> would support a long delay on the definition of the libraries and
> would strongly encourage the language committee to focus on C++ itself.

This is simply not true.

What _is_ true is that there STL has outstripped the ability of most
vendors to get compilers out.  The same thing happened with Barton and
Nachman, who had IBM's Cset++ compiler group trying to stay ahead of them.

The long delay isn't practical.  For a number of reasons, economic,
political (meaning international politics involving the governments of
various nations) and technical, this work will be done now or will not
be attempted for at least five years.

The most vexing nitpicker on the ANSI/ISO committee has recently written
(in intra-committee mail) that the sort of nits that he is reduced to
picking with STL indicates that that `clause' of the working paper is in
very, very good shape.
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
 (Training and consulting in C, C++, UNIX, etc.)

In article <3jktcc$m17@panix3.panix.com>,
Timothy Murphy <tmurphy@panix.com> wrote:
>
>   I'm not arguing that STL is poorly defined.  In fact, I find it very
>well thought out and quite beautiful.  It does however represent a
>quite extreme style of programming:

 Of course it does. It has a very specific architecture.

>It provides no run-time polymorphism
>whatsoever and has the tendency to turn your entire program into a
>collection of templates.

 That is the modern use of C++. Template polymorphism
is not only FASTER than dynamic binding, it is considerably
more powerful.

>Inheritance and virtual functions provide strong,
>early type and syntax checking as well as run-time capability that
>is completely absent with templates.

 Inheritance based libraries in strongly statically typed
NAME based systems have been found in practice to be impossible to
use on a component by component basis.

 That is, such libraries are monolithic and invasive
and do not cooperate with each other. This is not true in dynamic
signature based systems (like Smalltalk) which use a messaging
protocol.

>Total omission of run-time
>polymorphism in _the_ standard container library is an undeniably
>extreme posture.

 Yes. It leaves the use of dynamic binding where it
belongs -- in the hands of users who can trade off the
invasiveness and loss of interoperability with the needs
of particular applications.

 That seems to be correct to me.

>Pushed far enough, templates produce enormous
>executables, huge compile times, and can easily break all extant
>compilers.

 Pushed far enough -- using full mixin technology --
virtual function polymorphism proves completely inadequate
both functionally and structurally.

 VFpmorphism cannot bind on more than one argument
(the object) and so is useless for many practical
problems (which tend to deal with relationships -- i.e.
require binding on more than one argument).

 And, because it is name based, functionally
equivalent entities are incompatible.

 Templates, on the other hand, are signature based
(they work for any class with the right member functions)
and so are not as safe -- but far less structure needs to
be specified to use them, and their domain of applicability
is wider.

 For example: my graphic library uses VFP'morphism.
If you use it, you have to use suitable driver objects,
and you are locked into the protocol I define.

 You can't fiddle with the screen using any other
code because my library would loose track of what was
happening.

 Take it all, or leave it all.

 STL, you can use just ONE algorithm. Or just
use a Vector<char>. You can even use my STL compliant
string class, or my (under development) safe anchored iterators.
And all the bits will work together.

 What is STL? Take out all the algorithms, remove all
the containers. You still have STL -- no code, no templates,
no nothing.

 STL is not a library. Its a Standard.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3jkvbd$no0@panix3.panix.com>,
Timothy Murphy <tmurphy@panix.com> wrote:

>... Standardizing the C++ language today, given the rate-of-change of
>its de facto ARM standard is frightening, though perhaps justifiable.
>Standardizing libraries that, for all intents and purposes, do not
>exist and have not been used is insane.  We may be building ourselves
>a straightjacket.

 But STL does exist. I'm using it right now.
It works as advertised. It is simple to use once you overcome
the initial "information overload" by trying a few examples.
It is simple -- if a bit laborious -- to design your own
iterators and containers, but very easy to write algorithms.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3jkvbd$no0@panix3.panix.com> tmurphy@panix.com (Timothy Murphy) writes:

> ... Standardizing the C++ language today, given the rate-of-change of
> its de facto ARM standard is frightening, though perhaps justifiable.
> Standardizing libraries that, for all intents and purposes, do not
> exist and have not been used is insane.  We may be building ourselves
> a straightjacket.

It may be insane, yes, but standardizing an object-oriented language
without providing a standard library would be even more insane.  The
lack of a standard library up to now has hurt C++ very badly.

Note that the distinction between a library and a language is always
blurry; in C++, it's getting blurrier.  Are classes like Bad_cast and
xalloc (or whatever those classes are called in the latest draft) part
of the language, or part of the library?  Think hard before you
answer.

Finally, there's one additional reason why you should write the
standard library in conjunction with designing the language: that way,
the needs of the library can influence language design.  That's
important.  If the language makes it difficult to write a good library
then the language is deficient, and it's important to recognize and
rectify that deficiency as soon as possible.
--

                               --matt

mat@mole-end.matawan.nj.us wrote:
: In article <3jfiis$m4h@panix3.panix.com>, tmurphy@panix.com (Timothy Murphy) writes:
: >
: > Libraries.
: >
: >    Looking at the draft specification of 20 September 1994, it seems to
: > me that specification of most of the libraries is wildly premature.
: > At least in the realm of Unix compilers, I have yet to see a working
: > implementation of STL, strings, the new stream stuff ... Two thirds
: > of the document is devoted to the library specification and I think
: > that there is simply not enough experience in the user committee for
: > these libraries to be enshrined in an ANSI specification.  I, for one,
: > would support a long delay on the definition of the libraries and
: > would strongly encourage the language committee to focus on C++ itself.

: This is simply not true.

: What _is_ true is that there STL has outstripped the ability of most
: vendors to get compilers out.  The same thing happened with Barton and
: Nachman, who had IBM's Cset++ compiler group trying to stay ahead of them.

: The long delay isn't practical.  For a number of reasons, economic,
: political (meaning international politics involving the governments of
: various nations) and technical, this work will be done now or will not
: be attempted for at least five years.

: The most vexing nitpicker on the ANSI/ISO committee has recently written
: (in intra-committee mail) that the sort of nits that he is reduced to
: picking with STL indicates that that `clause' of the working paper is in
: very, very good shape.
: --

   I'm not arguing that STL is poorly defined.  In fact, I find it very
well thought out and quite beautiful.  It does however represent a
quite extreme style of programming:  It provides no run-time polymorphism
whatsoever and has the tendency to turn your entire program into a
collection of templates.  Inheritance and virtual functions provide strong,
early type and syntax checking as well as run-time capability that
is completely absent with templates.  Total omission of run-time
polymorphism in _the_ standard container library is an undeniably
extreme posture.  Pushed far enough, templates produce enormous
executables, huge compile times, and can easily break all extant
compilers.

   Many people programmed for many years quite happily in C before it
was enshrined in an international standard.

  ...somehow the end of my last post got dropped ...

... Standardizing the C++ language today, given the rate-of-change of
its de facto ARM standard is frightening, though perhaps justifiable.
Standardizing libraries that, for all intents and purposes, do not
exist and have not been used is insane.  We may be building ourselves
a straightjacket.

---tim

In article <3jfiis$m4h@panix3.panix.com>,
Timothy Murphy <tmurphy@panix.com> wrote:
>
>Libraries.
>
>   Looking at the draft specification of 20 September 1994, it seems to
>me that specification of most of the libraries is wildly premature.
>At least in the realm of Unix compilers, I have yet to see a working
>implementation of STL,

 You can always buy an _advanced_ computer (A PC).
STL seems to run fine under Borland 4.0.


>strings, the new stream stuff ... Two thirds
>of the document is devoted to the library specification and I think
>that there is simply not enough experience in the user committee for
>these libraries to be enshrined in an ANSI specification.

 ANSI/ISO or just plain ISO please.

>I, for one,
>would support a long delay on the definition of the libraries and
>would strongly encourage the language committee to focus on C++ itself.

 Several National Bodies agree with you. (France and New Zealand).
Others (Australia) probably would not oppose a split. However,
some may strongly oppose a split.

 I tend to feel that the Library is in fact BETTER
specified and more stable than the core language, especially some
of the new features like namespaces and templates.

 So I think I'd be happy to Standardise the Library now,
and see a delay Standardising the core language :-)

 I good compromise seems to be to do both together.
Which is what the committee is currently attempting.

 PS: I think Libraries are easier to specify because

 1) the specification is in terms of C++ itself and is thus
 easier to make precise

 2) the semantics are testable by implementation
 not just theoretical analysis (libraries are easer to code
 than compilers)

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Libraries.

   Looking at the draft specification of 20 September 1994, it seems to
me that specification of most of the libraries is wildly premature.
At least in the realm of Unix compilers, I have yet to see a working
implementation of STL, strings, the new stream stuff ... Two thirds
of the document is devoted to the library specification and I think
that there is simply not enough experience in the user committee for
these libraries to be enshrined in an ANSI specification.  I, for one,
would support a long delay on the definition of the libraries and
would strongly encourage the language committee to focus on C++ itself.


-- Timothy S. Murphy: A serious user and admirer of C++.
   tmurphy@panix.com