Scott Robert Ladd wrote in message <930234731.755.42@news.remarQ.com>...
>Al Stevens <alstevens@midifitz.com> wrote:
>> I think he meant abstruse. It's a common error to confuse the two words.
>
>Correction. I did mean "obtuse", which according to my Websters dictionary
>means: "not clear in thought or expression; dull."

I think Webster's is trying to say that obtuse in this sense describes
_persons_ who are dull/slow, unclear in their expressions. Applying it to a
document is pushing the word a bit beyond it's normal meanings. (I think,
IMHO, and all that.)

>I do not see that clarity and and precision as mutually exclusive. If
>anything, I think one requires the other; you can not be clear without
>precision, and vice versa.


Be advised that vague, general criticism of the standard in this forum is a
sure fire way to get snapped at by people who have put in a lot of volunteer
time and are not amused at their work being abused. (Moderators: please
don't make me rewrite that in bowdlerized form;

[Moderator note: of course not ;) --vb ]

I actually sympathize with objections to vague complaints...)


I find that there are places in the standard that I fail to understand. My
impression is that some of that (most???) is due to my not doing enough
homework to understand the technical vocabulary. Accurate use of "hard"
words is not something that is fair game for charges of lack of clarity
(giving obtuse credit for that meaning<g>).

Anyway, if the standard is lacking clarity, find specific examples, present
them, and then show that they correspond to a general problem. If you make
your case, there's a good chance the problems will get fixed.

David J. Littleboy
---
[ 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              ]

smeyers@aristeia.com (Scott Meyers) wrote:

:   new operator
:   operator new
:   new expression

I really don't understand why there is any confusion.

void* operator new (size_t); // prefix unary operator
void* p = new 4;             // obvious usage

void* operator new (size_t, nothrow_t); // binary operator
void* p = 4 new nothrow;                // obvious usage

void* operator new (size_t, int, float* (*)(int)); // ternary operator
void* p = 4 new 7 : f;                             // obvious usage
void* p = 4 ne 7 w f;                              // alternate usage
void* p = 4 n 7 ew f;                              // alternate usage

void* operator new (size_t, int, int, int); // quaternary operator
void* p = 4 new x : y : z;                  // obvious usage
void* p = 4 n x e y w z;                    // alternate usage

Anyone still upright at this point is invited to compile these.

It is now clear that there are allocation functions which are invoked
using the normal function notation that have the unfortunate name
"operator new" which could mislead some into thinking that they are
really operators.

Since it is common in C++ to allocate memory and initialize it using
a constructor which does not have a name, a way to express this is
needed.

T* p = new T;
int* pi = new int(5);
T* p = new (nothrow) T;
T* p = new (7, f) T;
T* p = new (x, y, z) T;

Only the first of these uses "new" in a form where it may be confused
with an operator.  These are new-expressions which invoke an
allocation function and constructor as desired.

There are neither new operators nor operators new.  There are
new-expressiosns and allocation functions.

The next section of the standard talks about the
"delete-expression operator".  That should make everything clear :)

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

