"Herb Sutter" <hsutter@peerdirect.com> wrote

> 3. Apart from two experts (Mike Miller and James Kanze), all the people
who
> responded to my question said that they preferred Option B

Really? I think I saw a plenty supporting A, and let me second that too.

> (to use
> "placement new" to really mean placement only), and this included some
> regulars who said they weren't even aware it was used to mean any
overloaded
> new with extra parameters. The repeated rationale was that to use
"placement
> new" in an extended sense was unintuitive, even if it has been used that
> way.

Far not all terms used are intuitive, but if they're widely used (and I
believe placement new always meant all overloads, throug a plenty of books
and journals + e-discussion).

> All of this has made me decide to do neither Option A nor Option B, purely
> on the teaching merits: Option A would promote a term that has
consistently
> proven to be confusing to non-experts, which is not desirable, and Option
B
> would be clearer but inconsistent with some past usage, which is also not
> desirable.

Well, that also makes sense. :)

> I absolutely agree that we need a word for this, and since I too don't
know
> of an existing term and refuse to use "placement new" from now on, in my
> March column I will call this "in-place new" without further explanation.

How about prealloc, or non-alloc new? address-supplied new? (addressed new?)
In-place is probably good for those already read this discussion (but for
them anything els is as good, including the original :), and in-place lets
me associate other things.

Paul



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Hmm. In writing my March column, I think I've just realized that both Matt
and I were wrong when we repeated the following oft-repeated folklore:

>Herb Sutter <hsutter@peerdirect.com> writes:
>> It's also worth pointing out again that "placement new" is an
>> unfortunately misleading term. The term is used to refer to any new
>> taking additional parameters. It just so happens that the first (and
>> only standardized) use of this facility happens to be a "place it
>> _there_ and don't actually bother allocating anything" operation which
>> can naturally be described as "placement" -- most other uses of this
>> facility wouldn't as naturally be described as "placement."

Matthew Austern <austern@research.att.com> writes:
>Almost true.  Placement was indeed the first use for "placement new",
>but it's not the only standardized use.  The other use in the standard
>library is nothrow new.

I've just realized two things:

1. Matt and I were both wrong to say that the standard uses the term
loosely; it doesn't. In 18.4.1.3, the standard is clear that only the
"put-it-there" version is called "placement," and these "placement" versions
are further distinguished from all other forms in that they may not be
replaced by users. OTOH, the other forms, including nothrow new, are just
overloads described in the main section, and all can be replaced by the user
as long as the semantics are preserved.

2. Unfortunately, as a community I do think we have traditionally used the
term more loosely. Somewhere we've accumulated an urban legend (which I
believed) that "placement new" means any overloaded new taking additional
parameters. I've seen this looser usage on newsgroups and, I think, within
the committee itself, so it could be viewed as part of the C++ community's
"language."


Given this state of affairs, I'm (slightly) undecided whether to best write
this up by ignoring the standard and documenting the colloquial status quo:

  Option A paraphrase: "in addition to true placement, 'placement new'
  has also commonly come to mean any overloaded new taking additional
  parameters, so that's the way I'm going to use the term"

or by bucking the colloquial status quo and asserting the standard (and also
promoting more precise and correct terminology):

  Option B paraphrase: "although a lot of people use 'placement new'
  to mean any overloaded new taking additional parameters, the standard
  is much stricter and more precise -- the only 'placement new' is the
  one that truly places an object in an existing location without
  performing an actual allocation, so that's the way I'm going to use
  the term; the other forms of new are simply extended overloads"

Since this affects our shared terminology and may buck tradition, a
Question: Does the committee/community have a strong preference for which
form I should publish? I'm leaning toward Option B because it avoids some
confusion (already exemplified in this thread), conforms to the standard,
and makes the term "placement" more precise and consistent with the spirit
of its original and intuitive meaning.

Herb

---
Herb Sutter (mailto:hsutter@peerdirect.com)

