http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-16
09:20:43 UTC ---
Author: redi
Date: Wed Jan 16 09:20:34 2013
New Revision: 195231
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195231
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #10 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-10-24 06:37:05 UTC ---
(In reply to comment #9)
(In reply to comment #8)
is this a bug in is_constructible?
I don't think so. The implementation of the copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-24
08:25:04 UTC ---
(In reply to comment #10)
(In reply to comment #9)
(In reply to comment #8)
is this a bug in is_constructible?
I don't think so. The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #12 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-10-24 08:33:47 UTC ---
(In reply to comment #11)
That seems inconsistent with 20.9.4.3/6
the predicate condition for a template specialization is_constructibleT,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-24
09:10:38 UTC ---
Ah yes, you're right.
So to make the testcase compile (which it should) I'd need to use sfinae to
disable the container members, which means writing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #14 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-10-24 09:23:22 UTC ---
(In reply to comment #13)
So to make the testcase compile (which it should) I'd need to use sfinae to
disable the container members, which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-24
15:40:28 UTC ---
(In reply to comment #14)
I think it is implementable (I have done something similar to ensure that my
optionalT realizes the same effect), but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-24
17:36:52 UTC ---
I have a better idea: specialize is_copy_constructible for each std::container
to depend on whether its value type is CopyInsertable into it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #17 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-10-24 17:48:07 UTC ---
(In reply to comment #15)
1) It will prevent the incomplete type support
Ouch... but not required by the standard.
I agree, but I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #18 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-10-24 18:12:25 UTC ---
(In reply to comment #17)
Looking at the concrete problem here I think the only thing that is needed
is a conditional noexcept for all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #19 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-24
18:51:24 UTC ---
Essentially memory allocation is needed because that is the simplest state
for such containers, what the default constructor also does in other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #20 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-24
20:03:52 UTC ---
It's conforming for unordered_map to have a possibly-throwing move ctor, but it
must be possible to insert it into a vector, because
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-24
20:28:59 UTC ---
Totally agreed it would be better (in Italian in such cases we say something
like you are trying to open a door which is already open ;) We'll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Summary|issue with nesting |[4.7/4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-23
22:53:06 UTC ---
Unfortunately, I don't think we can simply add noexcept to the move ctor,
because it does allocate memory. Something similar happens for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-23
23:06:43 UTC ---
Oh dear.
If a type is not nothrow MoveInsertable and is not CopyInsertable, should we
just move it, with unspecified behaviour if an except is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-23
23:14:17 UTC ---
I suppose the logic could be the same of move_if_noexcept? In any case, I guess
we have to handle such unlikely circumstances, somebody could well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-24
01:08:13 UTC ---
It already does use move_if_noexcept, so should work.
The problem is that
std::is_copy_constructiblestd::unordered_setstd::unique_ptrint::value is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #9 from Marc Glisse glisse at gcc dot gnu.org 2012-10-24 03:04:16
UTC ---
(In reply to comment #8)
is this a bug in is_constructible?
I don't think so. The implementation of the copy constructor is irrelevant,
only the
22 matches
Mail list logo
