🚀 go-pugleaf

akv@cacs.usl.edu (Anil Vijendran) writes:
	...
>    Alex> 	shape *s = new(pstore) shape(pstore);

>    Alex> Basically, while it _might_ perhaps be nice to have syntax sugar to
>    Alex> avoid having to write pstore twice in this way, I do not think there
>    Alex> is really any burning need for such sugar...

>I'm not that much of syntactic-sugar guy, but tell me how you would do
>this if you needed to allocate an array of objects? 

In the same way as when needing to pass ANY argument whatsoever to
the constructors of objects allocated as part of a new[]'ed builtin
array -- i.e., do without.  The draft standard simply does not support
any non-default constructors for this case, and despite all the
arguments one could muster against this decision (and there are
surely more important and cogent cases than the specific example
of passing an allocator), there isn't a snowball's chance in Hell
that the committee will budge on this point, I believe.  Apparently,
builtin arrays are, reasonably, perceived as very low-level features,
whose use must NOT be encouraged by any enhancement or new support --
witness the recent discussion about the lack of an auto_ptr for
builtin arrays.

Everybody's supposed to be using nicely packaged templates for
arraylike stuff -- and sweat it out if they're *implementing*
the darned "nicely packaged templates".

So, what one does (perhaps inside the template's guts) everytime
one needs a non-default constructor for array elements, is
something like...:

-- use operator new[]() to allocate raw memory (perhaps in a
   suitably overloaded form through an allocator);
-- loop over the raw memory, calling placement new on each
   slice (with whatever nondefault args one needs) to turn
   the raw bits into a living object.

In particular, if need be, one can pass the reference to the
allocato to use in the placement new statement.

>Doesn't anyone else feel there needs to be a link between the
>placement-expression and the constructor? I'm curious 'cos I get the
>feeling I'm missing something... 

Well, there's an old Usenet saying, known as Ugol's Law, that
goes something like "If you ask if you're the only one -- you
aren't".  But the fact that others feel like you does not imply,
of necessity, that it makes sense:-).  Note, for example, how
horribly having a link between placement-expression and ctor
would work in the normal usage case that I outline above, where
I have to use placement new over already-allocated memory (the
normal kind, taking a void*) BUT I have to tell the object to
use another allocator (the one that was originally used to
get the raw-memory, in a *different* point from the placement
expression I'm now using) for its own allocation purposes...!


Alex
--
DISCLAIMER: these are MY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it -- Phone: +39 (51) 597 313  [Fax: 597 120]
Cad.Lab S.p.A., v. Ronzani 7/29, 40033 Casalecchio (BO), Italia


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]