To begin with, my use of the word "obtuse" was quite correct. My Webster's
10th Collegiate defines one meaning for obtuse as: "Difficult to comprehend:
not clear or precise in thought or expression." And that is exactly what I
meant to say. I suggest some people might want to consult their dictionaries
before criticizing someone else's English, much as they expect people to
consult the Standard before asking questions about C++.

Please take the following in the light of constructive criticism from
someone who does not have an emotional connection to the Standard. I respect
the work of the Committee.

Be that as it may, I believe that the Standard would be most improved by its
reorganization into a well-designed hypertext document, linking related
sections to provide a better presentation of complete concepts. I could, if
anyoen is interested, work up an example.

To the extent possible, the library section should be separated into a
different document. The language itself is largely (but not completely, as
evidence by the discussion of "new") a separate issue from the class
library. This is especially true of the Standard implementation of
containers. I think the document lacks focus; division would allow separate
subcommittees to concentrate on specific sections of the document.

The document should also include the relevent sections of the C standard;
the C++ Standard appears to assume that its readers are experienced C
programmers -- and that is a disservice in today's world, where programmers
often *begin* with C++.

I don't like the typography, especially in the library section. Members
should be "outdented", text regarding them indented, with better use of
fonts to highlight the document's structure.

Are those specific enough, Pete? ;}

--
    Scott Robert Ladd
    Coyote Gulch Productions
    srladd@frontier.net
    http://www.frontier.net/~srladd
---
[ 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              ]

Scott Robert Ladd wrote:
>
> Be that as it may, I believe that the Standard would be most improved by its
> reorganization into a well-designed hypertext document, linking related
> sections to provide a better presentation of complete concepts. I could, if
> anyoen is interested, work up an example.

There's already an example:
http://www.dinkumware.com/htm_stl/index.html. Maintaining a document
like that while the working paper is changing under foot is a great deal
of work. I think you just added about two years to the time it will take
to produce a standard.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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 <930235591.934.103@news.remarQ.com>,
Scott Robert Ladd <srladd@frontier.net> wrote:

> Be that as it may, I believe that the Standard would be most improved by its
> reorganization into a well-designed hypertext document, linking related
> sections to provide a better presentation of complete concepts. I could, if
> anyoen is interested, work up an example.

I'm sure that a lot of people on the committee would agree with you.
Unfortunately, we can't do it.  The official form of the standard
is a paper document, and I am quite sure that ISO would not have
permitted us to produce an alternative document that is not the standard,
but is intended to be used instead of the standard.
--
    Andrew Koenig
    ark@research.att.com
    http://www.research.att.com/info/ark



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

"Scott Robert Ladd" <srladd@frontier.net> writes:

>To the extent possible, the library section should be separated into a
>different document.

That would double the amount of administrative work necessary to
produce the standard. Two documents mean two statements of work,
two sets of international votes to approve the statements of work,
two sets of approving and issuing drafts for approval,
two sets of public comment periods and responses to them, two
sets of international voting with two sets of responses to
objections by national bodies, two documents to be ordered
when you want a copy of "the" standard, etc.

I don't see what advanage would be gained in exchange for
the extra work. Maybe you could explain. You can alway split
your copy of the standard into two parts if you want.

>I think the document lacks focus; division would allow separate
>subcommittees to concentrate on specific sections of the document.

Whatever focus is lacking is BECAUSE is was worked on in two or
more sections by separate subcommittees. Even relatively late
drafts were found to have missing (or inconsistent) parts because
each subcommittee thought some other subcommittee was (or was
not) working on that part.

>The document should also include the relevent sections of the C standard;

That suggestion seems at odds with your earlier one to split the
standard into two parts. In a sense it IS split into two parts:
the C part and the C++ part. Well, I'm half joking here. You
probably want the language parts of both C and C++ in one document,
and the library parts in another.

Seriously, we did consider for quite some time whether to include
the contents of the C standard in the C++ standard, or to include
the C standard by reference and explain what was different in C++.
Each method has its advantages.

In the end, we decided to include the C standard (and its 1985
amendment) by reference.  Standards normally do refer to other
standards, for reasons similar to splitting a program into
separate modules.  The C++ standard refers to two other
international standards as well.  Parts of the C++ standard cannot
be comprehended without referring to them as well. Even if we drew
the line at just the C standard and the amendment, the C++ standard
would be at least 500 pages longer.

