C++ for Scientists - Technische Universität Dresden

5.2. PROVIDING TYPE INFORMATION 141
trans_const.cpp:121: Error: ≫const mtl::matrix::dense2D≪ cannot be converted to ≫int≪
in initialization
Obviously, with this trick we will not get an executable binary. But we know more about the
types in our program and can now better solve our problems. In the rare case that the type you
examine is convertible to int, you can take any other type like std::set to which the examined
class is not convertible. To exclude convertibility entirely you can introduce a new type.
After this short excursion into type introspection we know for certain that the member ref is a
constant reference. The following happens:
• When we call trans(B) the function’s template argument is instantiated with const dense2D.
• Thus, the return type is transposed view.
• The constructor argument has type const dense2D&.
• Likewise the member has type const dense2D&.
It remains the question why the non-const version of the operator (line 9) is called despite we
refer a constant matrix. The answer is that the constancy of ref does not matter for the choice
but whether or not the view object is constant. Thus, we can write:
const tst::transposed view Bt(B);
std::cout ≪ ”Bt(2, 0) = ” ≪ Bt(2, 0) ≪ ’\n’;
This works but it is not very elegant.
A brutal possibility to get the view compiled for constant matrices is to cast away the constancy.
The undesired result would be that mutable views on constant matrices enable the modification
of the allegedly constant matrix. This violates so heavily our principles that we do not even
show how the code would read.
Rule
Never cast away const.
In the following we will empower you with very strong methodologies for handling constancy
correctly. Every const cast is an indicator for a severe design error. As Sutter and Alexandrescu
phrased it “If you go const you never go back.” The only situation where a const cast
is needed by using const-incorrect third-party software, i.e. read-only arguments are passed as
mutable pointers or references. That is not our fault and we have no choice. Unfortunately,
there is still a lot of const-incorrect packages around and some of them would take too much
resources to reimplement that we have to live with them. The best we can do is to add an
appropriate API on top of it and avoid working with the original API. This saves ourselves
from spoiling our applications with const casts and restricts the unspeakable const cast to the
interface. A good example of such a layer is ‘Boost::Bindings’ [?] that provides const-correct