>No, I did mean obtuse, as in "not clear or precise in thought or
expression"
>(Webster's 10th Collegiate Dictionary.)

People (some people) are obtuse. Obtuse implies a behavior. Things (some
things) are abstruse. Abstruse implies a property. Obscure means deficient
in light, indistinct. I don't think any of those terms fairly describe the
document.

I don't think the document is all that unclear in view of its purpose. I
very much disagree that it is imprecise. It is what it means to be--a
concise statement of the specifications of the language. It has known
ambiguities, but they are few. So far, it hasn't let me down. Whenever
anyone poses a specific question here, they usually get consistent answers
from the committee members. Most disagreements seem to be in what should or
should not have been added or changed about the language, not on any
specific interpretation. When that many people agree on interpretations of
complex matters, clarity is not an issue.

If you could identify for us a particular section where you think the
document needs clarification, the participants here can concentrate on that
specific concern. Your questions about new and delete have been addressed
and the appropriate sections in the document cited. Perhaps your criticism
is just that it is not always that easy to find things. I have had that
experience a few times, but either by perservering or asking questions I
have always found what I needed. I don't always like what I found or agree
with what is specified, but I can usually find it.
---
[ 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 in message ...

>I agree that the document is abstruse...

After giving it some thought, I wish to retract that judgement. I do not
think the document is all that difficult to understand if you view it from
the perspective from which it was intended to be used and with the
understanding that the document assumes you bring to the exercise.
---
[ 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              ]

"David J. Littleboy" <davidjl@gol.com> writes:

>Anyway, if the standard is lacking clarity, find specific examples, present
>them, and then show that they correspond to a general problem. If you make
>your case, there's a good chance the problems will get fixed.

In fact, if you find a part of the standard that is not clear,
please submit a defect report, whether or not it is part of a
larger problem.

But please bear in mind that any one sentence or paragraph might
not be clear standing on its own. Take into account the context in
which it appears, as well as any other sections that it refers to.

The procedure for submitting defect reports are listed in the FAQ
for this newsgroup.

If you don't want to go to the trouble of submitting a DR, you
can just post a comment in this newsgroup. Someone else who
agrees it is a problem might decide to submit a DR.

--
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 <7km8jh$gq7$1@remarQ.com>,
Scott Robert Ladd <srladd@frontier.net> wrote:
>A complex standard (as is C++) would work best as a well-design hypertext
>document. Something as complex as C++ doesn't lend itself well to a linear
>format, since concepts weave in and out of the text. In this day-and-age of
>electronic publishing, I see hypertext (perhaps XML?) documents as the best
>vehicles for complex reference documents.

I agree - there's even precendent for this - Common LISP has a version
of its ANSI spec in HTML at
http://www.harlequin.com/education/books/HyperSpec/

>But moving the standard to hypertext may be difficult or politically
>unpalatable.

Difficult, certainly.  But I'd also pay a great deal more than the $18
that I did for the PDF version of the C++ Spec for a well-designed
(I'm thinking about the "Effective C++" CD as an example of a set of
books well-converted to an electronic format) CD-ROM containing the
C++ spec in HTML, or some other hypertext form that's viewable on any
platform I care to view it on - and since ANSI is *already*
distributing the spec electronically, it's clear that any concerns
about illegal distribution have already been overcome.
--
   Rob Macomber
    (rmacombe@u.arizona.edu)


[ 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:
[no attribution wrote:]
>>Scott Robert Ladd wrote in message <7kjc0d$i1d$1@remarQ.com>...
>>>I really wish the standard was written more clearly; it can be a rather
>>>obtuse document.
>>
>>There's nothing obtuse about the standard whatsoever. I find it to be
>>extremely quick and alert in perception, extremely sharp and acute, not
>>rounded at its extremities in the slightest, and perceived extremely
>>distinctly as pain.
>
> I think he meant abstruse.
>

 Interesting, I thought he meant obscure.
 Scott?

<l8r>
-het


--
 "Simplicity is the ultimate sophistication."  - old Apple logo

   Harvey Taylor     het@despam.pangea.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              ]

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

>I understand that. My question is: *Which* "version" of the new operator
>*function* is called by the *intrinsic* operator. Is it implementation
>defined or not?

It is completely defined by the standard. Section 5.3.4 paragraphs
8 through 14 describe how an operator new is selected for
use in a new-expression. I'm not going to duplicate the page of
text here.

>Can I assume that new calls the "throw" version of new, as
>seems implied (but not explicitly stated) by the sections I quoted?

It depends on whether the type T being created has a member
operator new and whether you supply placement arguments.

If you do not supply any placement arguments and type T does not
have a non-placement member operator new, a non-member operator
new that can throw an exception must be called. (A no-throw version
cannot be called, because non-member, non-placement operator new is
required to report failure by throwing an exception.)

Simple examples, where type T does not have a member operator new,
and I'm omitting "std::" for brevity:

T* p1 = new T;           // ::operator new(size_t) throw(bad_alloc)
T* p2 = new T[n];        // ::operator new[](size_t) throw(bad_alloc)
T* p3 = new (nothrow) T; // ::operator new(size_t, nothrow_t) throw()

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

No, I did mean obtuse, as in "not clear or precise in thought or expression"
(Webster's 10th Collegiate Dictionary.)

But obscure and abtruse do apply! ;}

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

Al Stevens <alstevens@midifitz.com> wrote:
> I think he meant abstruse. It's a common error to confuse the two words.

Correction. I did mean "obtuse", which according to my Websters dictionary
means: "not clear in thought or expression; dull."

> Iagree that the document is abstruse, but how could it not be given its
> purpose? Anything you could do to make it less so and more reader-friendly
> could compromise its precision. We don't need a "Programming Languages --
> C++ for Dummies."

I do not see that clarity and and precision as mutually exclusive. If
anything, I think one requires the other; you can not be clear without
precision, and vice versa.

--
    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" <srladd@frontier.net> writes:

>Greg Colvin <address@withheld.com> wrote:
>> There are 8 replacable global funtions in 18.4.1, not 4:

>I was not referring to chapter 18, which is about the Library, but to
>sections of chapter 3, about the language. That's probably *why* I posted
>specific reference numbers from the standard text.

>new and delete have intrinsic implementations, just as other operators do;
>my interest is in the behavior of the intrinsic functions.

I think you are confusing a new-expression, which is a language
construct, with operator new, which is a set of overloaded
functions in the standard library, declared in standard header
<new>.

The keyword new is a C++ intrinsic operation that first invokes
some version of operator new, then invokes constructors as
appropriate.  The intrinsic operation is not a function, has no
declaration, and has no throw specification. The exception
behavior of a new-expression is determined completely by the
particular version of operator new that it invokes.

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

blargg@flash.net wrote in message <199906211513.KAA11262@ares.flash.net>...
>In article <P4fb3.1181$2b.171201@nnrp.gol.com>, "David J. Littleboy"
><davidjl@gol.com> wrote:
>> Seriously, though, I'd find the standard easier to read if there were a
lot
>> more examples...

Ouch. That was poor. Let me try again: Some of the sections in the standard
I've looked at could be made clearer with the addition of one judicious
example. (I know, I should have taken notes and should be making specific
suggestions...)

>I don't think the standard is meant to be "Learn C++ in 21 Days". It is
>*the* document that describes the language in "language-legal" terms. If
>it doesn't, then nothing does.

As the only document that describes the language correctly, it's the only
document that every C++ programmer has to read. I think readability is of
concern, although admittedly secondary concern.

>Adding lots of examples (which are
>non-normative AFAIK) doesn't contribute to this aspect at all.

Sorry, I should have said "a few more examples". Sigh.

> What's
>wrong with supplementary materials (books, web pages, courses) to help the
>"normal" people understand the language?

Many of the books, web pages, and courses I've looked at are loaded with
glitches (in general the more introductory*, the worse) and I spend more
time thinking about the glitches than the language itself. This problem is
largely non-existent with the standard, simply because a lot more effort has
gone into the standard than can possibly go into just about any book.

*: Probably because in trying to be introductory, a book attempts at
simplifying things, and inevitably gets it wrong. And to add insult to
injury, while the English in the standard is legalese, at least it's
stylistically consistent and consistently correct English. The English in
the introductory books is even buggier than their C++.

The above grumbling does not, of course, apply to Stroustrup's book, which
has had several rounds of glitch removal.

Grumbly yours,
David J. Littleboy



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

Dave Abrahams wrote:
>
> In article <376CD812.462F828E@acm.org> , Pete Becker <petebecker@acm.org>
> wrote:
>
> > there are two different uses of the word 'new' in the standard: the
> > keyword and the operator.
>
> I think it would be more accurate to say:
>
> "there are two different uses of the word 'new' in the standard: the
> operator[1] and the allocation functions[2].
>
> [1] The new operator calls the appropriate allocation function, then invokes
> the constructor
>
> [2] The allocation functions are all called "operator new", which has been
> overloaded to accept various parameter lists.
>
> new is an operator much like ! or * is an operator.

I don't think that that's right. Although the standard puts
new-expression in the clause called "Unary expressions", the production
unary-operator consists of *, &, +, -, !, and ~. I've always found it
easier to explain by differentiating between "operator new", which is a
function and, from its name, clearly an operator, and a new-expression,
which uses the unadorned keyword 'new'.

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

Well, I swore I'd stay away from this discussion, but now I just can't resist.

On 22 Jun 1999 15:49:14 GMT, Pete Becker wrote:
>
> unary-operator consists of *, &, +, -, !, and ~. I've always found it
> easier to explain by differentiating between "operator new", which is a
> function and, from its name, clearly an operator, and a new-expression,
> which uses the unadorned keyword 'new'.

In my experience explaining new/delete issues to working C++ professinals
(and I have a fair amount of experience in this area), the biggest
difficulty people have is understanding what the word "new" in a new
expression does.  In More Effective C++, I refer to this word as "the new
operator," as did Dave Abrahams in the posting to which Pete responded.
Also like Dave, I refer to the underlying allocation function as operator
new.  This yields three way-too-similar-sounding phrases:

  new operator
  operator new
  new expression

They are related as follows:

  A new expression is an expression containing a use of the new operator.
  Every time you use the new operator, some underlying operator new is
  called.

I franky find no use for the term "new expression" when I explain things to
professional programmers, though I believe it is useful when working on C++
standards.

What I find either interesting or infuriating (depending on my mood) is the
resistance of the community of C++ experts to bless the term "new
operator", insisting instead on "new expression".  (In one article I
published in CUJ, the editor assidiously reworded every phrase where I'd
used "new operator" to instead refer to a "new expression".)  That makes it
impossible to answer this common question:

  What is the "new" in "new Widget"?

If you can't call it the new operator, what do you call it?  It's not a new
expression, and it's not operator new.  Calling it "the new in a new
expression" sounds stupid and doesn't help people.  Currently, I tell them
it's the new operator, then I warn them not to use that term in the company
of strangers, as one never knows what may happen.

So: why *is* there so much resistance to the term "new operator"?  I find
it to be useful in explaining things to working C++ programmers, and I
don't see how it interferes with the use of other terms like "new
expression".  How did this very useful term get such a black eye?

Scott

--
Scott Meyers, Ph.D.                  smeyers@aristeia.com
Software Development Consultant      http://www.aristeia.com/
Visit http://meyerscd.awl.com/ to demo the Effective C++ CD


[ 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 Meyers wrote:
>
> I franky find no use for the term "new expression" when I explain things to
> professional programmers, though I believe it is useful when working on C++
> standards.

I agree. And I see on rereading my message that I said I used the term
'new-expression'. I don't. See below.

>
> What I find either interesting or infuriating (depending on my mood) is the
> resistance of the community of C++ experts to bless the term "new
> operator", insisting instead on "new expression".  (In one article I
> published in CUJ, the editor assidiously reworded every phrase where I'd
> used "new operator" to instead refer to a "new expression".)  That makes it
> impossible to answer this common question:
>
>   What is the "new" in "new Widget"?

It's the keyword new.

> So: why *is* there so much resistance to the term "new operator"?  I find
> it to be useful in explaining things to working C++ programmers, and I
> don't see how it interferes with the use of other terms like "new
> expression".  How did this very useful term get such a black eye?

It's probably fear of the same sort of confusion that arose out of the
terms "class template" and "template class". That inversion sounds too
much like word play. I haven't had problems explaining the difference
between the "keyword new" and the "operator new", because it's clear
(more or less) which is the noun and which is the adjective, and in both
terms we're dealing with the same noun.

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

clamage@eng.sun.com (Steve Clamage) writes:

>The keyword new is a C++ intrinsic operation that first invokes
>some version of operator new, then invokes constructors as
>appropriate.  The intrinsic operation is not a function, has no
>declaration, and has no throw specification. The exception
>behavior of a new-expression is determined completely by the
>particular version of operator new that it invokes.

Oops. Maybe I'll be the first to correct myself. The exception
behavior of a new-expresison also depends on whether the
constructor that is called can exit via an exception.

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

<blargg@flash.net> wrote:
> I don't think the standard is meant to be "Learn C++ in 21 Days". It is
> *the* document that describes the language in "language-legal" terms. If
> it doesn't, then nothing does. Adding lots of examples (which are
> non-normative AFAIK) doesn't contribute to this aspect at all. What's
> wrong with supplementary materials (books, web pages, courses) to help the
> "normal" people understand the language?