Secretary, ISO WG21 / ANSI J16 (C++)
Contributing Editor, C/C++ Users Journal (http://www.cuj.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://www.research.att.com/~austern/csc/faq.html                ]

"Herb Sutter" <hsutter@peerdirect.com> wrote in message
news:8mt14tseiv5lsveqb9rfvpfgusl73kcjq0@4ax.com...
[snip-o-rama]
>
> Since this affects our shared terminology and may buck tradition, a
> Question: Does the committee/community have a strong preference for which
> form I should publish? I'm leaning toward Option B because it avoids some
> confusion (already exemplified in this thread), conforms to the standard,
> and makes the term "placement" more precise and consistent with the spirit
> of its original and intuitive meaning.
>
> Herb

Option B all the way
-cd



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 <8mt14tseiv5lsveqb9rfvpfgusl73kcjq0@4ax.com>,
  Herb Sutter <hsutter@peerdirect.com> wrote:
> Hmm. In writing my March column, I think I've just realized that both
Matt
> and I were wrong when we repeated the following oft-repeated folklore:
>
> >Herb Sutter <hsutter@peerdirect.com> writes:
> >> It's also worth pointing out again that "placement new" is an
> >> unfortunately misleading term. The term is used to refer to any new
> >> taking additional parameters. It just so happens that the first
(and
> >> only standardized) use of this facility happens to be a "place it
> >> _there_ and don't actually bother allocating anything" operation
which
> >> can naturally be described as "placement" -- most other uses of
this
> >> facility wouldn't as naturally be described as "placement."
>
> Matthew Austern <austern@research.att.com> writes:
> >Almost true.  Placement was indeed the first use for "placement new",
> >but it's not the only standardized use.  The other use in the
standard
> >library is nothrow new.
>
> I've just realized two things:
>
> 1. Matt and I were both wrong to say that the standard uses the term
> loosely; it doesn't. In 18.4.1.3, the standard is clear that only the
> "put-it-there" version is called "placement," and these "placement"
versions
> are further distinguished from all other forms in that they may not be
> replaced by users. OTOH, the other forms, including nothrow new, are
just
> overloads described in the main section, and all can be replaced by
the user
> as long as the semantics are preserved.

Hmm, indeed.

There are lots of places in the language part of the Standard
where the term "placement" obviously refers to all overloaded
(extra-argument) versions of allocation and deallocation
functions.  A quick search using Acrobat shows 3.2p2, 3.7.3.2p2,
5.3.4p1, 5.3.4p12, 5.3.4p19-20, and 14.5.5.2p1.  The grammar
in 5.3.4p1 even uses the syntactic nonterminal "new-placement"
to describe the extra arguments in the new-expression,
regardless of how many or of what types they are.

I don't think it's necessary to read 18.4.1.3 the way you do,
however.  It's entitled "Placement Forms," and for me the most
natural reading of that is that, while there is an unbounded
set of "placement forms," the two that the library provides
are described in this section (just as, for example, there are
many "operators", but the ones mentioned in 20.2.1 ("Operators")
are provided by the library).

This reading has the drawback that treats the nothrow versions
as "misfiled," since they also use the new-placement syntax but
are described elsewhere.  However, I do think it's more
consistent with the rest of the Standard.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com
http://www.deja.com/

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 5.3.4/1 is given a description:

  new expression:
 ::[opt] new new-placement[opt] ...

  new-placement:
 ( expression-list )

where the ... is just my way of indicating that the rest seems not to
matter in this context and [opt] is my notational, lacking fancy
rendering in an ascii newsgroup, for optional.

It is clear that this refers to an expression of the form

  new( list of parameters ) ...

There is no indication that this is to be called placement new. I could
thus support your initiative on that basis but I fear that it might not
admit the clarity that you gain by such a change. It might therefore be
beneficial if the wording

  new-placement

were replaced by something else.


Regards, John.

BTW, I've a nagging suspicion that the _usual_ meaning ascribed to
placement new may have originated in the Annotated C++ Reference Manual
(aka The ARM) but as I've not got a copy nearby I'm unsure about this
claim.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A426675.F4171DC7@nortelnetworks.com>,
  "John Hickin" <hickin@nortelnetworks.com> wrote:
> In 5.3.4/1 is given a description:
>
>   new expression:
>  ::[opt] new new-placement[opt] ...
>
>   new-placement:
>  ( expression-list )
>
> where the ... is just my way of indicating that the rest seems not to
> matter in this context and [opt] is my notational, lacking fancy
> rendering in an ascii newsgroup, for optional.
>
> It is clear that this refers to an expression of the form
>
>   new( list of parameters ) ...
>
> There is no indication that this is to be called placement new.

I must differ.  See, for instance, 5.3.4p12:

    ...array new-expressions, including those referencing the
    library function operator new[](std::size_t, void*) and
    other placement allocation functions.

Note, "_other_ placement allocation functions."  The clear
implication is that the "(std::size_t, void*)" version in
the library is only one of many "placement allocation
functions."  This is just one of a number of references in
the language clauses that use "placement" in this way, as I
mentioned in another post.

> BTW, I've a nagging suspicion that the _usual_ meaning ascribed to
> placement new may have originated in the Annotated C++ Reference
Manual
> (aka The ARM) but as I've not got a copy nearby I'm unsure about this
> claim.

It certainly was used that way in the ARM; in fact, the
syntactic non-terminal "new-placement" in the Standard was
simply "placement" in the ARM.

However, the usage goes back further.  Originally, the idea
was simply a dedicated way of overriding the default allocation.
In very early versions of the language, the way to do that was
to assign a value to "this" inside the constructor if "this"
was NULL on entry (the NULL value indicated that the constructor
was being invoked as a result of a "new" expression, as opposed
to constructing static and auto objects where the value would be
non-NULL on entry).

This approach was viewed as kludgy and error-prone.  The first
attempt to improve the situation was simply to change the "new"
syntax to allow passing the value of "this" to the constructor
explicitly.  The constructor, seeing a non-NULL "this", would
use that address instead of allocating a new object.  This form
of "new" expression was naturally called the "placement" form.

A little later, the idea of "operator new" was developed,
completely replacing the "assignment to this" scheme.  It wasn't
too long before it was realized that the "placement" syntax
could be used to provide parameters to overloaded "operator new."
Even though the usage was greatly expanded beyond passing the
value of "this" to the constructor, the syntactic form kept its
old name and is still called "placement."

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com
http://www.deja.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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Herb Sutter wrote:

>   Option A paraphrase: "in addition to true placement, 'placement new'
>   has also commonly come to mean any overloaded new taking additional
>   parameters, so that's the way I'm going to use the term"

[...]

>   Option B paraphrase: "although a lot of people use 'placement new'
>   to mean any overloaded new taking additional parameters, the
>   standard is much stricter and more precise -- the only 'placement
>   new' is the one that truly places an object in an existing location
>   without performing an actual allocation, so that's the way I'm going
>   to use the term; the other forms of new are simply extended
>   overloads"
>
> Since this affects our shared terminology and may buck tradition, a
> Question: Does the committee/community have a strong preference for
> which form I should publish?

Option B, by all means. Overloaded and ambiguous terms and keywords (can
you spell "static"?) make C++ unnecessarily hard to understand already,
so every step towards a more precise terminology would be most welcome.

Gerhard Menzl

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Herb Sutter wrote:
[...]
> Given this state of affairs, I'm (slightly) undecided whether to best write
> this up by ignoring the standard and documenting the colloquial status quo:
>
>   Option A paraphrase: "in addition to true placement, 'placement new'
>   has also commonly come to mean any overloaded new taking additional
>   parameters, so that's the way I'm going to use the term"
>
> or by bucking the colloquial status quo and asserting the standard (and also
> promoting more precise and correct terminology):
>
>   Option B paraphrase: "although a lot of people use 'placement new'
>   to mean any overloaded new taking additional parameters, the standard
>   is much stricter and more precise -- the only 'placement new' is the
>   one that truly places an object in an existing location without
>   performing an actual allocation, so that's the way I'm going to use
>   the term; the other forms of new are simply extended overloads"
>
> Since this affects our shared terminology and may buck tradition, a
> Question: Does the committee/community have a strong preference for which
> form I should publish? I'm leaning toward Option B because it avoids some
> confusion (already exemplified in this thread), conforms to the standard,
> and makes the term "placement" more precise and consistent with the spirit
> of its original and intuitive meaning.

Option B.  I have no doubt about it.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 <91ttk5$s46$1@nnrp1.deja.com>,
  wmm@fastdial.net wrote:
> In article <8mt14tseiv5lsveqb9rfvpfgusl73kcjq0@4ax.com>,
>   Herb Sutter <hsutter@peerdirect.com> wrote:
> > I've just realized two things:

> > 1. Matt and I were both wrong to say that the standard uses the
> > term loosely; it doesn't. In 18.4.1.3, the standard is clear that
> > only the "put-it-there" version is called "placement," and these
> > "placement" versions are further distinguished from all other
> > forms in that they may not be replaced by users. OTOH, the other
> > forms, including nothrow new, are just overloads described in the
> > main section, and all can be replaced by the user as long as the
> > semantics are preserved.

> Hmm, indeed.

> There are lots of places in the language part of the Standard
> where the term "placement" obviously refers to all overloaded
> (extra-argument) versions of allocation and deallocation
> functions.  A quick search using Acrobat shows 3.2p2, 3.7.3.2p2,
> 5.3.4p1, 5.3.4p12, 5.3.4p19-20, and 14.5.5.2p1.  The grammar
> in 5.3.4p1 even uses the syntactic nonterminal "new-placement"
> to describe the extra arguments in the new-expression,
> regardless of how many or of what types they are.

I'll second Bill Miller here.  The *first* place it occured to me to
look in order to find out what the standard considers placement new
was 5.3.4.  And there, it is very clear that placement new signifies
*all* forms with additional parameters.  This is also the conventional
use, at least since the ARM.  The term may be misleading, but then, it
is usual to use terms in somewhat special ways when speaking exactly
about a language.  It's consacrated, and changing it in any way would
invalidate so many books already written, and lead to even more
confusion.  Think of what it would mean to beginners if both Herb
Sutter and Bjarne Stroustrup use the term "placement new", but each
with a different meaning, simply because they published at different
times.  Whatever the implications, placement new it is, and placement
new it must stay, unless we want total confusion.

> I don't think it's necessary to read 18.4.1.3 the way you do,
> however.  It's entitled "Placement Forms," and for me the most
> natural reading of that is that, while there is an unbounded set of
> "placement forms," the two that the library provides are described
> in this section (just as, for example, there are many "operators",
> but the ones mentioned in 20.2.1 ("Operators") are provided by the
> library).

> This reading has the drawback that treats the nothrow versions as
> "misfiled," since they also use the new-placement syntax but are
> described elsewhere.  However, I do think it's more consistent with
> the rest of the Standard.

Agreed.  I think the main problem is much simpler: we don't have a
good name for the void* form of placement new.  It's a shame that
"placement new" is already taken; it would fit well:-).  Any other
suggestions.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orientie objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com
http://www.deja.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://www.research.att.com/~austern/csc/faq.html                ]

