Re: std::vector of const values
On Nov 22, 1:52 pm, Dave <thedaverud...@gmail.com> wrote:
I have run into this problem a few times and was hoping there was a
more elegant solution than what I was doing. Suppose I have the
following [erroneous] code:
void doStuff( const std::vector< const int* >& ints )
{
for( size_t i = 0; i != ints.size(); ++i )
std::cout << *ints[ i ] << std::endl;
}
....
std::vector< int* > ints;
....
doStuff( ints );
[snip]
However, it seems to me that, if the compiler wanted to, it could just
treat the argument as vector< const int* > and just proceed. So does
anyone know of a way to do that? Or am I stuck with making copies.
If you want to trust to your "seems to me", then you can assert this
explicitly to the compiler:
doStuff( *reinterpret_cast<const std::vector<const int*>*>
(&ints));
That will produce undefined behaviour - and therefore isn't useful for
production code - but may suit your purposes. Past that, I'm not
personally interested in comments on the appropriateness of this on clc
++m, but if you use it in shared code you should expect "feedback".
Alternatively, the most direct way to model what you're attempting is
to build "glue" between the type being passed, and the restricted
usage your doStuff function is allowed to make of it:
template <typename T>
struct Vector_Const_Ptr
{
Vector_Const_Ptr(const std::vector<T*>& v)
: ref_(v)
{ }
const T* const operator[](size_t n) const { return ref_[n]; }
size_t size() const { return ref_.size(); }
private:
const std::vector<T*> ref_;
};
void doStuff(const Vector_Const_Ptr<int>& ints)
Though a familiar design pattern I'd say this is also ugly and
confusing, but if you insist on getting that const-ness across, then
this is functional.
Better yet, adopt a different approach as suggested by earlier
replies.
Is there some fundamental reason why a vector of non-const values could
not be treated as a vector of const values?
Yes... a template may instantiate code differently for T* and const
T*. For example, the programmer may have used type traits to
differentiate the two at compile time, with alternative code. While
not applicable to the STL, this might be useful: e.g.
- some manner of container of pointers might have a member function to
check for two pointers to the same element,
- given some knowledge of the types the container might hold...
- a non-const version might iterate temporarily marking elements non-
destructively until it sees an already-marked element (result = true)
or reaches the end (result = false),
- it then revisits the earlier elements to remove the mark
- typically faster than building a temporary associative container
to record visited elements.
The compiler has to cope not just with the cleaner less cyclic STL,
but also hackery like the above where the container implementer is
anticipating the container elements and adapting algorithms therefore.
Further - regardless of whether it's practical to do so - the right is
reserved for an optimiser to use the "const"-ness in an attempt to
produce tighter code.
Regards,
Tony
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]