I don't expect a Standard (for C++ or anything else) to be a tutorial. I
*do* expect a Standard to be concise, thorough, and well-organized. I think
the C++ standard misses that ideal in some areas.

Otherwise, why would so many people read the standard and continue to have
questions? Surely you do not denigrate the intelligence of anyone who has a
question? I think it is rather condescending to refer to "normal" people, as
if somehow there is an elite crowd for whom the standard is meant.

I was not a part of the Standard committee, a fact related to finances (I
don't have a big company to pay my way). However, assuming the Standard was
written for people outside the Committee, I don't think it is unreasonable
to provide constructive criticism for its improvement.

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

Steve Clamage <clamage@eng.sun.com> wrote:
> The keyword new is a C++ intrinsic operation that first invokes
> some version of operator new, then invokes constructors as
> appropriate.  The intrinsic operation is not a function, has no
> declaration, and has no throw specification. The exception
> behavior of a new-expression is determined completely by the
> particular version of operator new that it invokes.

I understand that. My question is: *Which* "version" of the new operator
*function* is called by the *intrinsic* operator. Is it implementation
defined or not? Can I assume that new calls the "throw" version of new, as
seems implied (but not explicitly stated) by the sections I quoted?

I think my question has been answered.

--
    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 Meyers wrote:
> On 22 Jun 1999 15:49:14 GMT, Pete Becker wrote:
>>
>> I've always found it easier to explain by differentiating between
>> "operator new", which is a function and, from its name, clearly an
>> operator, and a new-expression, which uses the unadorned keyword
>> 'new'.
>
> In my experience explaining new/delete issues to working C++
> professinals (and I have a fair amount of experience in this area),
> the biggest difficulty people have is understanding what the word
> "new" in a new expression does.  In More Effective C++, I refer to
> this word as "the new operator," as did Dave Abrahams in the posting
> to which Pete responded.  Also like Dave, I refer to the underlying
> allocation function as operator new.  This yields three
> way-too-similar-sounding phrases:
>
>   new operator
>   operator new
>   new expression

Perhaps it would have been better if Bjarne had called the allocation
functions something like '::allocate()' and '::deallocate()' instead
of '::operator new()' and '::operator delete()'.  Ah, but this is so
easy to say with the benefit of hindsight.  (There's also the
counter-argument that it's not immediately obvious that 'new T'
invokes 'allocate()', but then the counter-counter-argument is that
it's not obvious that 'new T' invokes 'operator new()' either.)
For whatever confusion it creates, we're stuck with it.

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

smeyers@aristeia.com (Scott Meyers) writes:

>In my experience explaining new/delete issues to working C++ professinals
>(and I have a fair amount of experience in this area), the biggest
>difficulty people have is understanding what the word "new" in a new
>expression does.  In More Effective C++, I refer to this word as "the new
>operator," as did Dave Abrahams in the posting to which Pete responded.
>Also like Dave, I refer to the underlying allocation function as operator
>new.  This yields three way-too-similar-sounding phrases:

>  new operator
>  operator new
>  new expression

Aye, there's the rub. I used to talk about "new operator" and
"operator new", but found the similarity confused people. For a
while I've just used "new-expression" and "operator new", and
have so far found it adequate for explanation.

>What I find either interesting or infuriating (depending on my mood) is the
>resistance of the community of C++ experts to bless the term "new
>operator", insisting instead on "new expression".  (In one article I
>published in CUJ, the editor assidiously reworded every phrase where I'd
>used "new operator" to instead refer to a "new expression".)  That makes it
>impossible to answer this common question:

>  What is the "new" in "new Widget"?
>If you can't call it the new operator, what do you call it?

It is the keyword that introduces a new-expression. Compare:
What is the "for" in "for(...) { ... }"?

BTW, I always use the hyphenated phrase "new-expression" to
avoid confusion with "an expression that is new."
Examples:
"The old expression wasn't valid, but the new expression is OK."
"Don't call operator new directly; use a new-expression instead."

But I don't think I'd ever say
"The new expression uses a new-expression." :-)

