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

From: Chris Goller (cgoller_at_[hidden])
Date: 2005-02-15 16:44:48

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_at_[hidden]> 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,
>
>  
>