On 21 Dec 2000 14:53:05 -0500, Herb Sutter wrote:
>   Option A paraphrase: "in addition to true placement, 'placement new'
>   has also commonly come to mean any overloaded new taking additional
>   parameters, so that's the way I'm going to use the term"

Please do this.  First, it happens to be true.  Look at 5.3.4/19:

  A declaration of a placement deallocation function matches the
  declaration of a placement allocation func-tion if it has the same number
  of parameters and, after parameter transformations (8.3.5), all parameter
  types except the first are identical.

It's clear that this is written to handle the case of an arbitrary number
of extra parameters of arbitrary types.

Second, anything other than Option A contradicts what I wrote in the
sidebar of my April 1998 CUJ article , which you can find at
http://www.awlonline.com/cseng/meyerscddemo/DEMO/MAGAZINE/CO_FRAME.HTM.  I
suffered plenty during revisions of MEC++ as the committee struggled to
figure out how auto_ptr was supposed to behave.  Please don't torture me
again by changing terminology after the fact :-)

Scott

--
I've scheduled more public seminars.  Check out
http://www.aristeia.com/seminars/ for details.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

----- Original Message -----
From: <James.Kanze@dresdner-bank.com>
> Agreed.  I think the main problem is much simpler: we don't have a
> good name for the void* form of placement new.  It's a shame that
> "placement new" is already taken; it would fit well:-).  Any other
> suggestions.
>

