This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: unordered containers emplace
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: François Dumont <frs dot dumont at gmail dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, Christopher Jefferson <chris at bubblescope dot net>
- Date: Wed, 7 Dec 2011 13:14:07 +0000
- Subject: Re: unordered containers emplace
- References: <4EDBD234.8030208@gmail.com> <4EDF55A2.5080104@oracle.com>
On 7 December 2011 12:01, Paolo Carlini wrote:
> Much more importantly, I don't think we are doing the right thing for map /
> multimap; honestly I cannot say to have followed in any special detail the
> standardization of the piecewise_construct_t things, at the corresponding
> ISO Meetings, but I think we have to involve that pair constructor in this
> case. I'm adding Jon and Chris in CC for you to have more help on this,
> please also have a look to various papers authored by Pablo Halpern et al
> over the last 2/3 years.
>
I might be wrong, as I'm only going by reading the cotnainer
requirements not all the past discussion, but I think emplace should
just do alloc.construct(p, std::forward<Args>(args)...)
If the value_type is a std::pair and the user wants to create it with
more than two arguments, they can call emplace( piecewise_construct,
make_tuple(...), make_tuple(...) )
I don't think the library should call the piecewise constructor
directly, only when the function parameter pack contains
piecewise_construct_t, and the right constructor will be chosen by
normal overload resolution.