AllanW@my-dejanews.com wrote:
>
> It would be easy to construct
> a template function that constructs an array of any class
> given a buffer address and a number of elements...

The uninitialized_copy, uninitialized_fill and uninitialized_fill_n
functions in STL do exactly this.

> ...and another one that destructs all of the elements.

I don't see a standard version in STL, but the implementation I've got
(HP->Rogue Wave->Borland) has an internal helper function that does
this.

--

Ciao,
Paul


[ 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 <3655B49B.97D17F08@prolifics.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:
>
> "Paul D. DeRocco" wrote:
> > If, in your placement new[] example, your compiler doesn't construct the
> > zeroth X exactly at the address specified by aPtr, then I would think
> > the compiler writers have misunderstood something. Or perhaps I have,
> > but it all seems pretty clear to me.
>
> You have. Section 5.3.4, paragraph 12, says
>     This overhead may be applied in all array new-expressions,
>     including those referencing the library function operator
>     new[](std::size_t, void *) and other placement allocation
>     functions. The amount of overhead may vary from one
>     invocation of new to another.

This even precludes an application from testing for the overhead
amount and anticipating. E.g.
    std::size_t previous_placement_new_array_size = 0;
    std::size_t operator_new_array_overhead = 0;
    void * operator new[](std::size_t size, void*where) {
        previous_placement_new_array_size = size;
        return where;
    }
    void makeBufferForMyClass(int n) {
        if (operator_new_array_overhead < 1)
        {
            union {
                long double ld;
                long l;
                long double *ldp;
                void(*funcptr)();
                char buffer[sizeof(myClass)*3+1024];
            } x;
            new[(void*)&x] myClass();
            operator_new_array_overhead =
                previous_placement_new_array_size - sizeof(myClass);
            ((myClass*)&x)->~myClass();
        }
        int need_size = sizeof(myClass)*n+operator_new_array_overhead;
        myClass*addr = (myClass*)myAlloc(need_size);
        return new[(void*)addr] myClass[n];
    }
This calculates the amount of overhead needed by operator new[].
But according to the snipped posted above the amount of overhead
can vary from one allocation to the next, so this won't work!

I think that a "placement" new[] that simply returns it's void*
argument is faulty. A proper implementation must react to the
size_t argument at run-time, and can make very few assumptions
about it's value. It would be less dangerous to ignore the void*
argument! But if we do that, it degenerates into an exact clone
of non-placement new[].

Perhaps the only safe way to do this is to eschew (good word,
huh?) all use of placement new[] at all; instead, use placement
new (the non-array version). After all, we're likely to know
how big our arrays are anyway. It would be easy to construct
a template function that constructs an array of any class
given a buffer address and a number of elements, and another
one that destructs all of the elements. That way the only
overhead is whatever we're already using to keep track of
the number of elements. This is somewhat error-prone (the user
could easily supply the wrong number of elements), but in light
of placement-new[]'s behavior it may be the safest course!

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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              ]

Hyman Rosen wrote:
>
> You have. Section 5.3.4, paragraph 12, says
>   This overhead may be applied in all array new-expressions, including
>   those referencing the library function operator new[](std::size_t,
>   void *) and other placement allocation functions. The amount of
>   overhead may vary from one invocation of new to another.

Well, I can't argue with that. Or I can't argue that the standard
doesn't say that, but it looks like a flaw to me.

I think that placement-new introduces a small can of worms, in that it
is used for two unrelated things, with conflicting requirements. In the
most general case, the new and new[] operators that take extra
parameters have nothing to do with "placement" at all, but are merely a
way of passing additional information to the operators; it might be used
to steer allocation into a particular type of memory, for instance. In
this case, the overhead is still necessary for operator new[], because
we still need the ability to destroy the correct number of objects even
if some unrelated code uses delete[] on a pointer to the zeroth array
element.

The "placement" use of these operators is kind of a special case,
although the fact that they call these variants "placement-new" and
"placement-delete" implies that this usage was in fact the primary
purpose of including this syntax in the language. In this special case,
the compiler doesn't need to record the length of the array, because the
caller is taking responsibility for destroying the objects. That is,
each call to placement-new[] is expected to be balanced by a loop
containing explicit calls to the destructor.

In this latter case, as was pointed out at the start of this thread, if
the compiler includes this overhead, but keeps the amount a secret, then
no one can use placement-new[] in this manner, except the compiler
writers themselves, who are in on the secret.

Borland's (or Rogue Wave's) STL avoids this problem by never using
placement-new[] in its STL. It uses individual calls to the non-array
form of placement-new in a loop, but makes no effort (that I can see) to
clean up the already constructed items should one of them throw an
exception during construction. At least this is true in Borland 5.01.

