On 08/12/2012 10:00 PM, François Dumont wrote:
On 08/11/2012 03:47 PM, Marc Glisse wrote:
On Sat, 11 Aug 2012, François Dumont wrote:
Your remark on using std::move rather than std::forward Marc made
sens but didn't work. I don't understand why but the new test is
showing that
On 08/13/2012 02:10 PM, Paolo Carlini wrote:
On 08/12/2012 10:00 PM, François Dumont wrote:
Ok for trunk ?
Ok, thanks!
Paolo.
PS: you may want to remove the trailing blank line of
testsuite_counter_type.h
Attached patch applied.
2012-08-13 François Dumont fdum...@gcc.gnu.org
On 11 August 2012 14:47, Marc Glisse wrote:
What testcase failed? I just tried the 2.cc file you added with the patch,
and replacing forwardkey_type(__k) with move(__k) compiled fine.
Shouldn't it be std::move(__k) to disable ADL though?
On Sun, 12 Aug 2012, Jonathan Wakely wrote:
On 11 August 2012 14:47, Marc Glisse wrote:
What testcase failed? I just tried the 2.cc file you added with the patch,
and replacing forwardkey_type(__k) with move(__k) compiled fine.
Shouldn't it be std::move(__k) to disable ADL though?
It is
On 08/11/2012 03:47 PM, Marc Glisse wrote:
On Sat, 11 Aug 2012, François Dumont wrote:
Your remark on using std::move rather than std::forward Marc made
sens but didn't work. I don't understand why but the new test is
showing that std::forward works. If anyone can explain why std::move
Here is an other attempt. I took the time to refactor the hashtable
implementation. I prefer to rename _M_insert_node into
_M_insert_unique_node and use it also into _M_emplace implementation. I
introduce _M_insert_multi_node that is used in _M_insert and _M_emplace
when keys are not
On Sat, 11 Aug 2012, François Dumont wrote:
Your remark on using std::move rather than std::forward Marc made sens
but didn't work. I don't understand why but the new test is showing that
std::forward works. If anyone can explain why std::move doesn't work I am
interested.
What testcase
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
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
On 9 August 2012 09:35, Paolo Carlini wrote:
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*
On 08/09/2012 10:35 AM, Paolo Carlini wrote:
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
On Thu, 9 Aug 2012, François Dumont wrote:
Here is an updated version considering the good catch from Marc. However
I prefer to use an explicit instantiation of tuple rather than using cref
that would have imply inclusion of functional in addition to tuple.
I wouldn't have used make_tuple
On 08/09/2012 11:22 PM, Marc Glisse wrote:
I don't know if std:: is needed, but it looks strange to have it only
on some functions:
std::forward_as_tuple(forwardkey_type(__k)),
Looking at this line again, you seem to be using std::forward on
something that is not a deduced parameter type. I
On Tue, 7 Aug 2012, Richard Smith wrote:
I've attached a patch for unordered_map which solves the rvalue
reference problem. For efficiency, I've created a new
_M_emplace_bucket method rather than call emplace directly.
I've verified all libstdc++ tests pass (sorry for the previous
oversight)
On 08/08/2012 09:34 AM, Marc Glisse wrote:
On Tue, 7 Aug 2012, Richard Smith wrote:
I've attached a patch for unordered_map which solves the rvalue
reference problem. For efficiency, I've created a new
_M_emplace_bucket method rather than call emplace directly.
I've verified all libstdc++
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.
On Wed, 8 Aug 2012, François Dumont wrote:
On 08/08/2012 09:34 AM, Marc Glisse wrote:
On Tue, 7 Aug 2012, Richard Smith wrote:
I've attached a patch for unordered_map which solves the rvalue
reference problem. For efficiency, I've created a new
_M_emplace_bucket method rather than call
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,
On Sat, Aug 4, 2012 at 10:34 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
First, I think we should add libstdc++ in CC.
Thus, I would recommend people working in this area to begin with
unordered_map, because in that case emplace is already available, assuming
that's really the point
Hi,
(adding in CC Francois too)
On 08/07/2012 11:43 PM, Ollie Wild wrote:
On Sat, Aug 4, 2012 at 10:34 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
First, I think we should add libstdc++ in CC.
Thus, I would recommend people working in this area to begin with
unordered_map, because in
On 08/03/2012 05:19 PM, Ollie Wild wrote:
On Fri, Aug 3, 2012 at 2:39 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Ok, but, can you also double check and in case fix unordered_map too?
Looks like we have the same issue, right?
Indeed, we do. I'll send a separate patch for the
.. note anyway, that only the new testcase was failing, no regressions
on pre existing testcases. Thus, it may well be that only the testcase
had issues, whereas the code changes themselves (likewise those for
unordered_map) are fine as they are, no changes needed elsewhere, neithe
in the
On Sat, 4 Aug 2012, Paolo Carlini wrote:
.. note anyway, that only the new testcase was failing, no regressions on pre
existing testcases.
What I am seeing is a different testcase (with the same name but in a
different directory) failing, because:
typedef std::pairconst
On 08/04/2012 03:26 PM, Marc Glisse wrote:
On Sat, 4 Aug 2012, Paolo Carlini wrote:
.. note anyway, that only the new testcase was failing, no
regressions on pre existing testcases.
What I am seeing is a different testcase (with the same name but in a
different directory) failing, because:
On Sat, 4 Aug 2012, Paolo Carlini wrote:
I'm not sure to understand which specific testcase you are discussing, but
for sure we don't want regressions. I agree that we should assume a priori
that the standard is right, but correcting the make_pair should not lead to
failures elsewhere (unless
On 08/04/2012 05:16 PM, Marc Glisse wrote:
On Sat, 4 Aug 2012, Paolo Carlini wrote:
I'm not sure to understand which specific testcase you are
discussing, but for sure we don't want regressions. I agree that we
should assume a priori that the standard is right, but correcting the
make_pair
On Sat, 4 Aug 2012, Paolo Carlini wrote:
On 08/04/2012 05:16 PM, Marc Glisse wrote:
On Sat, 4 Aug 2012, Paolo Carlini wrote:
I'm not sure to understand which specific testcase you are discussing, but
for sure we don't want regressions. I agree that we should assume a priori
that the
On 08/04/2012 05:27 PM, Marc Glisse wrote:
On Sat, 4 Aug 2012, Paolo Carlini wrote:
On 08/04/2012 05:16 PM, Marc Glisse wrote:
On Sat, 4 Aug 2012, Paolo Carlini wrote:
I'm not sure to understand which specific testcase you are
discussing, but for sure we don't want regressions. I agree that
Hi,
On 08/03/2012 06:17 AM, Ollie Wild wrote:
Patch courtesy Richard Smith at Google:
Fix bug in the implementation of std::map's operator[]. Construct an
object of type value_type, rather than using std::make_pair, so as to
allow mapped_type to have an *explicit* copy constructor.
See
On Fri, Aug 3, 2012 at 2:39 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Ok, but, can you also double check and in case fix unordered_map too?
Looks like we have the same issue, right?
Indeed, we do. I'll send a separate patch for the unordered_map problem.
Thanks!
Paolo.
PS:
Patch courtesy Richard Smith at Google:
Fix bug in the implementation of std::map's operator[]. Construct an
object of type value_type, rather than using std::make_pair, so as to
allow mapped_type to have an *explicit* copy constructor.
See [map.access] (23.4.4.3)/5 for the corresponding
31 matches
Mail list logo