>the C++ Standard appears to assume that its readers are experienced C
>programmers -- and that is a disservice in today's world, where programmers
>often *begin* with C++.

The standard does not, and should not, attempt to address the needs
of beginners.  Any standard assumes you have considerable
background. Just as the C++ standard assumes the contents of the
C standard, it assumes the contents of the ISO vocabulary standard.
Even the non-technical English vocabulary of the C++ standard is
extensive.

If we had tried to write to a lower level of experience, the result
would resemble a tutorial more than a reference.  It would lack the
conciseness and precision necessary in a reference work. It would
become less useful, or even useless, for its intended purpose.

>I don't like the typography, especially in the library section. Members
>should be "outdented", text regarding them indented, with better use of
>fonts to highlight the document's structure.

I don't like the library layout either. It is hard to find where
the description of a function starts and ends. I don't remember
why nothing better was devised. I'm sure ISO layout rules were
a contributing factor.

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

Scott Robert Ladd wrote in message <930235591.934.103@news.remarQ.com>...
>To begin with, my use of the word "obtuse" was quite correct. My Webster's
>10th Collegiate defines one meaning for obtuse as: "Difficult to
comprehend:
>not clear or precise in thought or expression." And that is exactly what I
>meant to say.

Your interpretation of Webster's implies that the document is a thinking
organism. It is not. "Obtuse" is a characteristic that in common usage and
throughout literature is attributed to people and not to inanimate things
such as language standard documents. As I said before, however, yours is a
common error. It is through such common errors that language mutates and
such changes are accepted into common usage. That's how "data" got to be a
singular noun and "initializer" became a word. (The jury is still out on
"stringizing" with me voting guilty.) So perhaps in a future edition,
Webster's will agree with you. Until then, I will not. Nor will I comment on
it further. Some other obtuse person may have the last word and offer a
different abstruse opinion.

That said, as one who is not a committee member but has publically both
criticised and praised the committee's product, and as one who has spent a
great deal of time using and studying the document under fire, I think I am
particularly, if not uniquely, qualified to address the issues you raise.
So, with the committee's permission, or without it, here goes.

>Be that as it may, I believe that the Standard would be most improved by
its
>reorganization into a well-designed hypertext document, linking related
>sections to provide a better presentation of complete concepts. I could, if
>anyoen is interested, work up an example.

The document faithfully references, by paragraph number, the text that is
related to a current discussion. This particular criticism, therefore, is
not of the document itself, which is organized as if it was hard copy, but
the medium in which it is delivered to you electronically. I, too, wish that
ANSI would have put links into the PDF file, assuming that PDF supports
links. Given that they did not, it is only a small effort to use the
automatic table of contents (the 2nd toolbutton from the left on the
toolbar) to go to the referenced section. What is really missing is a "back"
button, which itself would be unnecessary if the PDF reader would let me
have multiple copies running, which it does not, the fault of Adobe, not
ANSI. All that notwithstanding, the PDF document is much easier to navigate
than hard copy would be.

>To the extent possible, the library section should be separated into a
>different document.

I see no point in placing chapters (clauses?) 17 - 27 in a separate
document. Every one of those chapters has the word "library" in its title,
they are contiguous and they are about the libraries. None of chapters 1 -
16 have the word "library" in their titles, they are contiguous, and they
are not about the libraries. I find no fault with this organization.

>The language itself is largely (but not completely, as
>evidence by the discussion of "new") a separate issue from the class
>library.

And they are separated from each other in the document. The discussion here
of "new" centers around the confusion between "new operator" and "operator
new" and the unfortunate coincidence of their names. That's more a criticism
of the language than of the document. Both discussions are properly placed
in the document.

>This is especially true of the Standard implementation of
>containers.

Containers are addressed in one chapter. How much more separate could the
discussion be?

>I think the document lacks focus; division would allow separate
>subcommittees to concentrate on specific sections of the document.

I'll leave it to the subcommittee members to comment on whether the current
organization and focus created such problems with their concentration. As a
user, it does not present a problem to me.