This makes me wonder why we have to use this screwball syntax to invoke
a constructor, but not a destructor. If we can say x->~T() to destroy a
T pointed to by x, why can't we say x->T(...) to construct a T in the
memory pointed to by x? Then we could reserve the "placement" variants
for non-placement uses, where their semantics don't significantly differ
from the plain versions of the operators.

--

Ciao,
Paul
---
[ 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              ]

"Paul D. DeRocco" wrote:
> If, in your placement new[] example, your compiler doesn't construct the
> zeroth X exactly at the address specified by aPtr, then I would think
> the compiler writers have misunderstood something. Or perhaps I have,
> but it all seems pretty clear to me.

You have. Section 5.3.4, paragraph 12, says
    This overhead may be applied in all array new-expressions, including those
    referencing the library function operator new[](std::size_t, void *) and
    other placement allocation functions. The amount of overhead may vary from
    one invocation of new to another.


[ 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 in message <365395A5.CABB481B@acm.org>...
>Larry Brasfield wrote:
>>
>> Pete Becker wrote in message <3653144D.8A863861@acm.org>...
>> >Ken Walter wrote:
>> >>
>> >> Placement new[] on my compiler requires particular implementation
>> >> knowledge.
>> >
>> >The standard prohibits this. operator new[](size_t) is supposed to be
>> >called with an argument that gives the total number of bytes required by
>> >the implementation.

Please note that the new overload referred to above is
NOT "placement new".  It is ordinary, unadorned new.

>> I believe you have missed Mr. Walter's point.  "Placement new[]"
>> is used when allocation is handled outside the automatice C++
>> mechanisms, ("Over the covers", we might say.), typically using
>> the overload, "void * new(size_t, void *)".  To permit that allocation
>> to be performed before the placement new statement is executed,
>> some user-written code needs to know how much memory to set
>> aside, (address of which is then passed as the void * argument.)

An important point here, (perhaps not yet made sufficiently
explicit), is that the user's allocation *must* be performed
before using placement new to make efficient use of the
placement new mechanism.  It might be possible to do an
allocation, try the placement new construction statement,
then deallocate, reallocate and retry upon discovering
that the guessed overhead was insufficient, but that is a
lot of bother for what should be a simple operation.

>> The problem to which Mr. Walters alludes is that he cannot tell
>> how much extra memory to allocate beyond what the objects
>> themselves will occupy without either making assumptions about
>> the implementation or doing experiments for the implementations
>> to be targeted.  Either choice violates the notion that it is possible
>> to write portable C++ code if only C++ features are relied upon.
>
>He doesn't need to know. The runtime system asks for the memory that it
>needs, including any "extra" storage space. Be sceptical when testing
>this: if the class that you're allocating doesn't have a destructor then
>no extra space is needed.

But Pete, when placement new is invoked, the memory
has already been allocated.  If more is asked for than
what was allocated by the user, then there is no way
for the placement new function to know what to do.
(And of course, the standard placement new merely
returns the void * it was given, implying that this was
not intended to be an exercise of much intelligence.)

I suspect, from your mention of operator new[](size_t)
above when operator new[](size_t, void *) is the topic
of this discussion, that you have no real disagreement
with Mr. Walter's or my perception of the problem.

--Larry Brasfield
Above opinions may be mine alone.
X-Replace-Address
(Humans may reply at unundered larry_br@sea_net.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              ]

Hyman Rosen <hymie@prolifics.com> writes:

>Steve Clamage wrote:
>> The added overhead must be an integral multiple of the worst-case
>> alignment for any object that fits in requested size. Unfortunately,
>> there is no standard way to find out what that alignment is, and
>> no way to find out what integral multiple the compiler uses. (At
>> least, not from inside the program using portable code. The compiler
>> documentation might tell you, but of course the value can differ
>> among implementations.)

>Really? How about this?

>struct sizer { };
>void *operator new[](size_t b, const sizer &) { throw b; }

>template<typename T>
>size_t
>size(size_t n)
>{
> sizer s;
> try {
>  new(s) T[n];
> } catch (size_t b) {
>  return b;
> }
>}

I must get out of the habit of saying "no way" or "can't be done". :-)

What I should have said is that the standard doesn't provide a
direct way to make such queries.

Your template looks like it will do the job at run time.

It doesn't help at compile time, however, in determining how much
static storage to set aside for an array of T.

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

Hyman Rosen wrote:
>
> Really? How about this?
>
> struct sizer { };
> void *operator new[](size_t b, const sizer &) { throw b; }
>
> template<typename T>
> size_t
> size(size_t n)
> {
>         sizer s;
>         try {
>                 new(s) T[n];
>         } catch (size_t b) {
>                 return b;
>         }
> }

This is a nice idea. There is just one little subtle point
in the Standard that states that the amount of overhead
may vary from one invocation of new to another (5.3.4/12).
I doubt that any reasonable implementation would do this,
but the wording is still there.

