Re: [Boost-users] Re: metaprogramming exercise 2-0

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 would be int const &? As for the better solution, I'll keep working on it! Chris David Abrahams wrote:

Chris Goller 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::type, int &>::value;

However! bool "a" is true. So my question is why is "a" true? Why isn't add_const::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,