public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/16875] New: Fails to compile: STL container of const pointer to X
@ 2004-08-04 12:41 loose at astron dot nl
2004-08-04 12:46 ` [Bug c++/16875] " loose at astron dot nl
` (9 more replies)
0 siblings, 10 replies; 11+ messages in thread
From: loose at astron dot nl @ 2004-08-04 12:41 UTC (permalink / raw)
To: gcc-bugs
The IMHO valid C++ code in the sample program tt.cc (see below) fails to
compile. I've tried using different STL containers, but the result was (more or
less) the same. I've tried to compile this code with three different versions
of gcc (3.2.1, 3.2.2, and 3.4.1), and all three fail. Furthermore, I've tried
to compile it with the Intel C++ compiler (v8.0) which accepts the code.
$ g++ -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-
checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
$ g++ -save-temps tt.cc
/usr/include/c++/3.2.2/bits/stl_alloc.h: In instantiation of `std::allocator<X*
const>':
tt.cc:9: instantiated from here
/usr/include/c++/3.2.2/bits/stl_alloc.h:674: `const _Tp*
std::allocator<_Alloc>::address(const _Tp&) const [with _Tp = X* const]' and
`_Tp* std::allocator<_Alloc>::address(_Tp&) const [with _Tp = X* const]'
cannot be overloaded
/usr/include/c++/3.2.2/bits/stl_construct.h: In function `void
std::_Construct(_T1*, const _T2&) [with _T1 = X* const, _T2 = X*]':
/usr/include/c++/3.2.2/bits/stl_list.h:328: instantiated from
`std::_List_node<_Tp>* std::list<_Tp, _Alloc>::_M_create_node(const _Tp&) [with
_Tp = X* const, _Alloc = std::allocator<X* const>]'
/usr/include/c++/3.2.2/bits/stl_list.h:430: instantiated from
`std::_List_iterator<_Tp, _Tp&, _Tp*> std::list<_Tp, _Alloc>::insert
(std::_List_iterator<_Tp, _Tp&, _Tp*>, const _Tp&) [with _Tp = X* const, _Alloc
= std::allocator<X* const>]'
/usr/include/c++/3.2.2/bits/stl_list.h:479: instantiated from `void
std::list<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = X* const, _Alloc =
std::allocator<X* const>]'
tt.cc:10: instantiated from here
/usr/include/c++/3.2.2/bits/stl_construct.h:78: static_cast from type `X*
const*' to type `void*' casts away constness
$ cat tt.cc
#include <list>
struct X
{
};
int main()
{
std::list<X* const> li;
li.push_back(new X());
}
--
Summary: Fails to compile: STL container of const pointer to X
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: loose at astron dot nl
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16875
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/16875] Fails to compile: STL container of const pointer to X
2004-08-04 12:41 [Bug c++/16875] New: Fails to compile: STL container of const pointer to X loose at astron dot nl
@ 2004-08-04 12:46 ` loose at astron dot nl
2004-08-05 2:07 ` [Bug libstdc++/16875] " pinskia at gcc dot gnu dot org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: loose at astron dot nl @ 2004-08-04 12:46 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From loose at astron dot nl 2004-08-04 12:46 -------
Created an attachment (id=6880)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6880&action=view)
Precompiler output tt.ii for the source file tt.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16875
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/16875] Fails to compile: STL container of const pointer to X
2004-08-04 12:41 [Bug c++/16875] New: Fails to compile: STL container of const pointer to X loose at astron dot nl
2004-08-04 12:46 ` [Bug c++/16875] " loose at astron dot nl
@ 2004-08-05 2:07 ` pinskia at gcc dot gnu dot org
2004-08-05 8:03 ` gdr at integrable-solutions dot net
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-08-05 2:07 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-08-05 02:07 -------
Invalid as 20.4.1 for allocator:
pointer address(reference x) const;
const_pointer address(const_reference x) const;
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16875
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/16875] Fails to compile: STL container of const pointer to X
2004-08-04 12:41 [Bug c++/16875] New: Fails to compile: STL container of const pointer to X loose at astron dot nl
2004-08-04 12:46 ` [Bug c++/16875] " loose at astron dot nl
2004-08-05 2:07 ` [Bug libstdc++/16875] " pinskia at gcc dot gnu dot org
@ 2004-08-05 8:03 ` gdr at integrable-solutions dot net
2004-10-06 20:08 ` pinskia at gcc dot gnu dot org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: gdr at integrable-solutions dot net @ 2004-08-05 8:03 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gdr at integrable-solutions dot net 2004-08-05 08:03 -------
Subject: Re: Fails to compile: STL container of const pointer to X
"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:
| ... indeed, the error:
|
| /usr/include/c++/3.2.2/bits/stl_alloc.h:674: `const _Tp*
| std::allocator<_Alloc>::address(const _Tp&) const [with _Tp = X* const]' and
| `_Tp* std::allocator<_Alloc>::address(_Tp&) const [with _Tp = X* const]'
| cannot be overloaded
|
| definitely makes sense for _Tp == X* const!
|
| Gaby?
The code shown in the report does not make sense: You can't put a
const T in a standard sequence.
People have figured out that there is another issue with allocator.
So the PR is doubly invalid :-)
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16875
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/16875] Fails to compile: STL container of const pointer to X
2004-08-04 12:41 [Bug c++/16875] New: Fails to compile: STL container of const pointer to X loose at astron dot nl
` (2 preceding siblings ...)
2004-08-05 8:03 ` gdr at integrable-solutions dot net
@ 2004-10-06 20:08 ` pinskia at gcc dot gnu dot org
2004-10-06 20:32 ` pinskia at gcc dot gnu dot org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-10-06 20:08 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-06 20:08 -------
*** Bug 17866 has been marked as a duplicate of this bug. ***
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16875
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/16875] Fails to compile: STL container of const pointer to X
2004-08-04 12:41 [Bug c++/16875] New: Fails to compile: STL container of const pointer to X loose at astron dot nl
` (3 preceding siblings ...)
2004-10-06 20:08 ` pinskia at gcc dot gnu dot org
@ 2004-10-06 20:32 ` pinskia at gcc dot gnu dot org
2004-10-06 22:04 ` igodard at pacbell dot net
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-10-06 20:32 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-06 20:32 -------
*** Bug 17866 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16875
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/16875] Fails to compile: STL container of const pointer to X
2004-08-04 12:41 [Bug c++/16875] New: Fails to compile: STL container of const pointer to X loose at astron dot nl
` (4 preceding siblings ...)
2004-10-06 20:32 ` pinskia at gcc dot gnu dot org
@ 2004-10-06 22:04 ` igodard at pacbell dot net
2004-10-07 1:23 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: igodard at pacbell dot net @ 2004-10-06 22:04 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From igodard at pacbell dot net 2004-10-06 22:04 -------
I've reopened this PR after looking at #16875 (which I can't re-open, although
I've cross-posted this note there). The basic argument to reject that bug was
that putting consts in a standard collection is non-sensical, because the
collections re-organize themselves and you can't do that with a const element
type. This seems shortsighted, as my application shows (the test case I
submitted was simplified from the actual use).
In my application, I have a number of data values (the number is statically
known) that I need to put into a data structure and subsequently do various
kinds of searches on them. The searchers are not to be permitted to change the
values once they are in the structure. Using "int" as the element and "vector"
as the collection (mine is more complicated), the code looks something like:
vector<const int> v;
#define count = 5
v.reserve(count);
void init() { for (int i = 0; i < count; ++i) {int j; j << cin;
v.push_back(j);}} // push_back works because it constructs, not copies
void use() { for_each(v.begin(), v.end(), something()); }
That is, I want to be able to use the whole algorithm and collection
machinery without re-inventing the wheel, on a standard collection and that
collection's contents that will be immutable once it is built. This seems a
reasonable need to me; do you differ and still think it is non-sensical?
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16875
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/16875] Fails to compile: STL container of const pointer to X
2004-08-04 12:41 [Bug c++/16875] New: Fails to compile: STL container of const pointer to X loose at astron dot nl
` (5 preceding siblings ...)
2004-10-06 22:04 ` igodard at pacbell dot net
@ 2004-10-07 1:23 ` pinskia at gcc dot gnu dot org
2004-10-07 2:22 ` igodard at pacbell dot net
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-10-07 1:23 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-07 01:23 -------
*** Bug 17866 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16875
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/16875] Fails to compile: STL container of const pointer to X
2004-08-04 12:41 [Bug c++/16875] New: Fails to compile: STL container of const pointer to X loose at astron dot nl
` (6 preceding siblings ...)
2004-10-07 1:23 ` pinskia at gcc dot gnu dot org
@ 2004-10-07 2:22 ` igodard at pacbell dot net
2004-10-07 2:50 ` pinskia at gcc dot gnu dot org
2004-10-07 7:32 ` loose at astron dot nl
9 siblings, 0 replies; 11+ messages in thread
From: igodard at pacbell dot net @ 2004-10-07 2:22 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From igodard at pacbell dot net 2004-10-07 02:22 -------
For the record, the following was posted on comp.std.c++:
Try:
std::allocator<const int> a;
This fails on gcc and is permitted in icc and the other EDG derivatives. While
allocating const objects may seem non-sensical, that's what you do when you have
a standard collection of const value type. And you have (or want to have) such a
collection of const objects whenever you have a bunch of data that you want to
put in a standard collection to use standard algorithms on (say for searching)
but which will be (or should be) immutable once the collection is constructed.
g++ complains about the definition of the "address" function in std::allocator,
and the g++ folks say (in response to the PR, bug #16875; see also #17866):
"Invalid as 20.4.1 for allocator:
pointer address(reference x) const;
const_pointer address(const_reference x) const;"
However, the utility of the application is obvious and the utility of the
restriction is not, so I propose that the library specification be changed to
support allocators (and by implication collections) of const element type.
Apparently icc uses a specialization of allocator to merge the declarations of
"address" when the argument type is const, which is a pretty trivial fix. No
existing code would be invalidated by the change.
Sincerely,
Ivan Godard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16875
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/16875] Fails to compile: STL container of const pointer to X
2004-08-04 12:41 [Bug c++/16875] New: Fails to compile: STL container of const pointer to X loose at astron dot nl
` (7 preceding siblings ...)
2004-10-07 2:22 ` igodard at pacbell dot net
@ 2004-10-07 2:50 ` pinskia at gcc dot gnu dot org
2004-10-07 7:32 ` loose at astron dot nl
9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-10-07 2:50 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-07 02:50 -------
*** Bug 17866 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16875
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/16875] Fails to compile: STL container of const pointer to X
2004-08-04 12:41 [Bug c++/16875] New: Fails to compile: STL container of const pointer to X loose at astron dot nl
` (8 preceding siblings ...)
2004-10-07 2:50 ` pinskia at gcc dot gnu dot org
@ 2004-10-07 7:32 ` loose at astron dot nl
9 siblings, 0 replies; 11+ messages in thread
From: loose at astron dot nl @ 2004-10-07 7:32 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From loose at astron dot nl 2004-10-07 07:32 -------
(In reply to comment #12)
...
> Apparently icc uses a specialization of allocator to merge the declarations
of
> "address" when the argument type is const, which is a pretty trivial fix. No
> existing code would be invalidated by the change.
...
After I posted this bug, with the notion that ICC did compile my code example
with a container of const elements, I've been looking at the ICC STL header
files, and (no offense to Intel, etc.) they seem to be based on STLport and
look rather ancient. For instance, under the hood, this STL implementations
uses void pointers throughout. This probably explains why my original example
did compile using ICC. So, in short, the changes to be made to the GCC STL
implementation will probably not be trivial, unless one would like to go back
to the type unsafe void pointer era.
Furthermore, as was noted in comment #12, this is a more fundamental issue. The
current C++ standard is pretty clear about the allocator rule (of which I was
unaware at the time of submitting the bug report), however the reason behind
this rule is very unclear and appears needlessly restrictive to me. Does anyone
in the C++ standardization committee have something to say about this?
Marcel Loose.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16875
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-10-07 7:32 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-04 12:41 [Bug c++/16875] New: Fails to compile: STL container of const pointer to X loose at astron dot nl
2004-08-04 12:46 ` [Bug c++/16875] " loose at astron dot nl
2004-08-05 2:07 ` [Bug libstdc++/16875] " pinskia at gcc dot gnu dot org
2004-08-05 8:03 ` gdr at integrable-solutions dot net
2004-10-06 20:08 ` pinskia at gcc dot gnu dot org
2004-10-06 20:32 ` pinskia at gcc dot gnu dot org
2004-10-06 22:04 ` igodard at pacbell dot net
2004-10-07 1:23 ` pinskia at gcc dot gnu dot org
2004-10-07 2:22 ` igodard at pacbell dot net
2004-10-07 2:50 ` pinskia at gcc dot gnu dot org
2004-10-07 7:32 ` loose at astron dot nl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).