From: Neal Becker (ndbecker2_at_[hidden])
Date: 2007-02-05 07:39:18
Gunter Winkler wrote:
> On Saturday 03 February 2007 17:05, Neal Becker wrote:
>> OK, here is a try:
>> (note, this also includes the proposed serialization patch)
> I think we should split the patch in 2 parts (and remove the serialization
> Part 1:
> - all changes from new to alloc.construct(..) and similar.
> - I'd like to shift the loop + consruct to
> detail::uninitilized_fill_a(first, last, value, alloc)
> (which can later be forwarded to the STL or adopted to different
> Part 2:
> - the trivial constructor check that completely skips the initialize
> Is this reasonable?
Can any other interested parties review my changes, and check that I did
pick up all the required(desired) changes of new?
* storage types (other than unbounded)
BTW, I agree in principal that a specialized allocator is all that is
required and that the trivial constructor check is a bit redundant. I
believe we should keep it anyway because:
* explicit is better than implicit
* it costs nothing
* the correct allocator behavior depends on correct supporting