Re: Containers of pointers and const-correctness
Alf P. Steinbach wrote:
* 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.
Ok, I think I was getting confused.
So the third "doesn't compile" would be OK if std::vector supported that.
Indeed! I was wondering if there was some reason for it not to support
it beyond "it's rather tricky to do" :-) Because it seemed to satisfy
LSP ok, so I just wondered whether there was another problem I'd missed.
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>
And in this case, I guess the reinterpret_cast is definitely fine
because it's supplied within Array?
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
Ok, work-around time then :-) See else-thread for the best alternative
I've managed to dig up.
* why base/derived referent conversions aren't supported (it's a bit
complicated, e.g. Java gives up on that and does runtime checking!).
There may be two issues here as well. I guess we might want this to compile:
std::vector<D1*> vD1;
const std::vector<const B*>& CvCB = vD1;
But the example above involving std::vector<B*>& shouldn't. In the case
of Java, you definitely shouldn't be able to convert a
Container<Derived> to a Container<Base>, because there's no notion of
const-ness there - you could just insert something else into the
Container<Base> and completely mess things up (this much was drummed
into us at university) :-) In C++ the issue seems more subtle.
Cheers,
Stu
Cheers,
- Alf