How about _trivial new_. It is trivial in the sense that nothing really
happens as far as memory allocation goes. There is the side effect of a
constructor call but all new expressions involve that.


Regards, 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Okay, so we're basically in the situation that:

1. Some parts of the standard refer to placement new as specifically the
"truly placement" version taking an extra void* parameter. The clearest case
is the very subclause that categorizes the operators new supplied by the
library, where 18.4.1.3 is entitled "Placement forms
[lib.new.delete.placement]" and includes ONLY the operators new and new[]
taking the void*:

  void* operator new(std::size_t size, void* ptr) throw();
  void* operator new[](std::size_t size, void* ptr) throw();

2. Other parts of the standard implicitly imply[sic] that placement new
means all overloaded new. The most persuasive example, I think, is 5.3.4/11:

11The  new-placement syntax is used to supply additional arguments to an
  allocation function.  If used, overload resolution is performed  on  a
  function call created by assembling an argument list consisting of the
  amount of space requested (the first argument) and the expressions  in
  the  new-placement part of the new-expression (the second and succeed-
  ing arguments).

(I say "imply" because even this does not use the term "placement new," only
the new-placement nonterminal label, but it's pretty clearly implied and
specifically mentions multiple additional arguments.)

3. Apart from two experts (Mike Miller and James Kanze), all the people who
responded to my question said that they preferred Option B (to use
"placement new" to really mean placement only), and this included some
regulars who said they weren't even aware it was used to mean any overloaded
new with extra parameters. The repeated rationale was that to use "placement
new" in an extended sense was unintuitive, even if it has been used that
way.

