Re: [boost] [hash] documentation issues (was [TR1 Review] TR1 Formal Review Beginning)

From: Daniel James (daniel_at_[hidden])
Date: 2005-10-10 15:10:01

Jonathan Wakely wrote:
> What if some other Boost lib makes use of the extensions internally, so
> that the user shouldn't have to care?  Should Boost libs avoid the
> extension so that they still work if the user defines the macro?
> 
> 
>>Or, I could just have two classes boost::hash & boost::tr1::hash (or 
>>whatever). All of the implementation will still be in hash_value etc. so 
>>there wouldn't be any code bloat. The macro would only affect 
>>boost::tr1::hash, which would still include the extensions by default. 
>>But that seems overly complicated.
> 
> 
> Boost libs could use the extensions under this scheme.

All true. But there will still be the same problem if anyone uses the 
extensions with Boost.TR1. This would inevitably lead to the 
recommendation (but not from me) that if you want to use the extensions 
you should use boost::hash, not std::tr1::hash. But I was convinced by 
Peter and John's arguments (which I linked to before) that the 
extensions should be in Boost.TR1.

Personally, I would see the macro as being similar to 'strict', 'ansi' 
or 'no-extensions' compiler switches which I do find very useful, mainly 
for unit tests where you can generally avoid these kinds of conflicts. 
So the macro might have some use for when you want to guarantee that 
your code will work on other implementations of TR1.

If you find that some other library needs the extensions - you can just 
not define the macro (anything which works without the extensions will 
also work with them). I believe that the only time this would really be 
a problem is if the macro is defined in a header the you can't change. 
Which is why I would suggest that it is never used in that way.

Daniel