Re: Containers of pointers and const-correctness
* Stuart Golodetz:
Alf P. Steinbach wrote:
* Stuart Golodetz:
#include <vector>
struct B {};
struct D1 : B {};
struct D2 : B {};
int main()
{
std::vector<D1*> vD1;
// Doesn't compile (shouldn't)
//std::vector<B*>& vB = vD1;
// Doesn't compile (shouldn't)
//std::vector<const D1*>& vCD1C = vD1;
// Doesn't compile (but why would it be a bad thing if it did?)
const std::vector<const D1*>& CvCD1 = vD1;
return 0;
}
Assume the vector has 1 element, which is a pointer.
A reference to a vector of 1 element is (with respect to what counts
here) functionally equivalent to a pointer to a vector of 1 element,
which is functionally equivalent to a pointer to a pointer.
So you're asking why you can't do
T* p = ...
T** pp = &p;
T const** PP = pp;
It would break const correctness, allowing you to modify an original
const thing.
See the FAQ item titled "Why am I getting an error converting a Foo**
to const Foo**", currently 18.17 and available at e.g. <url:
http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.17>.
I've seen that actually (I've been hanging around in this newsgroup for
a while, so read the FAQ quite a few times!), but thanks for the link
:-) I did wonder whether/how that might be an issue here. I got as far
as thinking:
std::vector<int*> v;
&v[0] is of type int **
const std::vector<const int*>
&v[0] is of type const int **
Oh. My Bad, sorry. I though what you didn't understand was the second "doesn't
compile" (actually I think I misread your code), but if I read you correctly
you're clear on that and wondering about the third.
And so my explanation of a different issue misled you.
In the second example above the type of v[0] is 'int const* const&', so applying
the address operator yields 'int const* const*', no problem.
So the third "doesn't compile" would be OK if std::vector supported that.
But in order to support it it would need a conversion operator, like
<code>
template< typename T >
struct Constified { typedef T Type; };
template< typename T >
struct Constified<T*> { typedef T const* Type; };
template< typename T >
class Array
{
private:
T elems[1];
public:
T& operator[]( int i ) { return elems[i]; }
T const& operator[]( int i ) const { return elems[i]; }
operator Array< typename Constified<T>::Type > const& () const
{
return reinterpret_cast<
Array< typename Constified<T>::Type > const&
>( *this );
}
};
void foo( Array<int const*> const& ) {}
int main()
{
foo( Array<int*>() );
Array<int>();
}
</code>
Now this appears to be fine (hark) good standard C++, but e.g. MSVC 7.1 is very
unhappy with the operator definition.
And I guess that that practical issue of specifying something that compilers of
the time could easily be upgraded to support, was considered by those proposing
things, sort of filtering out "difficult" proposals.
Not to mention that it would have increased the standard's size & complexity.
There is, however, also another issue hinted at by your code, having
to do with upcast/downcast of a collection.
The answer for that other issue is that the standard library
containers do not support all that they in principle could support
within type safety.
Ok, fair enough. I don't suppose anyone's suggested augmenting them in a
future revision of the standard? Or is that not a Pandora's box which
anyone particularly wants to open, since it probably doesn't bother
large numbers of people? :-)
I'm not sure, but I think it is, yes. Would require a lot of work. Anyway, it
seems we're now into 3 distinct issues:
* why the second "doesn't compile" doesn't and shouldn't compile, which you
already knew, namely as addressed in the FAQ item;
* why the third doesn't compile (simply not supported); and
* why base/derived referent conversions aren't supported (it's a bit
complicated, e.g. Java gives up on that and does runtime checking!).
Cheers,
- Alf