Re: const_cast in constructors to init const members
* Erik Wikstr?m:
On Feb 15, 10:44 am, "Alf P. Steinbach" <al...@start.no> wrote:
* 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:
[znip]
The alternative is to use const_cast in the constructor to allow it to
make modifications to the const members:
[znip]
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)
{}
};
Yes, using a wrapper is certainly nice, but then I would have to write
one wrapper class for each const member (unless there are two that can
be initialised in the same way), which can be a bit tiresome
(especially if I need to support much of the container's interface).
Well then, make the members non-const private and provide
const-enforcing protected accessor functions.
And I still have to worry about the order of initialisation when they
are dependent on each other.
You'll have to worry about that no matter which solution you land on,
except by enforcing initialization order via inheritance chain of dummy
classes.
If initialization order really is a general problem then it indicates
some design flaw, most likely lack of encapsulation in classes. Because
the items that have initialization order dependencies are strongly
connected and probably form some useful abstractions. So, for that,
think design, not language-level technical solution.
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?