http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #22 from Jonathan Wakely 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=gcc&view=rev&rev=195231
Log:
PR libstdc++/55043
* include/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.7.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #21 from Paolo Carlini 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 come to
that. Thanks Jon for al
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #20 from Jonathan Wakely 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 vector::emplace_back
doesn't require copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #19 from Paolo Carlini 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 terms.
Given that the moved fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #18 from Daniel Krügler
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 containers move constructors (which is
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #17 from Daniel Krügler
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 consider that as a high price.
> > 2) Th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #16 from Jonathan Wakely 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 #15 from Jonathan Wakely 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
> optional realizes the same effect), but the costs are not small:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #14 from Daniel Krügler
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 means writing constraints based on
> C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #13 from Jonathan Wakely 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 constraints based on
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #12 from Daniel Krügler
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_constructible Args...> shall be satisfied if and on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #11 from Jonathan Wakely 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 implementation of the copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #10 from Daniel Krügler
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 constructor is irrelevant,
> only th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #9 from Marc Glisse 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 prototype matters to determin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
Jonathan Wakely changed:
What|Removed |Added
CC||daniel.kruegler at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #7 from Jonathan Wakely 2012-10-24
01:08:13 UTC ---
It already does use move_if_noexcept, so should work.
The problem is that
std::is_copy_constructible>>::value is
true, so __move_if_noexcept_cond is true for unordered cont
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #6 from Paolo Carlini 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 instantiate
with such kind of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #5 from Jonathan Wakely 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 thrown?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #4 from Paolo Carlini 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 std::deque. In
terms of QoI I think we c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
Jonathan Wakely changed:
What|Removed |Added
Summary|issue with nesting |[4.7/4.8 Regression] issue
22 matches
Mail list logo