--- Comment #13 from paolo dot carlini at oracle dot com 2009-05-19 18:19
---
It's life, you know ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
--- Comment #12 from jeff at schwabcenter dot com 2009-05-19 18:07 ---
What he said. I'm perusing your patch, and I appreciate that you removed an
artificial restriction. The right place to catch this is up front, in a
concept check, rather than in _Destroy; since I'm not about to add
--- Comment #11 from coleb at eyesopen dot com 2009-05-19 17:57 ---
(In reply to comment #10)
> Look closely at the patch I committed, I changed *nothing* of the actual
> behavior of the containers. Thus the semantics is exactly the same as before,
> only, the destructor in not called ex
--- Comment #10 from paolo dot carlini at oracle dot com 2009-05-19 17:38
---
Look closely at the patch I committed, I changed *nothing* of the actual
behavior of the containers. Thus the semantics is exactly the same as before,
only, the destructor in not called explicitly anymore on s
--- Comment #9 from jeff at schwabcenter dot com 2009-05-19 17:32 ---
OK. Thanks for the explanation. Are the semantics documented somewhere?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
--- Comment #8 from paolo dot carlini at oracle dot com 2009-05-19 17:12
---
This is not going to change again. We had this behaviour forever until 4.3.x
and all the major implementations outside GCC behave the same as GCC now (and
before the change of behavior).
--
http://gcc.gnu.
--- Comment #7 from jeff at schwabcenter dot com 2009-05-19 17:09 ---
I understand the desire for backward compatibility, but are the semantics
actually the same? Are the vector values arrays, or do they decay to pointers?
Section 23.1 says standard container elements have to be CopyCo
--- Comment #6 from paolo dot carlini at oracle dot com 2009-05-19 16:42
---
I think that, in any case, we cannot do anything wrong here: we are simply
restoring an implementation detail of the previous implementations, which, as a
side effect, allows to compile this specific kind of sn
--- Comment #5 from jeff at schwabcenter dot com 2009-05-19 16:36 ---
Whoa whoa whoa... The behavior seemed correct before. vector
shouldn't even be legal. Shouldn't the compiler to catch such a mistake?
--
jeff at schwabcenter dot com changed:
What|Removed
--- Comment #4 from paolo dot carlini at oracle dot com 2009-05-18 23:18
---
Fixed for 4.4.1.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo at gcc dot gnu dot org 2009-05-18 23:17 ---
Subject: Bug 40192
Author: paolo
Date: Mon May 18 23:16:48 2009
New Revision: 147681
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147681
Log:
2009-05-18 Paolo Carlini
PR libstdc++/40192
*
--- Comment #2 from paolo at gcc dot gnu dot org 2009-05-18 23:16 ---
Subject: Bug 40192
Author: paolo
Date: Mon May 18 23:16:20 2009
New Revision: 147680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147680
Log:
2009-05-18 Paolo Carlini
PR libstdc++/40192
*
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-18 22:34
---
I'll fix it momentarily.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
13 matches
Mail list logo
