| 1 | |
|---|
| 2 | [/ Copyright 2005-2006 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] |
|---|