This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Bug in std::vector?
- From: Matt Austern <austern at apple dot com>
- To: Dmitriy Morozov <gcc at foxcub dot org>
- Cc: gcc-bugs at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Fri, 14 Mar 2003 15:42:16 -0800
- Subject: Re: Bug in std::vector?
On Friday, March 14, 2003, at 02:54 PM, Dmitriy Morozov wrote:
Hi,
In .../bits/stl_vector.h, in class vector<_Tp, _Alloc>, there is a
typedef value_type* pointer;
while it really should be something like
typedef allocator_type::pointer pointer;
This is just an example, this problem (of assuming that _Tp* is the
pointer to element type) arises throughout the whole vector hierarchy
(and I'm sure appears for other containers as well), and ignores the
fact that one could provide his own pointer type in the allocator. Am
I missing something here, or is this indeed a bug?
It's not exactly a bug. This was a deliberate decision. (Possibly a
mistaken design decision, but definitely deliberate.)
The C++ Standard (clause 20.1.5, paragraphs 4-5) says that a standard
library implementation is encouraged, but not required, to have
containers that allow users to supply their own pointer types. Our
implementation chooses not to support this feature.
Some day we might want to either (a) change our container implementation
so that we do support this feature; or (b) change the C++ Standard so
it removes implementors' freedom to leave this feature out.
Either of those things will take some design work. The reason the
Standard doesn't require this feature to be supported, and the reason
our implementation doesn't support it, is that nobody has ever done the
work of specifying exactly what it would mean: what restrictions a
user-defined "pointer" type would have to satisfy, etc. I once began
that work, but I didn't get all that far.
--Matt