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
Ollie Wild
*
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 std::forward
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
doe
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 forward(__k) with move(__k) compiled fine.
Shouldn't it be std::move(__k) to disable ADL though?
It is written st
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 forward(__k) with move(__k) compiled fine.
Shouldn't it be std::move(__k) to disable ADL though?
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 f
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 unique
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(forward(__k)),
Looking at this line again, you seem to be using std::forward on
something that is not a deduced parameter type. I guess it i
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 in addition to .
I wouldn't have used make_tuple at all (tuple<>
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
contai
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*
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 th
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 contain
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
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 empla
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 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++ tes
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) a
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 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 alre
On Sat, Aug 4, 2012 at 10:34 AM, Paolo Carlini 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 (and therefore reve
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
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 standard
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 sh
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 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:
.. 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::pair V;
static_assert(std:
.. 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 specs
On 08/03/2012 05:19 PM, Ollie Wild wrote:
On Fri, Aug 3, 2012 at 2:39 AM, Paolo Carlini 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.
But apparentl
On Fri, Aug 3, 2012 at 2:39 AM, Paolo Carlini 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: remember that all the
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 [map.ac
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 standard
31 matches
Mail list logo
