This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: stl_vector.h


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]