Jeff Thompson | a28eed8 | 2013-08-22 16:21:10 -0700 | [diff] [blame^] | 1 | |
| 2 | [/ Copyright 2005-2008 Daniel James. |
| 3 | / Distributed under the Boost Software License, Version 1.0. (See accompanying |
| 4 | / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) ] |
| 5 | |
| 6 | [section:disable Disabling The Extensions] |
| 7 | |
| 8 | While [classref boost::hash]'s extensions are generally useful, you might want |
| 9 | to turn them of in order to check that your code will work with other |
| 10 | implementations of TR1. To do this define the macro `BOOST_HASH_NO_EXTENSIONS`. |
| 11 | When this macro is defined, only the specialisations detailed |
| 12 | in TR1 will be declared. But, if you later undefine the macro and include |
| 13 | <[headerref boost/functional/hash.hpp]> then the non-specialised form will be defined |
| 14 | - activating the extensions. |
| 15 | |
| 16 | It is strongly recommended that you never undefine the macro - and only define |
| 17 | it so that it applies to the complete translation unit, either by defining it |
| 18 | at the beginning of the main source file or, preferably, by using a compiler |
| 19 | switch or preference. And you really should never define it in header files. |
| 20 | |
| 21 | If you are writing a library which has code in the header which requires the |
| 22 | extensions, then the best action is to tell users not to define the macro. |
| 23 | Their code won't ['require] the macro. |
| 24 | |
| 25 | Translation units that are compiled with the macro defined will link with units |
| 26 | that were compiled without it. This feature has been designed to avoid ODR |
| 27 | violations. |
| 28 | |
| 29 | [endsect] |