https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
Geoff Romer changed:
What|Removed |Added
CC||gromer at google dot com
--- Comment #14 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
--- Comment #13 from Jonathan Wakely ---
The C++11 standard clarifies that this is intended to work. The range
constructors require the type to be EmplaceConstructible into the container
from the iterator's value_type, which means calling
allocato
--- Comment #12 from paolo dot carlini at oracle dot com 2008-11-29 17:05
---
Subject: Re: STL treats explicit constructors as converting constructors
> The Standard does not require that std::uninitialized_copy be
> invoked when
> constructing an std::vector or...
Sure, but certa
--- Comment #11 from konto dot dydaktyczne at gmail dot com 2008-11-29
16:40 ---
(In reply to comment #10)
> an explicit constructor constructs objects only where the
> direct-initialization syntax or where casts are explicitly used. None of these
> cases occurs in the code above.
I m
--- Comment #10 from konto dot dydaktyczne at gmail dot com 2008-11-29
16:36 ---
(In reply to comment #9)
The Standard does not require that std::uninitialized_copy be invoked when
constructing an std::vector or std::deque.
Moreover, an explicit constructor constructs objects only whe
--- Comment #9 from paolo dot carlini at oracle dot com 2008-11-28 11:40
---
... and I'm coming to the conclusion that this is not a bug in our library.
Consider the std::vector case: I cannot see anything wrong with using
std::uninitialized_copy in the implementation of the constructor
--- Comment #8 from paolo dot carlini at oracle dot com 2008-11-28 11:30
---
The issue is different because if I remove all uses of _Construct and implement
the various uninitialized_* per the letter of the Standard, nothing changes...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #7 from konto dot dydaktyczne at gmail dot com 2008-11-28
11:23 ---
(In reply to comment #1)
> GCC 4.4.0 also accepts this code as does Comeau 4.3.10.1.
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
does not accept this code.
--
http:/
--- Comment #6 from paolo dot carlini at oracle dot com 2008-11-28 11:17
---
Hummm, the issue seems different than I remembered it. Will see..
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
--- Comment #5 from paolo dot carlini at oracle dot com 2008-11-28 11:03
---
But I see now that al long time ago list & co also used _Construct, this is
indeed an inconsistency... Let's see what we can do here...
--
paolo dot carlini at oracle dot com changed:
What|R
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-28 10:50
---
Yes, this is obvious, just grep for _Construct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
--- Comment #3 from konto dot dydaktyczne at gmail dot com 2008-11-28
10:07 ---
Let me add an std::list and an std::set to my code; see below. Both additions
produce errors. So,
[sequence containers]
std::vector -> no error signaled, "explicit" ignored
std::list
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-25 19:48
---
Unless I'm badly mistaken, this behaviour, dating back to the original HP/SGI
STL and as such very difficult to change now, is a small extension due to the
use in the containers of _Construct instead of calling
14 matches
Mail list logo