Regards
//Gabriel



[ 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:
> He doesn't need to know. The runtime system asks for the memory that it
> needs, including any "extra" storage space. Be sceptical when testing
> this: if the class that you're allocating doesn't have a destructor then
> no extra space is needed.

He does need to know if he's trying to allocate the memory outside of
operator new[], for use in a subsequent placement new.
---
[ 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              ]

Larry Brasfield wrote:
>
> I suspect, from your mention of operator new[](size_t)
> above when operator new[](size_t, void *) is the topic
> of this discussion, that you have no real disagreement
> with Mr. Walter's or my perception of the problem.

Sure I do. You guys should have been talking about array new, not
placement new, like I was. <g>

--
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 e3Hcgbrpl1Vl@eir.stiscan.com, icedancer.zamboni@ibm.zamboni.net (Ken Walter) writes:

>Placement new[] on my compiler requires particular implementation
>knowledge.
>
>Example:
>class X{...};  //  say sizeof( X )== 4
>                    // sizeof( X[10] ) == 40

>Using the library new X[10], the compiler in this case adds 8 bytes of
>overhead
>and then calls the constructor 10 times inline assuming an 8 byte offset.
>It does the same thing with new( aPtr ) X[10].
>The program must know that on this system it must
>malloc( sizeof( X[10])+8 ).  On some other system it may be different.
>If this class' placement new requires other overhead it must adjust
>the size inside the method and "fix" the returned pointer.

>Is there some reason in the standard that requires the compiler to add
>the overhead or could/should this be done in the library new[]()?

The compiler is not required to add the overhead, but is explicitly
allowed to add it for array allocations. (See the infamous 5.3.4
paragraph 10, which was discussed to death recently in this
newsgroup.)

The added overhead must be an integral multiple of the worst-case
alignment for any object that fits in requested size. Unfortunately,
there is no standard way to find out what that alignment is, and
no way to find out what integral multiple the compiler uses. (At
least, not from inside the program using portable code. The compiler
documentation might tell you, but of course the value can differ
among implementations.)

As a practical matter, it is unlikely that the overhead will be
more than 16 bytes, so you could reserve an extra 16 or 32 bytes
and be reasonably safe.

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

Ken Walter wrote:
>
> Placement new[] on my compiler requires particular implementation
> knowledge.

The standard prohibits this. operator new[](size_t) is supposed to be
called with an argument that gives the total number of bytes required by
the implementation.

--
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 in message <3653144D.8A863861@acm.org>...
>Ken Walter wrote:
>>
>> Placement new[] on my compiler requires particular implementation
>> knowledge.
>
>The standard prohibits this. operator new[](size_t) is supposed to be
>called with an argument that gives the total number of bytes required by
>the implementation.

I believe you have missed Mr. Walter's point.  "Placement new[]"
is used when allocation is handled outside the automatice C++
mechanisms, ("Over the covers", we might say.), typically using
the overload, "void * new(size_t, void *)".  To permit that allocation
to be performed before the placement new statement is executed,
some user-written code needs to know how much memory to set
aside, (address of which is then passed as the void * argument.)

The problem to which Mr. Walters alludes is that he cannot tell
how much extra memory to allocate beyond what the objects
themselves will occupy without either making assumptions about
the implementation or doing experiments for the implementations
to be targeted.  Either choice violates the notion that it is possible
to write portable C++ code if only C++ features are relied upon.

Now, it might be reasonable to keep the size in the allocation
and verify that the new(size_t, void *) call has not exceeded
what was set aside, so at least crashes can be portably
avoided.  But I see no way to ensure success beyond setting
aside some "large enough, for sure on non-absurd systems"
amound of memory on each allocation for the overhead that
is likely, (according to my glimpse under the covers) to be
necessary for array new statements.

--Larry Brasfield
Above opinions may be mine alone.
(Humans may reply at unundered larry_br@sea_net.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              ]

Ken Walter wrote:
>
> Placement new[] on my compiler requires particular implementation
> knowledge.
>
> Example:
> class X{...};  //  say sizeof( X )== 4
>                     // sizeof( X[10] ) == 40
>
> Using the library new X[10], the compiler in this case adds 8 bytes of
> overhead and then calls the constructor 10 times inline assuming an 8
> byte offset. It does the same thing with new( aPtr ) X[10].
> The program must know that on this system it must
> malloc( sizeof( X[10])+8 ).  On some other system it may be different.
> If this class' placement new requires other overhead it must adjust
> the size inside the method and "fix" the returned pointer.

When you call "new X[10]", you're asking the compiler to manage the
memory allocation. It therefore needs some secret amount of storage to
record the number of elements in the array, so that when you say
"delete[] x" somewhere else in the program, it will know how many times
to call the destructor. You seem to understand that.

However, when you call "new(aPtr) X[10]", you're telling the compiler
that you're taking responsibility for the memory allocation, and also
for the ultimate destruction and deallocation. The compiler should not
require any extra overhead, beyond sizeof(X[10]), for recording how many
items to destroy, because it will never destroy them automatically. It
is up to you to record that information yourself, if it is variable.

The only time the compiler will automatically destroy items that were
constructed as a result of placement new or placement new[] is if the
constructor throws an exception. In this case, the destruction is
happening in the same piece of the code that did the construction, so
the compiler knows how many items to destroy.

If, in your placement new[] example, your compiler doesn't construct the
zeroth X exactly at the address specified by aPtr, then I would think
the compiler writers have misunderstood something. Or perhaps I have,
but it all seems pretty clear to me.

--

Ciao,
Paul


[ 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 wrote:
> The added overhead must be an integral multiple of the worst-case
> alignment for any object that fits in requested size. Unfortunately,
> there is no standard way to find out what that alignment is, and
> no way to find out what integral multiple the compiler uses. (At
> least, not from inside the program using portable code. The compiler
> documentation might tell you, but of course the value can differ
> among implementations.)

Really? How about this?

struct sizer { };
void *operator new[](size_t b, const sizer &) { throw b; }

template<typename T>
size_t
size(size_t n)
{
 sizer s;
 try {
  new(s) T[n];
 } catch (size_t b) {
  return b;
 }
}
---
[ 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              ]

Larry Brasfield wrote:
>
> Pete Becker wrote in message <3653144D.8A863861@acm.org>...
> >Ken Walter wrote:
> >>
> >> Placement new[] on my compiler requires particular implementation
> >> knowledge.
> >
> >The standard prohibits this. operator new[](size_t) is supposed to be
> >called with an argument that gives the total number of bytes required by
> >the implementation.
>
> I believe you have missed Mr. Walter's point.  "Placement new[]"
> is used when allocation is handled outside the automatice C++
> mechanisms, ("Over the covers", we might say.), typically using
> the overload, "void * new(size_t, void *)".  To permit that allocation
> to be performed before the placement new statement is executed,
> some user-written code needs to know how much memory to set
> aside, (address of which is then passed as the void * argument.)
>
> The problem to which Mr. Walters alludes is that he cannot tell
> how much extra memory to allocate beyond what the objects
> themselves will occupy without either making assumptions about
> the implementation or doing experiments for the implementations
> to be targeted.  Either choice violates the notion that it is possible
> to write portable C++ code if only C++ features are relied upon.

He doesn't need to know. The runtime system asks for the memory that it
needs, including any "extra" storage space. Be sceptical when testing
this: if the class that you're allocating doesn't have a destructor then
no extra space is needed.

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

On Wed, 18 Nov 1998 21:56:33, Larry Brasfield <larry_br@sea_net.com>
wrote:

>
> Pete Becker wrote in message <3653144D.8A863861@acm.org>...
> I believe you have missed Mr. Walter's point.  "Placement new[]"
> is used when allocation is handled outside the automatice C++
> mechanisms, ("Over the covers", we might say.), typically using
> the overload, "void * new(size_t, void *)".  To permit that allocation
> to be performed before the placement new statement is executed,
> some user-written code needs to know how much memory to set
> aside, (address of which is then passed as the void * argument.)
[...]

Exactly.  I think I understand the problem better now.
The compiler must know about the element count at run time to call the
destructor for each.  It knows this count except when the array is
allocated
by new so sizeof( X[10] ) is the actual data size.  Although new[]
could add the extra
info, the compiler would still need to know it is there.

The only way I can see to get around the problem would be to add
something to the standard environment macros like NEWVECTOROVERHEAD
which allow the programmer implementation independent access to this
value.

Ken Walter

Remove .zamboni to reply
All the above is hearsay and the opinion of no one in particular
---
[ 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              ]

Placement new[] on my compiler requires particular implementation
knowledge.

Example:
class X{...};  //  say sizeof( X )== 4
                    // sizeof( X[10] ) == 40

Using the library new X[10], the compiler in this case adds 8 bytes of
overhead
and then calls the constructor 10 times inline assuming an 8 byte offset.
It does the same thing with new( aPtr ) X[10].
The program must know that on this system it must
malloc( sizeof( X[10])+8 ).  On some other system it may be different.
If this class' placement new requires other overhead it must adjust
the size inside the method and "fix" the returned pointer.

Is there some reason in the standard that requires the compiler to add
the overhead or could/should this be done in the library new[]()?
Having to deduce the overhead for each compiler and use conditional
#defines for each  is ugly.


Ken Walter

Remove .zamboni to reply
All the above is hearsay and the opinion of no one in particular


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