Patch: stl_vector.h

Matt Austern austern@apple.com
Sun Oct 17 18:22:00 GMT 2004


On Oct 16, 2004, at 9:18 PM, Dhruv Matani wrote:

> On Sun, 2004-10-17 at 02:23, Paolo Carlini wrote:
>> Paolo Carlini wrote:
>>
>>> Ok, I found it, and yes, it seems we need add some more too:
>>> 23.1.1/9,10, right?
>>
>> But, Matt, in case we add static_casts at that upper level, is still
>> needed the
>> _Construct with two template arguments? Isn't even slightly 
>> non-conforming,
>> that is, not strictly implementing the requirements for
>> std::allocator::construct
>> in table 32?
>
> I strongly believe that the problem is not with out implementation or
> the lack of sufficient amount of static_casts<> ;-) but with the
> standard's version of allocator::construct(pointer, const_reference). I
> feel this severely limits what you can construct using this function.
> Say you can construct a socket from a file descriptor. Now, using this
> syntax, I first have to manually construct a socket from the fd, and
> then pass the constructed socket to the construct() function so it will
> just to an uninitialized copy of the socket I manually constructed. Now
> it may not always be possible to copy construct a socket eh! So, I feel
> that the changes should go in the allocator::construct(), making it:
>
> template<typename T>
> struct allocator{
> template<typename T1>
> void construct<pointer T1 const& _rt1);
> };
>
> Now, the ctor of the class T which matches the one that takes a T1 can
> be called! Doesn't that sound great?
>
> Matt, I would be interested in proposing this for the standard. Do you
> have any idea how to go about doing this?

Formally, you write up an issue for the Library Working Group issues
list and send it to the chair of the LWG.  (You can do that either
by posting it on comp.std.c++ or by doing it through your
organizations's committee representative.)

Informally: I'm the LWG chair, and I just added this issue to the
issues list.  It's issue 487, and you will find it in the
version of the issues list that's in the post-Redmond mailing.

(I'm in Redmond right now, by the way, so I'll be a little
sporadic in responding to email over the next week.)

			--Matt



More information about the Libstdc++ mailing list