const and strict aliasing rules

[John L. Kulp]

I have a situation where I have a class that internally maintains a 
container object of non-const objects that it wants to publish to 
clients as a const container of const objects, that is, clients can't 
modify the list or the items in the list.  The data member wants to be 
non-const because the managing class needs to create and delete the foo 
objects.


data member:
   PtrList listOfFoo;

publishing member functions:
const PtrList &GetFooList () const {
   return reinterpret_cast&>(listOfFoo);
}

This results in the warning:
"type punning to incomplete type might break strict aliasing rules"
because the types aren't exactly the same with regard to cv qualifiers.  
While I understand the general issue of aliasing incompatible types, 
simply adding const qualifiers shouldn't provoke aliasing warnings, as I 
believe it is a reasonable thing to want to do, at least in the 
direction of adding const.  I understand it is probably hard to detect 
this in situations like the above.  Perhaps there is a need for the 
inverse to the const_cast construct, namely, add const rather than 
remove it.


You can work around this by using union's of pointers of both non-const 
and const types, but the reinterpret_cast solution would be more attractive.


Thoughts?

STL vector::resize

[John L. Kulp]

Shouldn't the last (optional) argument be (1) const and (2) a reference 
(rather than a potentially very expensive copying call-by-value)?  Among 
other things, if you have a type declared with alignment attributes, it 
will fail on this.  I notice the MSVC implementation has (1) but not 
(2).  I can't see any code that would depend on the value being copied.