>The document should also include the relevent sections of the C standard;


Well, as far as the core language goes, the document thoroughly defines the
language. It says what "int" and "for" mean, for example. Perhaps you can be
more specific and point to something that is missing. Being a C/C++
programmer, I might not have noticed where a vital specification is lacking.
We tend not to miss that which we take for granted.

The document quite properly leaves the library specification to the C
document so that the two documents may enjoy their own ANSI-mandated cycles
of evolution and publication. To include the C spec in the C++ spec would
create an unadministrable effort that would almost guarantee that the C++
spec would always be out of date and out of sync with the C spec.

>the C++ Standard appears to assume that its readers are experienced C
>programmers -- and that is a disservice in today's world, where programmers
>often *begin* with C++.

The C++ Standard also assumes that its readers are experienced C++
programmers. It is not meant to be a C++ textbook. It is a language and
translation specification. It specifies; it does not teach. I thought
everyone understood that.

>I don't like the typography, especially in the library section. Members
>should be "outdented", text regarding them indented, with better use of
>fonts to highlight the document's structure.


....the eye of the beholder. No one format of presentation would make
everybody happy.




[ 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 <FDvvvt.GpI@research.att.com>,
Andrew Koenig <ark@research.att.com> wrote:
>I'm sure that a lot of people on the committee would agree with you.
>Unfortunately, we can't do it.  The official form of the standard
>is a paper document, and I am quite sure that ISO would not have
>permitted us to produce an alternative document that is not the standard,
>but is intended to be used instead of the standard.

ANSI allowed Harlequin to produce the Common Lisp HyperSpec, a collection
of web pages derived from the same TeX source code as the ANSI Common Lisp
standard (the document editor made extensive use of TeX macros for markup,
which made it easier for the conversion program to figure out all the
hyperlinks).  Most casual users of the language use the CLHS rather than
purchasing the 1200-page ANSI document.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---
[ 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              ]

Al Stevens wrote:
...
> >The document should also include the relevent sections of the C standard;
>
> Well, as far as the core language goes, the document thoroughly defines the
> language. It says what "int" and "for" mean, for example. Perhaps you can be
> more specific and point to something that is missing. Being a C/C++
> programmer, I might not have noticed where a vital specification is lacking.
> We tend not to miss that which we take for granted.

There aren't many features of the language itself which are left to the
C standard to define, but there are a few. I'm always surprised when I
find one, but I haven't been keeping a list.

However, virtually the entire portion of the C++ standard library that
is derived from the C standard library has been left up to the C
standard to specify. I find this inconvenient, particular since my copy
of the C standard describes C9X, rather than C89, which is the version
actually incorporated by reference into the C++ standard.

> The document quite properly leaves the library specification to the C
> document so that the two documents may enjoy their own ANSI-mandated cycles
> of evolution and publication. To include the C spec in the C++ spec would
> create an unadministrable effort that would almost guarantee that the C++
> spec would always be out of date and out of sync with the C spec.

It will be out of sync in a year or so anyway. The C++ standard
incorporates C89, and C9X is coming out "soon".


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

ANSI also permitted Osborne Books to publish the C document in its entirety
in the Herb Schildt "The Annotated ANSI C Standard" book. The catch was that
ANSI got a big piece of the royalties.

>ANSI allowed Harlequin to produce the Common Lisp HyperSpec, a collection
>of web pages derived from the same TeX source code as the ANSI Common Lisp
>standard (the document editor made extensive use of TeX macros for markup,
>which made it easier for the conversion program to figure out all the
>hyperlinks).  Most casual users of the language use the CLHS rather than
>purchasing the 1200-page ANSI document.
---
[ 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              ]

alstevens@midifitz.com (Al Stevens) wrote in comp.std.c++:
>ANSI also permitted Osborne Books to publish the C document in its entirety
>in the Herb Schildt "The Annotated ANSI C Standard" book. The catch was that
>ANSI got a big piece of the royalties.

And the joke was that the much lower price for the book, as compared to
the bare standard, reflected the value subtracted by Schildt's
annotations.

Clive Feather's review of the book was a classic. Fortunately, it's been
saved on the Web at
 http://kbs.cs.tu-berlin.de/~jutta/c/schildt.html

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