All of this has made me decide to do neither Option A nor Option B, purely
on the teaching merits: Option A would promote a term that has consistently
proven to be confusing to non-experts, which is not desirable, and Option B
would be clearer but inconsistent with some past usage, which is also not
desirable.

I'm therefore going to choose a new Option C: I'm not using the term
"placement new" at all. Better not to use it at all than to use a confusing
term.


Mike Miller wrote:
>> This reading has the drawback that treats the nothrow versions as
>> "misfiled," since they also use the new-placement syntax but are
>> described elsewhere.

Agreed, and it's confusing and inconsistent. Oh well.

James.Kanze@dresdner-bank.com writes:
>I'll second [Mike] Miller here.  The *first* place it occured to me to
>look in order to find out what the standard considers placement new
>was 5.3.4.  And there, it is very clear that placement new signifies
>*all* forms with additional parameters.

Grudgingly agreed. I really wish I had been wrong the first time about
placement new having come to mean any overloaded new, but (as the British
would say, and later did) there it is.[*]

[*] With apologies to Douglas Adams.

>Agreed.  I think the main problem is much simpler: we don't have a
>good name for the void* form of placement new.  It's a shame that
>"placement new" is already taken; it would fit well:-).  Any other
>suggestions.

I absolutely agree that we need a word for this, and since I too don't know
of an existing term and refuse to use "placement new" from now on, in my
March column I will call this "in-place new" without further explanation.
"Place" is the best word to describe it, so why avoid the word?

Herb

---
Herb Sutter (mailto:hsutter@peerdirect.com)

Secretary, ISO WG21 / ANSI J16 (C++)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 <MPG.14ad7afc12bb7b5a98976b@news.supernews.com>, Scott Meyers
<smeyers@aristeia.com> writes
>Second, anything other than Option A contradicts what I wrote in the
>sidebar of my April 1998 CUJ article , which you can find at
>http://www.awlonline.com/cseng/meyerscddemo/DEMO/MAGAZINE/CO_FRAME.HTM.  I
>suffered plenty during revisions of MEC++ as the committee struggled to
>figure out how auto_ptr was supposed to behave.  Please don't torture me
>again by changing terminology after the fact :-)

Indeed, Scott's are not the only good books that use the terminology of
referring to all overloads (as opposed to overrides) of new as
'placement' ones. Any change now will just guarantee years of confusion
among good C++ programmers.



Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

Herb Sutter <hsutter@peerdirect.com> writes:

|>  >Agreed.  I think the main problem is much simpler: we don't have a
|>  >good name for the void* form of placement new.  It's a shame that
|>  >"placement new" is already taken; it would fit well:-).  Any other
|>  >suggestions.

|>  I absolutely agree that we need a word for this, and since I too
|>  don't know of an existing term and refuse to use "placement new"
|>  from now on, in my March column I will call this "in-place new"
|>  without further explanation.  "Place" is the best word to describe
|>  it, so why avoid the word?

A bit more awkward, but how about "non-allocating new", which stresses
the second important point -- no memory is actually allocated.  (I'll
avoid the temptation to suggest "old new", on the grounds that it uses
old memory, or "non-new new".)

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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