David- First, thanks for the response. BTW, I really like the book. Okay, I understand what you are saying about add_const and how it works. My next question is why was it implemented in that way? In other words, was there a specific reason not to make a special case for references such that add_const<int&> would be int const &? As for the better solution, I'll keep working on it! Chris David Abrahams wrote:
Chris Goller <cgoller@magpiesystems.com> writes:
His solution is SO much better then mine.
You can do even better (hint: you don't need to use add_const).
However, when I first saw it I thought it must be wrong because I assumed that add_const on a reference would would return a const reference. In other words, the code below would be false:
bool a = is_same<add_const<int &>::type, int &>::value;
However! bool "a" is true. So my question is why is "a" true? Why isn't add_const<int &>::type == int const &?
It's not a very interesting answer: that's just the way the C++ type system works.
The rule is, essentially, that
add_const<T>::type
is equivalent to
T const.
When you do that with int&, you get
int& const
Think of that as being like
int* const
The int isn't const, here; the pointer is. But unlike pointers, references can't be made to refer to new things. So
int& const
and
int&
are really the same type. Both are different from
int const&
where the int is immutable through that reference.
HTH,