--
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 <7kjc0d$i1d$1@remarQ.com>...
>>I really wish the standard was written more clearly; it can be a rather
>>obtuse document.
>
>There's nothing obtuse about the standard whatsoever. I find it to be
>extremely quick and alert in perception, extremely sharp and acute, not
>rounded at its extremities in the slightest, and perceived extremely
>distinctly as pain.

I think he meant abstruse. It's a common error to confuse the two words. I
agree that the document is abstruse, but how could it not be given its
purpose? Anything you could do to make it less so and more reader-friendly
could compromise its precision. We don't need a "Programming Languages --
C++ for Dummies."
---
[ 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:
>
> <blargg@flash.net> wrote:
> > I don't think the standard is meant to be "Learn C++ in 21 Days". It is
> > *the* document that describes the language in "language-legal" terms. If
> > it doesn't, then nothing does. Adding lots of examples (which are
> > non-normative AFAIK) doesn't contribute to this aspect at all. What's
> > wrong with supplementary materials (books, web pages, courses) to help the
> > "normal" people understand the language?
>
> I don't expect a Standard (for C++ or anything else) to be a tutorial. I
> *do* expect a Standard to be concise, thorough, and well-organized. I think
> the C++ standard misses that ideal in some areas.
>
> Otherwise, why would so many people read the standard and continue to have
> questions? Surely you do not denigrate the intelligence of anyone who has a
> question? I think it is rather condescending to refer to "normal" people, as
> if somehow there is an elite crowd for whom the standard is meant.
>
> I was not a part of the Standard committee, a fact related to finances (I
> don't have a big company to pay my way). However, assuming the Standard was
> written for people outside the Committee, I don't think it is unreasonable
> to provide constructive criticism for its improvement.

So I'll ask again: where and what needs to be improved? Simply saying
"they should have done a better job" isn't constructive.

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

Pete Becker <petebecker@acm.org> asked:

> What would you change in the organization of the document?

A complex standard (as is C++) would work best as a well-design hypertext
document. Something as complex as C++ doesn't lend itself well to a linear
format, since concepts weave in and out of the text. In this day-and-age of
electronic publishing, I see hypertext (perhaps XML?) documents as the best
vehicles for complex reference documents.

But moving the standard to hypertext may be difficult or politically
unpalatable. How about this: Once this "crunch" week is over, I'll work up a
short list of ideas for improving the organization and typography of the
standard, posting it here for general discussion.

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

[ moderator's note: html duplication of posting deleted. Please
  do not post html, and please do not put attachments on articles.
  -sdc ]

Okay, so I'm slightly confused; while this is not an unusual condition (!),
I hope, in this case, that the august members of this newsgroup can provide
clarity on the topic of std::new and std::delete.

I'm reading the C++ standard, Section 3.7.3, "Dynamic storage duration". In
paragraph 2, it defines four "global" functions implicitly defined by the
language:

    void * operator new(std::size_t) throw(std::std::bad_alloc);
    void * operator new[](std::size_t) throw(std::std::bad_alloc);
    void operator delete(void *) throw();
    void operator delete[](void *) throw();

That's all fine and dandy. I assume from the above that new will throw a
bad_alloc whenever an error occurs during memory allocation.

However, my mind becomes muddled when I read 3.7.3.1, paragraph 3, which
states:

    An allocation function that fails to allocate storage can invoke the
    currently installed new_handler (18.4.2.2), if any... If an allocation
    function declared with an empty exception-specification (15.4),
    throw(), fails to allocate storage, it shall return a null pointer. Any
    other allocation function that fails to allocate storage shall only
    indicate failure by throwing an exception of class std::bad_alloc
    (18.4.2.1) or a class derived from std::bad_alloc.

Looking at the "implicit" functions, I see two allocation functions named
"new", each declared to throw a bad_alloc exception. Where, then, are the
"allocation functions" defined with throw()? 3.7.3.1 p3 can't be referring
to delete; while delete does declare itself as throw(), it does not have any
return value with which it can return a null pointer!

So where are the versions of new declared with throw()? Since you can't
overload based on the throw declaration, I can't see how you could implement
a "void * new(std::size_t) throw()".

And so we come to the question that caused me the read the Standard in the
first place: Can I assume that any call to the "global implicit" new will
throw a bad_alloc on error, or do I still have to check for a null pointer
after every allocation? In other words, can I write:

    try
    {
        int * ip;

        ip = new int;
    }
    catch (std::bad_alloc & ba)
    {
        // do something about it
    }

Or do I have to say:

    try
    {
        int * ip;

        ip = new int;

        // better be safe!
        if (ip == NULL)
            throw std::bad_alloc();
    }
    catch (std::bad_alloc & ba)
    {
        // do something about it
    }

An inquiring mind wants a definitive answer, or close facsimile thereof.

--
    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" <srladd@frontier.net> writes:

>I'm reading the C++ standard, Section 3.7.3, "Dynamic storage duration". In
>paragraph 2, it defines four "global" functions implicitly defined by the
>language:

>    void * operator new(std::size_t) throw(std::std::bad_alloc);
>    void * operator new[](std::size_t) throw(std::std::bad_alloc);
>    void operator delete(void *) throw();
>    void operator delete[](void *) throw();

The functions are not implicitly defined. They are part of the
standard library, and are declared in standard header <new>.
(I'm ignoring the "std::std" typos.)  The names, but not the
signatures, of those functions are implicitly declared. You
can't call them directly without including <new>.

Normally you don't need to call them directly, since you would
write something like
 T* p = new T;
and the compiler implicitly invokes an operator new for you.
Remember the difference between a new-expression, such as
the example above, and a function whose name is "operator new".
The new-expression invokes an associated operator new, then
invokes the appropriate constuctor on the storage returned
by the "operator new" function.

>That's all fine and dandy. I assume from the above that new will throw a
>bad_alloc whenever an error occurs during memory allocation.

More specifically, the two versions of operator new that you
show must throw an exception if the request for storage cannot
be satisfied. The exception can be of type bad_alloc, or of any
type derived from bad_alloc.  You are allowed to replace the
versions in the standard library with your own functions, but the
same requirements still apply.

>However, my mind becomes muddled when I read 3.7.3.1, paragraph 3, which
>states:

>    An allocation function that fails to allocate storage can invoke the
>    currently installed new_handler (18.4.2.2), if any... If an allocation
>    function declared with an empty exception-specification (15.4),
>    throw(), fails to allocate storage, it shall return a null pointer. Any
>    other allocation function that fails to allocate storage shall only
>    indicate failure by throwing an exception of class std::bad_alloc
>    (18.4.2.1) or a class derived from std::bad_alloc.

>Looking at the "implicit" functions, I see two allocation functions named
>"new", each declared to throw a bad_alloc exception. Where, then, are the
>"allocation functions" defined with throw()?

You cannot read individual subsections out of context. Section 3.7.3
paragraph 1 defines "allocation function" as an operator new.

>So where are the versions of new declared with throw()? Since you can't
>overload based on the throw declaration, I can't see how you could implement
>a "void * new(std::size_t) throw()".

Standard header <new> (refer to section 18.4) declares other
allocation functions that have empty throw-specifications.  These
other functions are "placement-new" forms, and have additional
parameters. You can write other versions of operator new -- "placement"
versions or class-specific versions -- that do not throw exceptions.

If you want to avoid an allocation exception and get a null
return instead, you can write something like this:
 #include <new>
 ...
 T* p = new (std::nothrow) T;
 if( p == 0 ) { ... allocation failed ... }

>And so we come to the question that caused me the read the Standard in the
>first place: Can I assume that any call to the "global implicit" new will
>throw a bad_alloc on error, or do I still have to check for a null pointer
>after every allocation?

With a standard-conforming implementation, invoking the
non-placement version of the global operator new must result
in an exception if the allocation request cannot be satisfied.

In other words, can I write:

>    try
>    {
>        int * ip;

>        ip = new int;
>    }
>    catch (std::bad_alloc & ba)
>    {
>        // do something about it
>    }

Yes. You do not need to check for a null return with a standard-
conforming implementation.

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

From: Scott Robert Ladd <srladd@frontier.net>
> Okay, so I'm slightly confused; while this is not an unusual condition (!),
> I hope, in this case, that the august members of this newsgroup can provide
> clarity on the topic of std::new and std::delete.

There are 8 replacable global funtions in 18.4.1, not 4:

    void* operator new(std::size_t size) throw(std::bad_alloc);
    void* operator new(std::size_t size, const std::nothrow_t&) throw();
    void  operator delete(void* ptr) throw();
    void  operator delete(void* ptr, const std::nothrow_t&) throw();
    void* operator new[](std::size_t size) throw(std::bad_alloc);
    void* operator new[](std::size_t size, const std::nothrow_t&) throw();
    void  operator delete[](void* ptr) throw();
    void  operator delete[](void* ptr, const std::nothrow_t&) throw();

They overload on std::nothrow_t, as should your replacements.

> And so we come to the question that caused me the read the Standard in the
> first place: Can I assume that any call to the "global implicit" new will
> throw a bad_alloc on error, or do I still have to check for a null pointer
> after every allocation? In other words, can I write:
>
>     try
>     {
>         int * ip;
>
>         ip = new int;
>     }
>     catch (std::bad_alloc & ba)
>     {
>         // do something about it
>     }

Yes.

> Or do I have to say:
>
>     try
>     {
>         int * ip;
>
>         ip = new int;
>
>         // better be safe!
>         if (ip == NULL)
>             throw std::bad_alloc();
>     }
>     catch (std::bad_alloc & ba)
>     {
>         // do something about it
>     }

No.

> An inquiring mind wants a definitive answer, or close facsimile thereof.

What parts of "yes" and "no" aren't definitive enough?



[ 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:
>
>
> Looking at the "implicit" functions, I see two allocation functions named
> "new", each declared to throw a bad_alloc exception. Where, then, are the
> "allocation functions" defined with throw()? 3.7.3.1 p3 can't be referring
> to delete; while delete does declare itself as throw(), it does not have any
> return value with which it can return a null pointer!
>

The header <new> contains declarations of:

void *operator new(size_t, const std::nothrow_t&) throw();
void *operator new[](size_t, const std::nothrow_t&) throw();
void *operator new(size_t, void*) throw();
void *operator new[](size_t, void*) throw();

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

Greg Colvin <address@withheld.com> wrote:
> There are 8 replacable global funtions in 18.4.1, not 4:

I was not referring to chapter 18, which is about the Library, but to
sections of chapter 3, about the language. That's probably *why* I posted
specific reference numbers from the standard text.

new and delete have intrinsic implementations, just as other operators do;
my interest is in the behavior of the intrinsic functions.

> They overload on std::nothrow_t, as should your replacements.

Again, I was not talking about replacing anything; I didn't even use the
word "replace" in my original message. I was asking about default behaviors,
which are unclear from the text I quoted.

> What parts of "yes" and "no" aren't definitive enough?

You've given yet another example of how so many "experts" in this group are
condescending. Of course I know what "yes" and "no" mean. Please try to be
polite.

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

Steve Clamage <clamage@eng.sun.com> wrote:

> Yes. You do not need to check for a null return with a standard-
> conforming implementation.

Your final sentence answered my question. To me, it was not clear from the
Standard whether or not an implementation was allowed to define default new
as returning null instead of throwing bad_alloc.

I suspect my confusion stems from Microsoft's poor support of Standard C++.
Visual C++ 6.0 does not correctly implement default new; on a memory
allocation failue, it invokes new_handler or returns a null pointer.
Therefore, to write portable code, I must still check for null, since I have
no way of knowing if a compiler implements new correctly or not.

[Side note: I apologize to the moderator for HTML in my original message.
Apparently, installing Outlook Express 5 undid many of my default settings
from version 4.]


--
    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:
>
> Greg Colvin <address@withheld.com> wrote:
> > There are 8 replacable global funtions in 18.4.1, not 4:
>
> I was not referring to chapter 18, which is about the Library, but to
> sections of chapter 3, about the language. That's probably *why* I posted
> specific reference numbers from the standard text.

The text that you quoted talks about the behavior of 'an allocation
function', not 'the allocation functions mentioned up to this point'.

>
> new and delete have intrinsic implementations, just as other operators do;
> my interest is in the behavior of the intrinsic functions.
>

This is a common source of confusion. The keywords new and delete have
intrinsic implementations. The keyword new says to call the appropriate
operator new and then invoke the appropriate constructor on the block of
memory that it returns. Operator new is a set of library functions,
whose behavior must match what is set out in the standard. That is,
there are two different uses of the word 'new' in the standard: the
keyword and the operator.

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

Pete Becker wrote:

> This is a common source of confusion. The keywords new and delete have
> intrinsic implementations. The keyword new says to call the appropriate
> operator new and then invoke the appropriate constructor on the block of
> memory that it returns. Operator new is a set of library functions,
> whose behavior must match what is set out in the standard. That is,
> there are two different uses of the word 'new' in the standard: the
> keyword and the operator.

I really wish the standard was written more clearly; it can be a rather
obtuse document. While I know it's a "standard" and not a novel, I still
think the organization and clarity could be dramatically improved -- if by
nothing else than by better typography!

On the other hand, for a technical standard, C++ is pretty good. I've been
reading some ANSI electronic commerce standards recently -- ugh! ;}

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

In article <376CD812.462F828E@acm.org> , Pete Becker <petebecker@acm.org>
wrote:

> there are two different uses of the word 'new' in the standard: the
> keyword and the operator.

I think it would be more accurate to say:

"there are two different uses of the word 'new' in the standard: the
operator[1] and the allocation functions[2].

[1] The new operator calls the appropriate allocation function, then invokes
the constructor

[2] The allocation functions are all called "operator new", which has been
overloaded to accept various parameter lists.

new is an operator much like ! or * is an operator. The big difference is
that most operators X have a much more straightforward relationship to the
functions operator X() which implement them. The compiler doesn't do as much
"behind the scenes" in those cases.

-Dave
---
[ 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:
>
> I really wish the standard was written more clearly; it can be a rather
> obtuse document. While I know it's a "standard" and not a novel, I still
> think the organization and clarity could be dramatically improved -- if by
> nothing else than by better typography!

What would you change in the organization of the document?

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

Scott Robert Ladd wrote in message <7kjc0d$i1d$1@remarQ.com>...
>I really wish the standard was written more clearly; it can be a rather
>obtuse document.

There's nothing obtuse about the standard whatsoever. I find it to be
extremely quick and alert in perception, extremely sharp and acute, not
rounded at its extremities in the slightest, and perceived extremely
distinctly as pain.

Seriously, though, I'd find the standard easier to read if there were a lot
more examples...

David J. Littleboy
PS: obtuse
adj.1. not quick or alert in perception, feeling, or intellect; not
sensitive or observant; dull. 2. not sharp, acute, or pointed; blunt in
form. 3.  (of a leaf, petal, etc.) rounded at the extremity. 4. indistinctly
felt or perceived, as pain or sound.
---
[ 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              ]

From: Scott Robert Ladd <srladd@frontier.net>
>
> Greg Colvin <address@withheld.com> wrote:
> > There are 8 replacable global funtions in 18.4.1, not 4:
>
> I was not referring to chapter 18, which is about the Library, but to
> sections of chapter 3, about the language. That's probably *why* I posted
> specific reference numbers from the standard text.
>
> new and delete have intrinsic implementations, just as other operators do;
> my interest is in the behavior of the intrinsic functions.
>
> > They overload on std::nothrow_t, as should your replacements.
>
> Again, I was not talking about replacing anything; I didn't even use the
> word "replace" in my original message. I was asking about default behaviors,
> which are unclear from the text I quoted.

Sorry -- your question that I was trying to answer was:

   So where are the versions of new declared with throw()? Since you can't
   overload based on the throw declaration, I can't see how you could implement
   a "void * new(std::size_t) throw()".

Where they are is in Chapter 18, and how you implement the throw()
variants is by overloading on nothrow_t.  And such an implementation
would be a replacement.  It is pretty much impossible to understand
Chapters 3 and 18 in isolation, and pretty difficult to understand
them together.
---
[ 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              ]

> > What parts of "yes" and "no" aren't definitive enough?
>
> You've given yet another example of how so many "experts" in this group are
> condescending. Of course I know what "yes" and "no" mean. Please try to be
> polite.

Actually, I was trying to be humorous.  I should know better --
it never comes off as intended on usenet.  My sincere and humble
apologies.

Greg Colvin
---
[ 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 <P4fb3.1181$2b.171201@nnrp.gol.com>, "David J. Littleboy"
<davidjl@gol.com> wrote:

> Scott Robert Ladd wrote in message <7kjc0d$i1d$1@remarQ.com>...
> >I really wish the standard was written more clearly; it can be a rather
> >obtuse document.
>
> There's nothing obtuse about the standard whatsoever. I find it to be
> extremely quick and alert in perception, extremely sharp and acute, not
> rounded at its extremities in the slightest, and perceived extremely
> distinctly as pain.
>
> Seriously, though, I'd find the standard easier to read if there were a lot
> more examples...

I don't think the standard is meant to be "Learn C++ in 21 Days". It is
*the* document that describes the language in "language-legal" terms. If
it doesn't, then nothing does. Adding lots of examples (which are
non-normative AFAIK) doesn't contribute to this aspect at all. What's
wrong with supplementary materials (books, web pages, courses) to help the
"normal" people understand the language?
---
[ 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              ]