Re: const_cast in constructors to init const members
* Erik Wikstr?m:
I have a base-class that have some protected members which will be
initialised during construction, however since no derived classes (or
members of the base-class) should change the values of those member I
like to make the const. Unfortunately some of them are not trivial to
initialise (i.e. they can not just be initialised from a value passed
to the constructor. There are two ways I can construct these members,
the first is by using helper-functions:
class Bar {
// Members
const size_t m_nr;
const std::vector<size_t> m_indices;
// Helper function
std::vector<size_t> getIndices(const std::vector<size_t>& v,
size_t n) {
std::vector<size_t> vec;
for (size_t i = 0; i < v.size(); ++i) {
if (v[i] == n) {
vec.push_back(i);
}
}
return vec;
}
public:
// Constructor
Bar(size_t n, const std::vector<size_t>& v)
: m_nr(n), m_indices(getIndices(v, n)) { }
};
This way works but there are two things that I'm not particularly fond
of: I have to write a function(per member) that will only be used
once, and it can become a bit messy when the initialisation of member
B relies on member A already being initialised.
The alternative is to use const_cast in the constructor to allow it to
make modifications to the const members:
class Foo {
// Members
const size_t m_nr;
const std::vector<size_t> m_indices;
public:
// Constructor
Foo(size_t n, const std::vector<size_t>& v)
: m_nr(n)
{
for (size_t i = 0; i < v.size(); ++i) {
if (v[i] == m_nr) {
const_cast<std::vector<size_t>& >(m_indices).push_back(i);
}
}
}
};
The problem with this approach is that it is using const_cast (with
ugly syntax as a result) which I'm not particularly fond of either,
but on the up-side it is easier to read and you do not have to worry
about initialisation order. Is this (modifying the const members)
always safe or is this undefined behaviour?
Technically in-practice it should be OK since the vector doesn't know
that it's const, and was non-const during its own construction. But
formally I don't know and I don't think you should care. Because, you
shouldn't employ any of the two approaches above.
Instead,
class Foo {
private:
Foo( Foo const& );
Foo& operator=( Foo const& );
protected:
struct Indices {
size_t m_nr;
std::vector<size_t> m_values;
Indices(size_t n, const std::vector<size_t>& v)
: m_nr(n)
{
for (size_t i = 0; i < v.size(); ++i) {
if (v[i] == m_nr) {
m_values.push_back(i);
}
}
}
size_t nr() const { return m_nr; }
size_t size() const { return m_values.size(); }
size_t operator[]( size_t i ) const { return m_values[i]; }
};
const Indices m_indices;
public:
Foo(size_t n, const std::vector<size_t>& v)
: m_indices(n, v)
{}
};
The "protected:" here from your requirements spec.
FAQ 18.13* talks a bit
about this but I'm not sure if it applies since it talks about
modifying members in a const member-function.
* http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.13
Well, hm, uh.
(Actually I haven't looked at it)
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?