Hi,
On 08/09/2012 09:14 AM, Marc Glisse wrote:
On Wed, 8 Aug 2012, François Dumont wrote:
On 08/08/2012 03:39 PM, Paolo Carlini wrote:
On 08/08/2012 03:15 PM, François Dumont wrote:
I have also introduce a special std::pair constructor for container
usage so that we do not have to include the whole tuple stuff just
for associative container implementations.
To be clear: sorry, this is not an option.
Paolo.
Then I can only imagine the attached patch which require to
include tuple when including unordered_map or unordered_set. The
std::pair(piecewise_construct_t, tuple<>, tuple<>) is the only
constructor that allow to build a pair using the default constructor
for the second member.
I agree that the extra constructor would be convenient (I probably
would have gone with pair(T&&,__default_construct_t), the symmetric
version, and enough extra constructors to resolve all ambiguities).
Maybe LWG would consider doing something.
When it does, and the corresponding PR will be *ready* we'll reconsider
the issue. After all the *months and months and months* spent by the LWG
adding and removing members from pair and tweaking everything wrt the
containers and issues *still* popping up (like that with the defaulted
copy constructor vs insert constraining), and with the support for
scoped allocators still missing from our implementation, we are not
adding members to std::pair such easily. Sorry, but personally I'm not
available now to further discuss this specific point.
I was still hoping that for something as simple as mapped_type() we
wouldn't need the full <tuple> machinery, and I encourage everybody to
have another look (while making sure anything we figure out adapts
smoothly an consistently to std::map), then in a few days we'll take a
final decision. We'll still have chances to further improve the code in
time for 4.8.0.
+ __p = __h->_M_allocate_node(std::piecewise_construct,
+ std::make_tuple(__k),
+ std::make_tuple());
Don't you want cref(__k)? It might save a move at some point.
Are we already doing that elsewhere? I think we should aim for something
simple first, then carefully evaluate if the additional complexity is
worth the cost and in case deploy the superior solution consistently
everywhere it may apply.
Thanks!
Paolo.
