* [Bug libstdc++/55963] std::vector<const T> fails
2013-01-13 18:15 [Bug libstdc++/55963] New: std::vector<const T> fails corey at octayn dot net
@ 2013-01-13 18:16 ` corey at octayn dot net
2013-01-13 19:05 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: corey at octayn dot net @ 2013-01-13 18:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55963
--- Comment #1 from Corey Richardson <corey at octayn dot net> 2013-01-13 18:16:05 UTC ---
Created attachment 29157
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29157
g++ output
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug libstdc++/55963] std::vector<const T> fails
2013-01-13 18:15 [Bug libstdc++/55963] New: std::vector<const T> fails corey at octayn dot net
2013-01-13 18:16 ` [Bug libstdc++/55963] " corey at octayn dot net
@ 2013-01-13 19:05 ` redi at gcc dot gnu.org
2013-01-13 22:44 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2013-01-13 19:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55963
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-01-13 19:04:43 UTC ---
I disagree with the claim it's required to work. It's true that container
requirements have been relaxed so requirements on types are more fine-grained
and only apply to specific operations, but std::vector<const int> instantiates
std::allocator<const int> and that creates ambiguous overloads of
std::allocator<const int>::address(reference) and std::allocator<const
int>::address(const_reference) because reference and const_reference are the
same type.
I would argue it's required not to work, based on the explicit definition of
std::allocator given in the C++11 standard.
I've been thinking about altering std::allocator so it works though, so I'll
confirm this as an extension.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug libstdc++/55963] std::vector<const T> fails
2013-01-13 18:15 [Bug libstdc++/55963] New: std::vector<const T> fails corey at octayn dot net
2013-01-13 18:16 ` [Bug libstdc++/55963] " corey at octayn dot net
2013-01-13 19:05 ` redi at gcc dot gnu.org
@ 2013-01-13 22:44 ` redi at gcc dot gnu.org
2013-01-13 23:53 ` corey at octayn dot net
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2013-01-13 22:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55963
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-01-13 22:43:56 UTC ---
Looks like PJP's comment was from 2008, so I'm not sure what requirements he
means were standardized in 2008.
Looking further into it, I see that the Allocator requirements in C++11 say an
allocator can only be instantiated with a non-const type, see
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274
Because vector<const T> instantiates allocator<const T> that makes it
definitely ill-formed.
So I think I'm going to add a static_assert to std::allocator that rejects
const types, so the error is at least clear it's intentional not a bug.
To make it work you could write your own thin wrapper around std::allocator
that prevents instantiating it with const types, something like:
template<typename T>
struct allocator
: std::allocator<typename std::remove_const<T>::type>
{
template<typename U>
struct rebind { typedef allocator<U> other; };
typedef T value_type;
allocator() = default;
allocator(const allocator&) = default;
template<typename U>
allocator(const allocator<U>&) { }
};
Then use std::vector<const int, allocator<const int>>.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug libstdc++/55963] std::vector<const T> fails
2013-01-13 18:15 [Bug libstdc++/55963] New: std::vector<const T> fails corey at octayn dot net
` (2 preceding siblings ...)
2013-01-13 22:44 ` redi at gcc dot gnu.org
@ 2013-01-13 23:53 ` corey at octayn dot net
2013-01-14 22:29 ` redi at gcc dot gnu.org
2014-09-19 13:31 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: corey at octayn dot net @ 2013-01-13 23:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55963
--- Comment #4 from Corey Richardson <corey at octayn dot net> 2013-01-13 23:52:59 UTC ---
A more clear error message would be really useful, the feature itself
isn't all that important to me. Thank you for giving this your
attention so quickly.
On Sun, Jan 13, 2013 at 5:43 PM, redi at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55963
>
> --- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-01-13 22:43:56 UTC ---
> Looks like PJP's comment was from 2008, so I'm not sure what requirements he
> means were standardized in 2008.
>
> Looking further into it, I see that the Allocator requirements in C++11 say an
> allocator can only be instantiated with a non-const type, see
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274
>
> Because vector<const T> instantiates allocator<const T> that makes it
> definitely ill-formed.
>
> So I think I'm going to add a static_assert to std::allocator that rejects
> const types, so the error is at least clear it's intentional not a bug.
>
> To make it work you could write your own thin wrapper around std::allocator
> that prevents instantiating it with const types, something like:
>
> template<typename T>
> struct allocator
> : std::allocator<typename std::remove_const<T>::type>
> {
> template<typename U>
> struct rebind { typedef allocator<U> other; };
>
> typedef T value_type;
>
> allocator() = default;
>
> allocator(const allocator&) = default;
>
> template<typename U>
> allocator(const allocator<U>&) { }
> };
>
> Then use std::vector<const int, allocator<const int>>.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug libstdc++/55963] std::vector<const T> fails
2013-01-13 18:15 [Bug libstdc++/55963] New: std::vector<const T> fails corey at octayn dot net
` (3 preceding siblings ...)
2013-01-13 23:53 ` corey at octayn dot net
@ 2013-01-14 22:29 ` redi at gcc dot gnu.org
2014-09-19 13:31 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2013-01-14 22:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55963
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2013-01-14
AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-01-14 22:28:26 UTC ---
I'll add the assertions for 4.8.1
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug libstdc++/55963] std::vector<const T> fails
2013-01-13 18:15 [Bug libstdc++/55963] New: std::vector<const T> fails corey at octayn dot net
` (4 preceding siblings ...)
2013-01-14 22:29 ` redi at gcc dot gnu.org
@ 2014-09-19 13:31 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2014-09-19 13:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55963
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Same issue
*** This bug has been marked as a duplicate of bug 48101 ***
^ permalink raw reply [flat|nested] 7+ messages in thread