[12] | 1 | <html> |
---|
| 2 | <head> |
---|
| 3 | <title></title> |
---|
| 4 | <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
---|
| 5 | <meta name="Template" content="C:\PROGRAM FILES\MICROSOFT OFFICE\OFFICE\html.dot"> |
---|
| 6 | <meta name="GENERATOR" content="Microsoft FrontPage 5.0"> |
---|
| 7 | </head> |
---|
| 8 | <body bgcolor="#ffffff" link="#0000ff" vlink="#800080"> |
---|
| 9 | <p align="left"><img src="../../boost.png" alt="Boost" width="277" height="86"></p> |
---|
| 10 | <h1 align="center">Boost Configuration Reference</h1> |
---|
| 11 | <h2>Contents</h2> |
---|
| 12 | <pre><a href="#configuring">Configuring Boost for Your Platform</a> |
---|
| 13 | <a href="#default_config">Using the default boost configuration |
---|
| 14 | </a> <a href="#header">The <boost\config.hpp> header</a> |
---|
| 15 | <a href="#config_script">Using the configure script</a> |
---|
| 16 | <a href="#user_settable">User settable options</a> |
---|
| 17 | <a href="#advanced_config">Advanced configuration usage</a> |
---|
| 18 | <a href="#testing">Testing the boost configuration</a> |
---|
| 19 | <a href="#macro_ref">Boost Macro Reference</a> |
---|
| 20 | <a href="#defects">Macros that describe defects</a> |
---|
| 21 | <a href="#features">Macros that describe optional features</a> |
---|
| 22 | <a href="#helpers">Boost Helper Macros</a> |
---|
| 23 | <a href="#info_macros">Boost Informational Macros</a> |
---|
| 24 | <a href="#source">Macros for libraries with separate source code</a> |
---|
| 25 | <a href="#guidelines">Guidelines for Boost Authors</a> |
---|
| 26 | <a href="#defect_guidelines">Adding New Defect Macros</a> |
---|
| 27 | <a href="#feature_guidelines">Adding New Feature Test Macros</a> |
---|
| 28 | <a href="#modify_guidelines">Modifying the Boost Configuration Headers</a> |
---|
| 29 | <a href="#rationale">Rationale</a> |
---|
| 30 | <a href="#Acknowledgements">Acknowledgements</a></pre> |
---|
| 31 | <h2><a name="configuring"></a>Configuring Boost for Your Platform</h2> |
---|
| 32 | <h4><a name="default_config"></a>Using the default boost configuration</h4> |
---|
| 33 | <p>Boost is comes already configured for most common compilers and platforms; you |
---|
| 34 | should be able to use boost "as is". Since the compiler is configured |
---|
| 35 | separately from the standard library, the default configuration should work |
---|
| 36 | even if you replace the compiler's standard library with a third-party standard |
---|
| 37 | library (like <a href="http://www.stlport.org">STLport</a>). |
---|
| 38 | </p> |
---|
| 39 | <p>Using boost "as is" without trying to reconfigure is the recommended method for |
---|
| 40 | using boost. You can, however, run the configure script if you want to, and |
---|
| 41 | there are regression tests provided that allow you to test the current boost |
---|
| 42 | configuration with your particular compiler setup.</p> |
---|
| 43 | <p>Boost library users can request support for additional compilers or platforms |
---|
| 44 | by visiting our <a href="http://sourceforge.net/tracker/?group_id=7586">Tracker</a> |
---|
| 45 | and submitting a support request. |
---|
| 46 | </p> |
---|
| 47 | <h4>The <a href="../../boost/config.hpp"><boost/config.hpp></a> <a name="header"> |
---|
| 48 | header</a></h4> |
---|
| 49 | <p>Boost library implementations access configuration macros via <code>#include |
---|
| 50 | <boost/config.hpp></code>. |
---|
| 51 | </p> |
---|
| 52 | <P>While Boost library users are not required to include that file directly, or |
---|
| 53 | use those configuration macros, such use is acceptable. The configuration |
---|
| 54 | macros are documented as to their purpose, usage, and limitations which makes |
---|
| 55 | them usable by both Boost library and user code. |
---|
| 56 | </P> |
---|
| 57 | <P>Boost <A href="#info_macros">informational</A> or <A href="#helpers">helper</A> |
---|
| 58 | macros are designed for use by Boost users as well as for our own internal |
---|
| 59 | use. Note however, that the <A href="#features">feature test</A> and <A href="#defects"> |
---|
| 60 | defect test</A> macros were designed for internal use by Boost libraries, |
---|
| 61 | not user code, so they can change at any time (though no gratuitous changes are |
---|
| 62 | made to them). Boost library problems resulting from changes to the |
---|
| 63 | configuration macros are caught by the Boost regression tests, so the Boost |
---|
| 64 | libraries are updated to account for those changes. By contrast, Boost library |
---|
| 65 | user code can be adversely affected by changes to the macros without warning. |
---|
| 66 | The best way to keep abreast of changes to the macros used in user code is to |
---|
| 67 | monitor the discussions on the Boost developers list.</P> |
---|
| 68 | <h4><a name="config_script">Using the configure script</a></h4> |
---|
| 69 | <p>If you know that boost is incorrectly configured for your particular setup, and |
---|
| 70 | you are on a UNIX like platform, then you may want to try and improve things by |
---|
| 71 | running the boost configure script. From a shell command prompt you will need |
---|
| 72 | to cd into <boost-root>/libs/config/ and type:</p> |
---|
| 73 | <pre>sh ./configure</pre> |
---|
| 74 | <p>you will see a list of the items being checked as the script works it way |
---|
| 75 | through the regression tests. Note that the configure script only really |
---|
| 76 | auto-detects your compiler if it's called g++, c++ or CC. If you are using some |
---|
| 77 | other compiler then you will need to set one or more of the following |
---|
| 78 | environment variables:</p> |
---|
| 79 | <table border="1" cellpadding="7" cellspacing="1" width="624"> |
---|
| 80 | <tr> |
---|
| 81 | <td valign="top" width="50%"><p align="center"><b>Variable</b></p> |
---|
| 82 | </td> |
---|
| 83 | <td valign="top" width="50%"><p align="center"><b>Description</b></p> |
---|
| 84 | </td> |
---|
| 85 | </tr> |
---|
| 86 | <tr> |
---|
| 87 | <td valign="top" width="50%">CXX</td> |
---|
| 88 | <td valign="top" width="50%">The name of the compiler, for example "c++".</td> |
---|
| 89 | </tr> |
---|
| 90 | <tr> |
---|
| 91 | <td valign="top" width="50%">CXXFLAGS</td> |
---|
| 92 | <td valign="top" width="50%">The compiler flags to use, for example "-O2".</td> |
---|
| 93 | </tr> |
---|
| 94 | <tr> |
---|
| 95 | <td valign="top" width="50%">LDFLAGS</td> |
---|
| 96 | <td valign="top" width="50%">The linker flags to use, for example "-L/mypath".</td> |
---|
| 97 | </tr> |
---|
| 98 | <tr> |
---|
| 99 | <td valign="top" width="50%">LIBS</td> |
---|
| 100 | <td valign="top" width="50%">Any libraries to link in, for example -lpthread.</td> |
---|
| 101 | </tr> |
---|
| 102 | </table> |
---|
| 103 | <p>For example to run the configure script with HP aCC, you might use something |
---|
| 104 | like:</p> |
---|
| 105 | <pre>export CXX="aCC" |
---|
| 106 | export CXXFLAGS="-Aa |
---|
| 107 | -DAportable -D__HPACC_THREAD_SAFE_RB_TREE -DRWSTD_MULTI_THREAD -DRW_MULTI_THREAD -D_REENTRANT -D_THREAD_SAFE" export LDFLAGS="-DAportable" |
---|
| 108 | export LIBS= |
---|
| 109 | "-lpthread" sh |
---|
| 110 | ./configure</pre> |
---|
| 111 | <p>However you run the configure script, when it finishes you will find a new |
---|
| 112 | header - user.hpp - located in the <boost-root/libs/config/> directory. <b><i>Note |
---|
| 113 | that configure does not install this header into your boost include path by |
---|
| 114 | default.</i></b> This header contains all the options generated by the |
---|
| 115 | configure script, plus a header-section that contains the user settable options |
---|
| 116 | from the default version of <a href="../../boost/config/user.hpp">user.hpp</a> (located |
---|
| 117 | under <boost-root>/boost/config/). There are two ways you can use this |
---|
| 118 | header:</p> |
---|
| 119 | <p>Option 1: copy the header into <boost-root>/boost/config/ so that it |
---|
| 120 | replaces the default <a href="../../boost/config/user.hpp">user.hpp</a> provided |
---|
| 121 | by boost. This option allows only one configure-generated setup; boost |
---|
| 122 | developers should avoid this option, as it incurs the danger of accidentally |
---|
| 123 | committing a configure-modified user.hpp to the cvs repository (something you |
---|
| 124 | will not be thanked for!).</p> |
---|
| 125 | <p>Option 2: give the header a more memorable name, and place it somewhere |
---|
| 126 | convenient, then define the macro BOOST_USER_CONFIG to point to it. For example |
---|
| 127 | create a new sub-directory <boost-root>/boost/config/user/, and copy the |
---|
| 128 | header there; for example as "multithread-gcc-config.hpp". Then when compiling |
---|
| 129 | add the command line option: |
---|
| 130 | -DBOOST_USER_CONFIG="boost/config/user/multithread-gcc-config.hpp", and boost |
---|
| 131 | will use the new configuration header. This option allows you to generate more |
---|
| 132 | than one configuration header, and to keep them separate from the boost source |
---|
| 133 | - so that updates to the source do not interfere with your configuration.</p> |
---|
| 134 | <h4><a name="user_settable"></a>User settable options</h4> |
---|
| 135 | <p>There are some configuration-options that represent user choices, rather than |
---|
| 136 | compiler defects or platform specific options. These are listed in |
---|
| 137 | <boost/config/user.hpp> and at the start of a configure-generated |
---|
| 138 | user.hpp header. You can define these on the command line, or by editing |
---|
| 139 | <boost/config/user.hpp>, they are listed in the following table: </p> |
---|
| 140 | <table border="1" cellpadding="7" cellspacing="1" width="100%"> |
---|
| 141 | <tr> |
---|
| 142 | <td valign="top" width="48%"><p align="center"><b>Macro</b></p> |
---|
| 143 | </td> |
---|
| 144 | <td valign="top" width="52%"><p align="center"><b>Description</b></p> |
---|
| 145 | </td> |
---|
| 146 | </tr> |
---|
| 147 | <tr> |
---|
| 148 | <td valign="top" width="48%">BOOST_USER_CONFIG</td> |
---|
| 149 | <td valign="top" width="52%">When defined, it should point to the name of the user |
---|
| 150 | configuration file to include prior to any boost configuration files. When not |
---|
| 151 | defined, defaults to <<a href="../../boost/config/user.hpp">boost/config/user.hpp</a>>.</td> |
---|
| 152 | </tr> |
---|
| 153 | <tr> |
---|
| 154 | <td valign="top" width="48%">BOOST_COMPILER_CONFIG</td> |
---|
| 155 | <td valign="top" width="52%">When defined, it should point to the name of the |
---|
| 156 | compiler configuration file to use. Defining this cuts out the compiler |
---|
| 157 | selection logic, and eliminates the dependency on the header containing that |
---|
| 158 | logic. For example if you are using gcc, then you could define |
---|
| 159 | BOOST_COMPILER_CONFIG to "<a href="../../boost/config/compiler/gcc.hpp">boost/config/compiler/gcc.hpp</a>".</td> |
---|
| 160 | </tr> |
---|
| 161 | <tr> |
---|
| 162 | <td valign="top" width="48%">BOOST_STDLIB_CONFIG</td> |
---|
| 163 | <td valign="top" width="52%">When defined, it should point to the name of the |
---|
| 164 | standard library configuration file to use. Defining this cuts out the standard |
---|
| 165 | library selection logic, and eliminates the dependency on the header containing |
---|
| 166 | that logic. For example if you are using STLport, then you could define |
---|
| 167 | BOOST_STDLIB_CONFIG to "<a href="../../boost/config/stdlib/stlport.hpp">boost/config/stdlib/stlport.hpp</a>".</td> |
---|
| 168 | </tr> |
---|
| 169 | <tr> |
---|
| 170 | <td valign="top" width="48%">BOOST_PLATFORM_CONFIG</td> |
---|
| 171 | <td valign="top" width="52%">When defined, it should point to the name of the |
---|
| 172 | platform configuration file to use. Defining this cuts out the platform |
---|
| 173 | selection logic, and eliminates the dependency on the header containing that |
---|
| 174 | logic. For example if you are compiling on linux, then you could define |
---|
| 175 | BOOST_PLATFORM_CONFIG to "<a href="../../boost/config/platform/linux.hpp">boost/config/platform/linux.hpp</a>".</td> |
---|
| 176 | </tr> |
---|
| 177 | <tr> |
---|
| 178 | <td valign="top" width="48%">BOOST_NO_COMPILER_CONFIG</td> |
---|
| 179 | <td valign="top" width="52%">When defined, no compiler configuration file is |
---|
| 180 | selected or included, define when the compiler is fully conformant with the |
---|
| 181 | standard, or where the user header (see BOOST_USER_CONFIG), has had any options |
---|
| 182 | necessary added to it, for example by an autoconf generated configure script.</td> |
---|
| 183 | </tr> |
---|
| 184 | <tr> |
---|
| 185 | <td valign="top" width="48%">BOOST_NO_STDLIB_CONFIG</td> |
---|
| 186 | <td valign="top" width="52%">When defined, no standard library configuration file |
---|
| 187 | is selected or included, define when the standard library is fully conformant |
---|
| 188 | with the standard, or where the user header (see BOOST_USER_CONFIG), has had |
---|
| 189 | any options necessary added to it, for example by an autoconf generated |
---|
| 190 | configure script.</td> |
---|
| 191 | </tr> |
---|
| 192 | <tr> |
---|
| 193 | <td valign="top" width="48%">BOOST_NO_PLATFORM_CONFIG</td> |
---|
| 194 | <td valign="top" width="52%">When defined, no platform configuration file is |
---|
| 195 | selected or included, define when the platform is fully conformant with the |
---|
| 196 | standard (and has no useful extra features), or where the user header (see |
---|
| 197 | BOOST_USER_CONFIG), has had any options necessary added to it, for example by |
---|
| 198 | an autoconf generated configure script.</td> |
---|
| 199 | </tr> |
---|
| 200 | <tr> |
---|
| 201 | <td valign="top" width="48%">BOOST_NO_CONFIG</td> |
---|
| 202 | <td valign="top" width="52%">Equivalent to defining all of |
---|
| 203 | BOOST_NO_COMPILER_CONFIG, BOOST_NO_STDLIB_CONFIG and BOOST_NO_PLATFORM_CONFIG.</td> |
---|
| 204 | </tr> |
---|
| 205 | <tr> |
---|
| 206 | <td valign="top">BOOST_STRICT_CONFIG</td> |
---|
| 207 | <td>The normal behavior for compiler versions that are newer than the last known |
---|
| 208 | version, is to assume that they have all the same defects as the last known |
---|
| 209 | version. By setting this define, then compiler versions that are newer than the |
---|
| 210 | last known version are assumed to be fully conforming with the standard. This |
---|
| 211 | is probably most useful for boost developers or testers, and for those who want |
---|
| 212 | to use boost to test beta compiler versions.</td> |
---|
| 213 | </tr> |
---|
| 214 | <tr> |
---|
| 215 | <td valign="top">BOOST_ASSERT_CONFIG</td> |
---|
| 216 | <td>When this flag is set, if the config finds anything unknown, then it will stop |
---|
| 217 | with a #error rather than continue. Boost regression testers should set this |
---|
| 218 | define, as should anyone who wants to quickly check whether boost is supported |
---|
| 219 | on their platform.</td> |
---|
| 220 | </tr> |
---|
| 221 | <tr> |
---|
| 222 | <td valign="top" width="48%">BOOST_DISABLE_THREADS</td> |
---|
| 223 | <td valign="top" width="52%">When defined, disables threading support, even if the |
---|
| 224 | compiler in its current translation mode supports multiple threads.</td> |
---|
| 225 | </tr> |
---|
| 226 | <tr> |
---|
| 227 | <td valign="top">BOOST_DISABLE_WIN32</td> |
---|
| 228 | <td>When defined, disables the use of Win32 specific API's, even when these are |
---|
| 229 | available. Also has the effect of setting BOOST_DISABLE_THREADS unless |
---|
| 230 | BOOST_HAS_PTHREADS is set. This option may be set automatically by the config |
---|
| 231 | system when it detects that the compiler is in "strict mode".</td> |
---|
| 232 | </tr> |
---|
| 233 | <TR> |
---|
| 234 | <TD vAlign="top">BOOST_DISABLE_ABI_HEADERS</TD> |
---|
| 235 | <TD>Stops boost headers from including any prefix/suffix headers that normally |
---|
| 236 | control things like struct packing and alignment.</TD> |
---|
| 237 | </TR> |
---|
| 238 | <TR> |
---|
| 239 | <TD vAlign="top">BOOST_ABI_PREFIX</TD> |
---|
| 240 | <TD>A prefix header to include in place of whatever boost.config would normally |
---|
| 241 | select, any replacement should set up struct packing and alignment options as |
---|
| 242 | required.</TD> |
---|
| 243 | </TR> |
---|
| 244 | <TR> |
---|
| 245 | <TD vAlign="top">BOOST_ABI_SUFFIX</TD> |
---|
| 246 | <TD>A suffix header to include in place of whatever boost.config would normally |
---|
| 247 | select, any replacement should undo the effects of the prefix header.</TD> |
---|
| 248 | </TR> |
---|
| 249 | <TR> |
---|
| 250 | <TD vAlign="top">BOOST_ALL_DYN_LINK</TD> |
---|
| 251 | <TD> |
---|
| 252 | <P>Forces all libraries that have separate source, to be linked as dll's rather |
---|
| 253 | than static libraries on Microsoft Windows (this macro is used to turn on |
---|
| 254 | __declspec(dllimport) modifiers, so that the compiler knows which symbols to |
---|
| 255 | look for in a dll rather than in a static library). |
---|
| 256 | </P> |
---|
| 257 | <P>Note that there may be some libraries that can only be statically linked |
---|
| 258 | (Boost.Test for example) and others which may only be dynamically linked |
---|
| 259 | (Boost.Threads for example), in these cases this macro has no effect.</P> |
---|
| 260 | </TD> |
---|
| 261 | </TR> |
---|
| 262 | <TR> |
---|
| 263 | <TD vAlign="top">BOOST_WHATEVER_DYN_LINK</TD> |
---|
| 264 | <TD> |
---|
| 265 | <P>Forces library "whatever" to be linked as a dll rather than a static library on |
---|
| 266 | Microsoft Windows: replace the WHATEVER part of the macro name with the name of |
---|
| 267 | the library that you want to dynamically link to, for example use |
---|
| 268 | BOOST_DATE_TIME_DYN_LINK or BOOST_REGEX_DYN_LINK etc (this macro is used |
---|
| 269 | to turn on __declspec(dllimport) modifiers, so that the compiler knows which |
---|
| 270 | symbols to look for in a dll rather than in a static library). |
---|
| 271 | </P> |
---|
| 272 | <P>Note that there may be some libraries that can only be statically linked |
---|
| 273 | (Boost.Test for example) and others which may only be dynamically linked |
---|
| 274 | (Boost.Threads for example), in these cases this macro is unsupported.</P> |
---|
| 275 | </TD> |
---|
| 276 | </TR> |
---|
| 277 | <TR> |
---|
| 278 | <TD vAlign="top">BOOST_ALL_NO_LIB</TD> |
---|
| 279 | <TD> |
---|
| 280 | <P>Tells the config system not to automatically select which libraries to link |
---|
| 281 | against. |
---|
| 282 | </P> |
---|
| 283 | <P>Normally if a compiler supports #pragma lib, then the correct library build |
---|
| 284 | variant will be automatically selected and linked against, simply by the act of |
---|
| 285 | including one of that library's headers. This macro turns that feature |
---|
| 286 | off.</P> |
---|
| 287 | </TD> |
---|
| 288 | </TR> |
---|
| 289 | <TR> |
---|
| 290 | <TD vAlign="top">BOOST_WHATEVER_NO_LIB</TD> |
---|
| 291 | <TD> |
---|
| 292 | <P>Tells the config system not to automatically select which library to link |
---|
| 293 | against for library "whatever", replace WHATEVER in the macro name with the |
---|
| 294 | name of the library; for example BOOST_DATE_TIME_NO_LIB or |
---|
| 295 | BOOST_REGEX_NO_LIB. |
---|
| 296 | </P> |
---|
| 297 | <P>Normally if a compiler supports #pragma lib, then the correct library build |
---|
| 298 | variant will be automatically selected and linked against, simply by the act of |
---|
| 299 | including one of that library's headers. This macro turns that feature |
---|
| 300 | off.</P> |
---|
| 301 | </TD> |
---|
| 302 | </TR> |
---|
| 303 | <TR> |
---|
| 304 | <TD vAlign="top">BOOST_LIB_DIAGNOSTIC</TD> |
---|
| 305 | <TD>Causes the auto-linking code to output diagnostic messages indicating the name |
---|
| 306 | of the library that is selected for linking.</TD> |
---|
| 307 | </TR> |
---|
| 308 | <TR> |
---|
| 309 | <TD vAlign="top">BOOST_LIB_TOOLSET</TD> |
---|
| 310 | <TD>Overrides the name of the toolset part of the name of library being linked to; |
---|
| 311 | note if defined this must be defined to a quoted string literal, for example |
---|
| 312 | "abc".</TD> |
---|
| 313 | </TR> |
---|
| 314 | </table> |
---|
| 315 | <h4><a name="advanced_config"></a>Advanced configuration usage</h4> |
---|
| 316 | <p>By setting various macros on the compiler command line or by editing <<a href="../../boost/config/user.hpp">boost/config/user.hpp</a>>, |
---|
| 317 | the boost configuration setup can be optimised in a variety of ways. |
---|
| 318 | </p> |
---|
| 319 | <p>Boost's configuration is structured so that the user-configuration is included |
---|
| 320 | first (defaulting to <<a href="../../boost/config/user.hpp">boost/config/user.hpp</a>> |
---|
| 321 | if BOOST_USER_CONFIG is not defined). This sets up any user-defined policies, |
---|
| 322 | and gives the user-configuration a chance to influence what happens next. |
---|
| 323 | </p> |
---|
| 324 | <p>Next the compiler, standard library, and platform configuration files are |
---|
| 325 | included. These are included via macros (BOOST_COMPILER_CONFIG etc, <a href="#user_settable"> |
---|
| 326 | see user settable macros</a>), and if the corresponding macro is undefined |
---|
| 327 | then a separate header that detects which compiler/standard library/platform is |
---|
| 328 | in use is included in order to set these. The config can be told to ignore |
---|
| 329 | these headers altogether if the corresponding BOOST_NO_XXX macro is set (for |
---|
| 330 | example BOOST_NO_COMPILER_CONFIG to disable including any compiler |
---|
| 331 | configuration file - <a href="#user_settable">see user settable macros</a>). |
---|
| 332 | </p> |
---|
| 333 | <p>Finally the boost configuration header, includes <<a href="../../boost/config/suffix.hpp">boost/config/suffix.hpp</a>>; |
---|
| 334 | this header contains any boiler plate configuration code - for example where |
---|
| 335 | one boost macro being set implies that another must be set also.</p> |
---|
| 336 | <p>The following usage examples represent just a few of the possibilities:</p> |
---|
| 337 | <p><u>Example 1, creating our own frozen configuration.</u></p> |
---|
| 338 | <p>Lets suppose that we're building boost with Visual C++ 6, and STLport 4.0. Lets |
---|
| 339 | suppose also that we don't intend to update our compiler or standard library |
---|
| 340 | any time soon. In order to avoid breaking dependencies when we update boost, we |
---|
| 341 | may want to "freeze" our configuration headers, so that we only have to rebuild |
---|
| 342 | our project if the boost code itself has changed, and not because the boost |
---|
| 343 | config has been updated for more recent versions of Visual C++ or STLport. |
---|
| 344 | We'll start by realising that the configuration files in use are: <<a href="../../boost/config/compiler/visualc.hpp">boost/config/compiler/visualc.hpp</a>> |
---|
| 345 | for the compiler, <<a href="../../boost/config/stdlib/stlport.hpp">boost/config/stdlib/stlport.hpp</a>> |
---|
| 346 | for the standard library, and <<a href="../../boost/config/platform/win32.hpp">boost/config/platform/win32.hpp</a>> |
---|
| 347 | for the platform. Next we'll create our own private configuration directory: |
---|
| 348 | boost/config/mysetup/, and copy the configuration files into there. Finally, |
---|
| 349 | open up <<a href="../../boost/config/user.hpp">boost/config/user.hpp</a>> |
---|
| 350 | and edit the following defines:</p> |
---|
| 351 | <pre>#define BOOST_COMPILER_CONFIG "boost/config/mysetup/visualc.hpp" |
---|
| 352 | #define BOOST_STDLIB_CONFIG "boost/config/mysetup/stlport.hpp" |
---|
| 353 | #define BOOST_USER_CONFIG "boost/config/mysetup/win32.hpp"</pre> |
---|
| 354 | <p>Now when you use boost, its configuration header will go straight to our |
---|
| 355 | "frozen" versions, and ignore the default versions, you will now be insulated |
---|
| 356 | from any configuration changes when you update boost. This technique is also |
---|
| 357 | useful if you want to modify some of the boost configuration files; for example |
---|
| 358 | if you are working with a beta compiler release not yet supported by boost.</p> |
---|
| 359 | <p><u>Example 2: skipping files that you don't need.</u></p> |
---|
| 360 | <p>Lets suppose that you're using boost with a compiler that is fully conformant |
---|
| 361 | with the standard; you're not interested in the fact that older versions of |
---|
| 362 | your compiler may have had bugs, because you know that your current version |
---|
| 363 | does not need any configuration macros setting. In a case like this, you can |
---|
| 364 | define BOOST_NO_COMPILER_CONFIG either on the command line, or in |
---|
| 365 | <boost/config/user.hpp>, and miss out the compiler configuration header |
---|
| 366 | altogether (actually you miss out two headers, one which works out what the |
---|
| 367 | compiler is, and one that configures boost for it). This has two consequences: |
---|
| 368 | the first is that less code has to be compiled, and the second that you have |
---|
| 369 | removed a dependency on two boost headers.</p> |
---|
| 370 | <p><u>Example 3: using configure script to freeze the boost configuration.</u></p> |
---|
| 371 | <p>If you are working on a unix-like platform then you can use the configure |
---|
| 372 | script to generate a "frozen" configuration based on your current compiler |
---|
| 373 | setup - <a href="#config_script">see using the configure script</a> for more |
---|
| 374 | details.</p> |
---|
| 375 | <h4><a name="testing"></a>Testing the boost configuration</h4> |
---|
| 376 | <p>The boost configuration library provides a full set of regression test programs |
---|
| 377 | under the <boost-root>/libs/config/test/ sub-directory:</p> |
---|
| 378 | <table border="1" cellpadding="7" cellspacing="1" width="100%"> |
---|
| 379 | <tr> |
---|
| 380 | <td valign="top" width="50%"><p align="center"><b>File</b></p> |
---|
| 381 | </td> |
---|
| 382 | <td valign="top" width="50%"><p align="center"><b>Description</b></p> |
---|
| 383 | </td> |
---|
| 384 | </tr> |
---|
| 385 | <tr> |
---|
| 386 | <td valign="top" width="50%">config_info.cpp</td> |
---|
| 387 | <td valign="top" width="50%">Prints out a detailed description of your |
---|
| 388 | compiler/standard library/platform setup, plus your current boost |
---|
| 389 | configuration. The information provided by this program useful in setting up |
---|
| 390 | the boost configuration files. If you report that boost is incorrectly |
---|
| 391 | configured for your compiler/library/platform then please include the output |
---|
| 392 | from this program when reporting the changes required.</td> |
---|
| 393 | </tr> |
---|
| 394 | <tr> |
---|
| 395 | <td valign="top" width="50%">config_test.cpp</td> |
---|
| 396 | <td valign="top" width="50%">A monolithic test program that includes most of the |
---|
| 397 | individual test cases. This provides a quick check to see if boost is correctly |
---|
| 398 | configured for your compiler/library/platform.</td> |
---|
| 399 | </tr> |
---|
| 400 | <tr> |
---|
| 401 | <td valign="top" width="50%">limits_test.cpp</td> |
---|
| 402 | <td valign="top" width="50%">Tests your standard library's std::numeric_limits |
---|
| 403 | implementation (or its boost provided replacement if BOOST_NO_LIMITS is |
---|
| 404 | defined). This test file fails with most versions of numeric_limits, mainly due |
---|
| 405 | to the way that some compilers treat NAN's and infinity.</td> |
---|
| 406 | </tr> |
---|
| 407 | <tr> |
---|
| 408 | <td valign="top" width="50%">no_*pass.cpp</td> |
---|
| 409 | <td valign="top" width="50%">Individual compiler defect test files. Each of these |
---|
| 410 | should compile, if one does not then the corresponding BOOST_NO_XXX macro needs |
---|
| 411 | to be defined - see each test file for specific details.</td> |
---|
| 412 | </tr> |
---|
| 413 | <tr> |
---|
| 414 | <td valign="top" width="50%">no_*fail.cpp</td> |
---|
| 415 | <td valign="top" width="50%">Individual compiler defect test files. Each of these |
---|
| 416 | should <i>not</i> compile, if one does then the corresponding BOOST_NO_XXX |
---|
| 417 | macro is defined when it need not be - see each test file for specific details.</td> |
---|
| 418 | </tr> |
---|
| 419 | <tr> |
---|
| 420 | <td valign="top" width="50%">has_*pass.cpp</td> |
---|
| 421 | <td valign="top" width="50%">Individual feature test files. If one of these does <i>not</i> |
---|
| 422 | compile then the corresponding BOOST_HAS_XXX macro is defined when it should |
---|
| 423 | not be - see each test file for specific details.</td> |
---|
| 424 | </tr> |
---|
| 425 | <tr> |
---|
| 426 | <td valign="top" width="50%">has_*fail.cpp</td> |
---|
| 427 | <td valign="top" width="50%">Individual feature test files. If one of these does |
---|
| 428 | compile then the corresponding BOOST_HAS_XXX macro can be safely defined - see |
---|
| 429 | each test file for specific details.</td> |
---|
| 430 | </tr> |
---|
| 431 | </table> |
---|
| 432 | <p>Although you can run the configuration regression tests as individual test |
---|
| 433 | files, there are rather a lot of them, so there are a couple of shortcuts to |
---|
| 434 | help you out:</p> |
---|
| 435 | <p>If you have built the <a href="../../more/regression.html">boost regression test |
---|
| 436 | driver</a>, then you can use this to produce a nice html formatted report of |
---|
| 437 | the results using the supplied test file.</p> |
---|
| 438 | <p>Alternatively you can run the configure script like this:</p> |
---|
| 439 | <pre>./configure --enable-test</pre> |
---|
| 440 | <p>in which case the script will test the current configuration rather than |
---|
| 441 | creating a new one from scratch.</p> |
---|
| 442 | <p>If you are reporting the results of these tests for a new |
---|
| 443 | platform/library/compiler then please include a log of the full compiler |
---|
| 444 | output, the output from config_info.cpp, and the pass/fail test results.</p> |
---|
| 445 | <h2><a name="macro_ref"></a>Boost Macro Reference</h2> |
---|
| 446 | <h4><a name="defects"></a>Macros that describe defects:</h4> |
---|
| 447 | <p>The following macros all describe features that are required by the C++ |
---|
| 448 | standard, if one of the following macros is defined, then it represents a |
---|
| 449 | defect in the compiler's conformance with the standard.</p> |
---|
| 450 | <table border="1" cellpadding="7" cellspacing="1" width="100%"> |
---|
| 451 | <tr> |
---|
| 452 | <td valign="top" width="51%"><p align="center"><b>Macro</b></p> |
---|
| 453 | </td> |
---|
| 454 | <td valign="top" width="16%"><p align="center"><b>Section</b></p> |
---|
| 455 | </td> |
---|
| 456 | <td valign="top" width="33%"><p align="center"><b>Description</b></p> |
---|
| 457 | </td> |
---|
| 458 | </tr> |
---|
| 459 | <tr> |
---|
| 460 | <td>BOOST_BCB_PARTIAL_SPECIALIZATION_BUG</td> |
---|
| 461 | <td>Compiler</td> |
---|
| 462 | <td>The compiler exibits certain partial specialisation bug - probably Borland C++ |
---|
| 463 | Builder specific.</td> |
---|
| 464 | </tr> |
---|
| 465 | <TR> |
---|
| 466 | <TD vAlign="top" width="51%">BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL</TD> |
---|
| 467 | <TD vAlign="top" width="16%">Compiler</TD> |
---|
| 468 | <TD vAlign="top" width="33%">Argument dependent lookup fails if there is a using |
---|
| 469 | declaration for the symbol being looked up in the current scope. For |
---|
| 470 | example, <code>using boost::get_pointer;</code> prevents ADL from finding |
---|
| 471 | overloads of <code>get_pointer</code> in namespaces nested inside boost (but |
---|
| 472 | not elsewhere). Probably Borland specific.</TD> |
---|
| 473 | </TR> |
---|
| 474 | <tr> |
---|
| 475 | <td valign="top" width="51%">BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP</td> |
---|
| 476 | <td valign="top" width="16%">Compiler</td> |
---|
| 477 | <td valign="top" width="33%">Compiler does not implement argument-dependent lookup |
---|
| 478 | (also named Koenig lookup); see std::3.4.2 [basic.koenig.lookup]</td> |
---|
| 479 | </tr> |
---|
| 480 | <tr> |
---|
| 481 | <td valign="top" width="51%">BOOST_NO_AUTO_PTR</td> |
---|
| 482 | <td valign="top" width="16%">Standard library</td> |
---|
| 483 | <td valign="top" width="33%">If the compiler / library supplies non-standard or |
---|
| 484 | broken std::auto_ptr.</td> |
---|
| 485 | </tr> |
---|
| 486 | <tr> |
---|
| 487 | <td valign="top" width="51%">BOOST_NO_CTYPE_FUNCTIONS</td> |
---|
| 488 | <td valign="top" width="16%">Platform</td> |
---|
| 489 | <td valign="top" width="33%">The Platform does not provide functions for the |
---|
| 490 | character-classifying operations <ctype.h> and <cctype>, only |
---|
| 491 | macros.</td> |
---|
| 492 | </tr> |
---|
| 493 | <tr> |
---|
| 494 | <td valign="top" width="51%">BOOST_NO_CV_SPECIALIZATIONS</td> |
---|
| 495 | <td valign="top" width="16%">Compiler</td> |
---|
| 496 | <td valign="top" width="33%">If template specialisations for cv-qualified types |
---|
| 497 | conflict with a specialisation for a cv-unqualififed type.</td> |
---|
| 498 | </tr> |
---|
| 499 | <tr> |
---|
| 500 | <td valign="top" width="51%">BOOST_NO_CV_VOID_SPECIALIZATIONS</td> |
---|
| 501 | <td valign="top" width="16%">Compiler</td> |
---|
| 502 | <td valign="top" width="33%">If template specialisations for cv-void types |
---|
| 503 | conflict with a specialisation for void.</td> |
---|
| 504 | </tr> |
---|
| 505 | <tr> |
---|
| 506 | <td valign="top" width="51%">BOOST_NO_CWCHAR</td> |
---|
| 507 | <td valign="top" width="16%">Platform</td> |
---|
| 508 | <td valign="top" width="33%">The Platform does not provide <wchar.h> and |
---|
| 509 | <cwchar>.</td> |
---|
| 510 | </tr> |
---|
| 511 | <tr> |
---|
| 512 | <td valign="top" width="51%">BOOST_NO_CWCTYPE</td> |
---|
| 513 | <td valign="top" width="16%">Platform</td> |
---|
| 514 | <td valign="top" width="33%">The Platform does not provide <wctype.h> and |
---|
| 515 | <cwctype>.</td> |
---|
| 516 | </tr> |
---|
| 517 | <tr> |
---|
| 518 | <td valign="top" width="51%">BOOST_NO_DEPENDENT_NESTED_DERIVATIONS</td> |
---|
| 519 | <td valign="top" width="16%">Compiler</td> |
---|
| 520 | <td valign="top" width="33%">The compiler fails to compile a nested class that has |
---|
| 521 | a dependent base class:<pre>template<typename T> |
---|
| 522 | struct foo : { |
---|
| 523 | template<typename U> |
---|
| 524 | struct bar : public U {}; |
---|
| 525 | };</pre> |
---|
| 526 | </td> |
---|
| 527 | </tr> |
---|
| 528 | <tr> |
---|
| 529 | <td valign="top" width="51%">BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS</td> |
---|
| 530 | <td valign="top" width="16%">Compiler</td> |
---|
| 531 | <td valign="top" width="33%">Template value parameters cannot have a dependent |
---|
| 532 | type, for example:<pre>template<class T, typename T::type value> |
---|
| 533 | class X { ... };</pre> |
---|
| 534 | </td> |
---|
| 535 | </tr> |
---|
| 536 | <tr> |
---|
| 537 | <td valign="top">BOOST_NO_EXCEPTION_STD_NAMESPACE</td> |
---|
| 538 | <td valign="top">Standard Library</td> |
---|
| 539 | <td>The standard library does not put some or all of the contents of |
---|
| 540 | <exception> in namespace std.</td> |
---|
| 541 | </tr> |
---|
| 542 | <tr> |
---|
| 543 | <td valign="top">BOOST_NO_EXCEPTIONS</td> |
---|
| 544 | <td valign="top">Compiler</td> |
---|
| 545 | <td>The compiler does not support exception handling (this setting is typically |
---|
| 546 | required by many C++ compilers for embedded platforms). Note that there is no |
---|
| 547 | requirement for boost libraries to honor this configuration setting - indeed |
---|
| 548 | doing so may be impossible in some cases. Those libraries that do honor this |
---|
| 549 | will typically abort if a critical error occurs - you have been warned!</td> |
---|
| 550 | </tr> |
---|
| 551 | <tr> |
---|
| 552 | <td valign="top" width="51%">BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS</td> |
---|
| 553 | <td valign="top" width="16%">Compiler</td> |
---|
| 554 | <td valign="top" width="33%">Can only use deduced template arguments when calling |
---|
| 555 | function template instantiations.</td> |
---|
| 556 | </tr> |
---|
| 557 | <tr> |
---|
| 558 | <td valign="top" width="51%">BOOST_NO_FUNCTION_TEMPLATE_ORDERING</td> |
---|
| 559 | <td valign="top" width="16%">Compiler</td> |
---|
| 560 | <td valign="top" width="33%">The compiler does not perform function template |
---|
| 561 | ordering or its function template ordering is incorrect. |
---|
| 562 | <pre>template<typename T> void f(T); // #1 |
---|
| 563 | template<typename T, typename U> void f(T (*)(U)); // #2 |
---|
| 564 | |
---|
| 565 | void bar(int); |
---|
| 566 | |
---|
| 567 | f(&bar); // should choose #2.</pre> |
---|
| 568 | </td> |
---|
| 569 | </tr> |
---|
| 570 | <tr> |
---|
| 571 | <td valign="top" width="51%">BOOST_NO_INCLASS_MEMBER_INITIALIZATION</td> |
---|
| 572 | <td valign="top" width="16%">Compiler</td> |
---|
| 573 | <td valign="top" width="33%">Compiler violates std::9.4.2/4.</td> |
---|
| 574 | </tr> |
---|
| 575 | <tr> |
---|
| 576 | <td valign="top" width="51%">BOOST_NO_INTRINSIC_WCHAR_T</td> |
---|
| 577 | <td valign="top" width="16%">Compiler</td> |
---|
| 578 | <td valign="top" width="33%">The C++ implementation does not provide wchar_t, or |
---|
| 579 | it is really a synonym for another integral type. Use this symbol to decide |
---|
| 580 | whether it is appropriate to explicitly specialize a template on wchar_t if |
---|
| 581 | there is already a specialization for other integer types.</td> |
---|
| 582 | </tr> |
---|
| 583 | <TR> |
---|
| 584 | <TD vAlign="top" width="51%">BOOST_NO_IS_ABSTRACT</TD> |
---|
| 585 | <TD vAlign="top" width="16%">Compiler</TD> |
---|
| 586 | <TD vAlign="top" width="33%">The C++ compiler does not support SFINAE with |
---|
| 587 | abstract types, this is covered by <A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#337"> |
---|
| 588 | Core Language DR337</A>, but is not part of the current standard. |
---|
| 589 | Fortunately most compilers that support SFINAE also support this DR.</TD> |
---|
| 590 | </TR> |
---|
| 591 | <tr> |
---|
| 592 | <td valign="top" width="51%">BOOST_NO_LIMITS</td> |
---|
| 593 | <td valign="top" width="16%">Standard library</td> |
---|
| 594 | <td valign="top" width="33%">The C++ implementation does not provide the |
---|
| 595 | <limits> header. Never check for this symbol in library code; always |
---|
| 596 | include <boost/limits.hpp>, which guarantees to provide <code>std::numeric_limits</code>.</td> |
---|
| 597 | </tr> |
---|
| 598 | <tr> |
---|
| 599 | <td valign="top" width="51%">BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS</td> |
---|
| 600 | <td valign="top" width="16%">Standard library</td> |
---|
| 601 | <td valign="top" width="33%">Constants such as numeric_limits<T>::is_signed |
---|
| 602 | are not available for use at compile-time.</td> |
---|
| 603 | </tr> |
---|
| 604 | <tr> |
---|
| 605 | <td>BOOST_NO_LONG_LONG_NUMERIC_LIMITS</td> |
---|
| 606 | <td>Standard library</td> |
---|
| 607 | <td>There is no specialization for numeric_limits<long long> and |
---|
| 608 | numeric_limits<unsigned long long>. <boost/limits.hpp> will then |
---|
| 609 | add these specializations as a standard library "fix" only if the compiler |
---|
| 610 | supports the long long datatype.</td> |
---|
| 611 | </tr> |
---|
| 612 | <tr> |
---|
| 613 | <td>BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS</td> |
---|
| 614 | <td>Compiler</td> |
---|
| 615 | <td>The compiler does not support the specialization of individual member |
---|
| 616 | functions of template classes.</td> |
---|
| 617 | </tr> |
---|
| 618 | <tr> |
---|
| 619 | <td valign="top" width="51%">BOOST_NO_MEMBER_TEMPLATE_KEYWORD</td> |
---|
| 620 | <td valign="top" width="16%">Compiler</td> |
---|
| 621 | <td valign="top" width="33%">If the compiler supports member templates, but not |
---|
| 622 | the template keyword when accessing member template classes.</td> |
---|
| 623 | </tr> |
---|
| 624 | <tr> |
---|
| 625 | <td valign="top" width="51%">BOOST_NO_MEMBER_TEMPLATE_FRIENDS</td> |
---|
| 626 | <td valign="top" width="16%">Compiler</td> |
---|
| 627 | <td valign="top" width="33%">Member template friend syntax ("template<class |
---|
| 628 | P> friend class frd;") described in the C++ Standard, 14.5.3, not supported.</td> |
---|
| 629 | </tr> |
---|
| 630 | <tr> |
---|
| 631 | <td valign="top" width="51%">BOOST_NO_MEMBER_TEMPLATES</td> |
---|
| 632 | <td valign="top" width="16%">Compiler</td> |
---|
| 633 | <td valign="top" width="33%">Member template functions not fully supported.</td> |
---|
| 634 | </tr> |
---|
| 635 | <tr> |
---|
| 636 | <td>BOOST_NO_MS_INT64_NUMERIC_LIMITS</td> |
---|
| 637 | <td>Standard library</td> |
---|
| 638 | <td>There is no specialization for numeric_limits<__int64> and |
---|
| 639 | numeric_limits<unsigned __int64>. <boost/limits.hpp> will then add |
---|
| 640 | these specializations as a standard library "fix", only if the compiler |
---|
| 641 | supports the __int64 datatype.</td> |
---|
| 642 | </tr> |
---|
| 643 | <tr> |
---|
| 644 | <td valign="top" width="51%">BOOST_NO_OPERATORS_IN_NAMESPACE</td> |
---|
| 645 | <td valign="top" width="16%">Compiler</td> |
---|
| 646 | <td valign="top" width="33%">Compiler requires inherited operator friend functions |
---|
| 647 | to be defined at namespace scope, then using'ed to boost. Probably GCC |
---|
| 648 | specific. See <a href="../../boost/operators.hpp">boost/operators.hpp</a> for |
---|
| 649 | example.</td> |
---|
| 650 | </tr> |
---|
| 651 | <tr> |
---|
| 652 | <td valign="top" width="51%">BOOST_NO_POINTER_TO_MEMBER_CONST</td> |
---|
| 653 | <td valign="top" width="16%">Compiler</td> |
---|
| 654 | <td valign="top" width="33%">The compiler does not correctly handle pointers to |
---|
| 655 | const member functions, preventing use of these in overloaded function |
---|
| 656 | templates. See <a href="../../boost/functional.hpp">boost/functional.hpp</a> for |
---|
| 657 | example.</td> |
---|
| 658 | </tr> |
---|
| 659 | <TR> |
---|
| 660 | <TD vAlign="top" width="51%">BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS</TD> |
---|
| 661 | <TD vAlign="top" width="16%">Compiler</TD> |
---|
| 662 | <TD vAlign="top" width="33%">Pointers to members don't work when used as template |
---|
| 663 | parameters.</TD> |
---|
| 664 | </TR> |
---|
| 665 | <tr> |
---|
| 666 | <td valign="top" width="51%">BOOST_NO_PRIVATE_IN_AGGREGATE</td> |
---|
| 667 | <td valign="top" width="16%">Compiler</td> |
---|
| 668 | <td valign="top" width="33%">The compiler misreads 8.5.1, treating classes as |
---|
| 669 | non-aggregate if they contain private or protected member functions.</td> |
---|
| 670 | </tr> |
---|
| 671 | <TR> |
---|
| 672 | <TD vAlign="top" width="51%">BOOST_NO_SFINAE</TD> |
---|
| 673 | <TD vAlign="top" width="16%">Compiler</TD> |
---|
| 674 | <TD vAlign="top" width="33%">The compiler does not support the "Substitution |
---|
| 675 | Failure Is Not An Error" meta-programming idiom.</TD> |
---|
| 676 | </TR> |
---|
| 677 | <tr> |
---|
| 678 | <td valign="top" width="51%">BOOST_NO_STD_ALLOCATOR</td> |
---|
| 679 | <td valign="top" width="16%">Standard library</td> |
---|
| 680 | <td valign="top" width="33%">The C++ standard library does not provide a standards |
---|
| 681 | conforming std::allocator.</td> |
---|
| 682 | </tr> |
---|
| 683 | <tr> |
---|
| 684 | <td valign="top" width="51%">BOOST_NO_STD_DISTANCE</td> |
---|
| 685 | <td valign="top" width="16%">Standard library</td> |
---|
| 686 | <td valign="top" width="33%">The platform does not have a conforming version of |
---|
| 687 | std::distance.</td> |
---|
| 688 | </tr> |
---|
| 689 | <tr> |
---|
| 690 | <td valign="top" width="51%">BOOST_NO_STD_ITERATOR</td> |
---|
| 691 | <td valign="top" width="16%">Standard library</td> |
---|
| 692 | <td valign="top" width="33%">The C++ implementation fails to provide the |
---|
| 693 | std::iterator class.</td> |
---|
| 694 | </tr> |
---|
| 695 | <tr> |
---|
| 696 | <td valign="top" width="51%">BOOST_NO_STD_ITERATOR_TRAITS</td> |
---|
| 697 | <td valign="top" width="16%">Standard library</td> |
---|
| 698 | <td valign="top" width="33%">The compiler does not provide a standard compliant |
---|
| 699 | implementation of std::iterator_traits. Note that the compiler may still have a |
---|
| 700 | non-standard implementation.</td> |
---|
| 701 | </tr> |
---|
| 702 | <tr> |
---|
| 703 | <td valign="top" width="51%">BOOST_NO_STD_LOCALE</td> |
---|
| 704 | <td valign="top" width="16%">Standard library</td> |
---|
| 705 | <td valign="top" width="33%">The standard library lacks std::locale.</td> |
---|
| 706 | </tr> |
---|
| 707 | <tr> |
---|
| 708 | <td valign="top" width="51%">BOOST_NO_STD_MESSAGES</td> |
---|
| 709 | <td valign="top" width="16%">Standard library</td> |
---|
| 710 | <td valign="top" width="33%">The standard library lacks a conforming std::messages |
---|
| 711 | facet.</td> |
---|
| 712 | </tr> |
---|
| 713 | <tr> |
---|
| 714 | <td valign="top" width="51%">BOOST_NO_STD_MIN_MAX</td> |
---|
| 715 | <td valign="top" width="16%">Standard library</td> |
---|
| 716 | <td valign="top" width="33%">The C++ standard library does not provide the min() |
---|
| 717 | and max() template functions that should be in <algorithm>.</td> |
---|
| 718 | </tr> |
---|
| 719 | <tr> |
---|
| 720 | <td valign="top">BOOST_NO_STD_OUTPUT_ITERATOR_ASSIGN</td> |
---|
| 721 | <td valign="top">Standard library</td> |
---|
| 722 | <td valign="top">Defined if the standard library's output iterators are not |
---|
| 723 | assignable.</td> |
---|
| 724 | </tr> |
---|
| 725 | <tr> |
---|
| 726 | <td valign="top" width="51%">BOOST_NO_STD_USE_FACET</td> |
---|
| 727 | <td valign="top" width="16%">Standard library</td> |
---|
| 728 | <td valign="top" width="33%">The standard library lacks a conforming |
---|
| 729 | std::use_facet.</td> |
---|
| 730 | </tr> |
---|
| 731 | <tr> |
---|
| 732 | <td>BOOST_NO_STD_WSTREAMBUF</td> |
---|
| 733 | <td>Standard library</td> |
---|
| 734 | <td>The standard library's implementation of std::basic_streambuf<wchar_t> |
---|
| 735 | is either missing, incomplete, or buggy.</td> |
---|
| 736 | </tr> |
---|
| 737 | <tr> |
---|
| 738 | <td valign="top" width="51%">BOOST_NO_STD_WSTRING</td> |
---|
| 739 | <td valign="top" width="16%">Standard library</td> |
---|
| 740 | <td valign="top" width="33%">The standard library lacks std::wstring.</td> |
---|
| 741 | </tr> |
---|
| 742 | <tr> |
---|
| 743 | <td valign="top" width="51%">BOOST_NO_STDC_NAMESPACE</td> |
---|
| 744 | <td valign="top" width="16%">Compiler/Platform</td> |
---|
| 745 | <td valign="top" width="33%">The contents of C++ standard headers for C library |
---|
| 746 | functions (the <c...> headers) have not been placed in namespace std. |
---|
| 747 | This test is difficult - some libraries "fake" the std C functions by adding |
---|
| 748 | using declarations to import them into namespace std, unfortunately they don't |
---|
| 749 | necessarily catch all of them...</td> |
---|
| 750 | </tr> |
---|
| 751 | <tr> |
---|
| 752 | <td valign="top" width="51%">BOOST_NO_STRINGSTREAM</td> |
---|
| 753 | <td valign="top" width="16%">Standard library</td> |
---|
| 754 | <td valign="top" width="33%">The C++ implementation does not provide the |
---|
| 755 | <sstream> header.</td> |
---|
| 756 | </tr> |
---|
| 757 | <tr> |
---|
| 758 | <td valign="top" width="51%">BOOST_NO_SWPRINTF</td> |
---|
| 759 | <td valign="top" width="16%">Platform</td> |
---|
| 760 | <td valign="top" width="33%">The platform does not have a conforming version of |
---|
| 761 | swprintf.</td> |
---|
| 762 | </tr> |
---|
| 763 | <tr> |
---|
| 764 | <td valign="top" width="51%">BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION</td> |
---|
| 765 | <td valign="top" width="16%">Compiler</td> |
---|
| 766 | <td valign="top" width="33%">Class template partial specialization (14.5.4 |
---|
| 767 | [temp.class.spec]) not supported.</td> |
---|
| 768 | </tr> |
---|
| 769 | <tr> |
---|
| 770 | <td valign="top" width="51%">BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS</td> |
---|
| 771 | <td valign="top" width="16%">Standard library</td> |
---|
| 772 | <td valign="top" width="33%">The standard library does not provide templated |
---|
| 773 | iterator constructors for its containers.</td> |
---|
| 774 | </tr> |
---|
| 775 | <tr> |
---|
| 776 | <td>BOOST_NO_TEMPLATE_TEMPLATES</td> |
---|
| 777 | <td>Compiler</td> |
---|
| 778 | <td>The compiler does not support template template parameters.</td> |
---|
| 779 | </tr> |
---|
| 780 | <tr> |
---|
| 781 | <td>BOOST_NO_UNREACHABLE_RETURN_DETECTION</td> |
---|
| 782 | <td>Compiler</td> |
---|
| 783 | <td>If a return is unreachable, then no return statement should be required, |
---|
| 784 | however some compilers insist on it, while other issue a bunch of warnings if |
---|
| 785 | it is in fact present.</td> |
---|
| 786 | </tr> |
---|
| 787 | <TR> |
---|
| 788 | <TD vAlign="top" width="51%">BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE</TD> |
---|
| 789 | <TD vAlign="top" width="16%">Compiler</TD> |
---|
| 790 | <TD vAlign="top" width="33%">The compiler will not accept a using |
---|
| 791 | declaration that brings a function from a typename used as a base |
---|
| 792 | class into a derived class if functions of the same name are present |
---|
| 793 | in the derived class.</TD> |
---|
| 794 | </TR> |
---|
| 795 | <tr> |
---|
| 796 | <td valign="top" width="51%">BOOST_NO_USING_TEMPLATE</td> |
---|
| 797 | <td valign="top" width="16%">Compiler</td> |
---|
| 798 | <td valign="top" width="33%">The compiler will not accept a using declaration that |
---|
| 799 | imports a template class or function from another namespace. Originally a |
---|
| 800 | Borland specific problem with imports to/from the global namespace, extended to |
---|
| 801 | MSVC6 which has a specific issue with importing template classes (but not |
---|
| 802 | functions).</td> |
---|
| 803 | </tr> |
---|
| 804 | <tr> |
---|
| 805 | <td valign="top" width="51%">BOOST_NO_VOID_RETURNS</td> |
---|
| 806 | <td valign="top" width="16%">Compiler</td> |
---|
| 807 | <td valign="top" width="33%">The compiler does not allow a void function to return |
---|
| 808 | the result of calling another void function. |
---|
| 809 | <pre>void f() {} |
---|
| 810 | void g() { return f(); }</pre> |
---|
| 811 | </td> |
---|
| 812 | </tr> |
---|
| 813 | </table> |
---|
| 814 | <h4><a name="features"></a>Macros that describe optional features:</h4> |
---|
| 815 | <p>The following macros describe features that are not required by the C++ |
---|
| 816 | standard. The macro is only defined if the feature is present.</p> |
---|
| 817 | <table border="1" cellpadding="7" cellspacing="1" width="100%"> |
---|
| 818 | <tr> |
---|
| 819 | <td valign="top" width="48%"><p align="center"><b>Macro</b></p> |
---|
| 820 | </td> |
---|
| 821 | <td valign="top" width="15%"><p align="center"><b>Section</b></p> |
---|
| 822 | </td> |
---|
| 823 | <td valign="top" width="37%"><p align="center"><b>Description</b></p> |
---|
| 824 | </td> |
---|
| 825 | </tr> |
---|
| 826 | <tr> |
---|
| 827 | <td valign="top" width="48%">BOOST_HAS_BETHREADS</td> |
---|
| 828 | <td valign="top" width="15%">Platform</td> |
---|
| 829 | <td valign="top" width="37%">The platform supports BeOS style threads.</td> |
---|
| 830 | </tr> |
---|
| 831 | <tr> |
---|
| 832 | <td>BOOST_HAS_CLOCK_GETTIME</td> |
---|
| 833 | <td>Platform</td> |
---|
| 834 | <td>The platform has the POSIX API clock_gettime.</td> |
---|
| 835 | </tr> |
---|
| 836 | <TR> |
---|
| 837 | <TD>BOOST_HAS_DECLSPEC |
---|
| 838 | </TD> |
---|
| 839 | <TD>Compiler</TD> |
---|
| 840 | <TD>The compiler uses __declspec(dllexport) and __declspec(dllimport) to |
---|
| 841 | export/import symbols from dll's.</TD> |
---|
| 842 | </TR> |
---|
| 843 | <tr> |
---|
| 844 | <td>BOOST_HAS_DIRENT_H</td> |
---|
| 845 | <td>Platform</td> |
---|
| 846 | <td>The platform has the POSIX header <dirent.h>.</td> |
---|
| 847 | </tr> |
---|
| 848 | <tr> |
---|
| 849 | <td>BOOST_HAS_FTIME</td> |
---|
| 850 | <td>Platform</td> |
---|
| 851 | <td>The platform has the Win32 API GetSystemTimeAsFileTime.</td> |
---|
| 852 | </tr> |
---|
| 853 | <tr> |
---|
| 854 | <td>BOOST_HAS_GETTIMEOFDAY</td> |
---|
| 855 | <td>Platform</td> |
---|
| 856 | <td>The platform has the POSIX API gettimeofday.</td> |
---|
| 857 | </tr> |
---|
| 858 | <tr> |
---|
| 859 | <td valign="top" width="48%">BOOST_HAS_HASH</td> |
---|
| 860 | <td valign="top" width="15%">Standard library</td> |
---|
| 861 | <td valign="top" width="37%">The C++ implementation provides the (SGI) hash_set or |
---|
| 862 | hash_map classes.</td> |
---|
| 863 | </tr> |
---|
| 864 | <tr> |
---|
| 865 | <td>BOOST_HAS_LONG_LONG</td> |
---|
| 866 | <td>Compiler</td> |
---|
| 867 | <td>The compiler supports the long long data type.</td> |
---|
| 868 | </tr> |
---|
| 869 | <tr> |
---|
| 870 | <td valign="top" width="48%">BOOST_HAS_MACRO_USE_FACET</td> |
---|
| 871 | <td valign="top" width="15%">Standard library</td> |
---|
| 872 | <td valign="top" width="37%">The standard library lacks a conforming |
---|
| 873 | std::use_facet, but has a macro _USE(loc, Type) that does the job. This is |
---|
| 874 | primarily for the Dinkumware std lib.</td> |
---|
| 875 | </tr> |
---|
| 876 | <tr> |
---|
| 877 | <td>BOOST_HAS_MS_INT64</td> |
---|
| 878 | <td>Compiler</td> |
---|
| 879 | <td>The compiler supports the __int64 data type.</td> |
---|
| 880 | </tr> |
---|
| 881 | <tr> |
---|
| 882 | <td>BOOST_HAS_NANOSLEEP</td> |
---|
| 883 | <td>Platform</td> |
---|
| 884 | <td>The platform has the POSIX API nanosleep.</td> |
---|
| 885 | </tr> |
---|
| 886 | <tr> |
---|
| 887 | <td valign="top" width="48%">BOOST_HAS_NL_TYPES_H</td> |
---|
| 888 | <td valign="top" width="15%">Platform</td> |
---|
| 889 | <td valign="top" width="37%">The platform has an <nl_types.h>.</td> |
---|
| 890 | </tr> |
---|
| 891 | <tr> |
---|
| 892 | <td>BOOST_HAS_NRVO</td> |
---|
| 893 | <td>Compiler</td> |
---|
| 894 | <td>Indicated that the compiler supports the named return value optimization |
---|
| 895 | (NRVO). Used to select the most efficient implementation for some function. See <a href="../../boost/operators.hpp"> |
---|
| 896 | boost/operators.hpp</a> for example.</td> |
---|
| 897 | </tr> |
---|
| 898 | <tr> |
---|
| 899 | <td valign="top">BOOST_HAS_PARTIAL_STD_ALLOCATOR</td> |
---|
| 900 | <td>Standard Library</td> |
---|
| 901 | <td>The standard library has a partially conforming std::allocator class, but |
---|
| 902 | without any of the member templates.</td> |
---|
| 903 | </tr> |
---|
| 904 | <tr> |
---|
| 905 | <td>BOOST_HAS_PTHREAD_DELAY_NP</td> |
---|
| 906 | <td>Platform</td> |
---|
| 907 | <td>The platform has the POSIX API pthread_delay_np.</td> |
---|
| 908 | </tr> |
---|
| 909 | <tr> |
---|
| 910 | <td>BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE</td> |
---|
| 911 | <td>Platform</td> |
---|
| 912 | <td>The platform has the POSIX API pthread_mutexattr_settype.</td> |
---|
| 913 | </tr> |
---|
| 914 | <tr> |
---|
| 915 | <td>BOOST_HAS_PTHREAD_YIELD</td> |
---|
| 916 | <td>Platform</td> |
---|
| 917 | <td>The platform has the POSIX API pthread_yield.</td> |
---|
| 918 | </tr> |
---|
| 919 | <tr> |
---|
| 920 | <td valign="top" width="48%">BOOST_HAS_PTHREADS</td> |
---|
| 921 | <td valign="top" width="15%">Platform</td> |
---|
| 922 | <td valign="top" width="37%">The platform support POSIX style threads.</td> |
---|
| 923 | </tr> |
---|
| 924 | <tr> |
---|
| 925 | <td>BOOST_HAS_SCHED_YIELD</td> |
---|
| 926 | <td>Platform</td> |
---|
| 927 | <td>The platform has the POSIX API sched_yield.</td> |
---|
| 928 | </tr> |
---|
| 929 | <tr> |
---|
| 930 | <td>BOOST_HAS_SGI_TYPE_TRAITS</td> |
---|
| 931 | <td>Compiler/standard library</td> |
---|
| 932 | <td>The compiler has native support for SGI style type traits.</td> |
---|
| 933 | </tr> |
---|
| 934 | <tr> |
---|
| 935 | <td>BOOST_HAS_STDINT_H</td> |
---|
| 936 | <td>Platform</td> |
---|
| 937 | <td>The platform has a <stdint.h></td> |
---|
| 938 | </tr> |
---|
| 939 | <tr> |
---|
| 940 | <td valign="top" width="48%">BOOST_HAS_SLIST</td> |
---|
| 941 | <td valign="top" width="15%">Standard library</td> |
---|
| 942 | <td valign="top" width="37%">The C++ implementation provides the (SGI) slist |
---|
| 943 | class.</td> |
---|
| 944 | </tr> |
---|
| 945 | <tr> |
---|
| 946 | <td valign="top" width="48%">BOOST_HAS_STLP_USE_FACET</td> |
---|
| 947 | <td valign="top" width="15%">Standard library</td> |
---|
| 948 | <td valign="top" width="37%">The standard library lacks a conforming |
---|
| 949 | std::use_facet, but has a workaround class-version that does the job. This is |
---|
| 950 | primarily for the STLport std lib.</td> |
---|
| 951 | </tr> |
---|
| 952 | <tr> |
---|
| 953 | <td valign="top" width="48%">BOOST_HAS_THREADS</td> |
---|
| 954 | <td valign="top" width="15%">Platform/compiler</td> |
---|
| 955 | <td valign="top" width="37%">Defined if the compiler, in its current translation |
---|
| 956 | mode, supports multiple threads of execution.</td> |
---|
| 957 | </tr> |
---|
| 958 | <tr> |
---|
| 959 | <td valign="top" width="48%">BOOST_HAS_TWO_ARG_USE_FACET</td> |
---|
| 960 | <td valign="top" width="15%">Standard library</td> |
---|
| 961 | <td valign="top" width="37%">The standard library lacks a conforming |
---|
| 962 | std::use_facet, but has a two argument version that does the job. This is |
---|
| 963 | primarily for the Rogue Wave std lib.</td> |
---|
| 964 | </tr> |
---|
| 965 | <tr> |
---|
| 966 | <td valign="top" width="48%">BOOST_HAS_UNISTD_H</td> |
---|
| 967 | <td valign="top" width="15%">Platform</td> |
---|
| 968 | <td valign="top" width="37%">The Platform provides <unistd.h>.</td> |
---|
| 969 | </tr> |
---|
| 970 | <tr> |
---|
| 971 | <td valign="top" width="48%">BOOST_HAS_WINTHREADS</td> |
---|
| 972 | <td valign="top" width="15%">Platform</td> |
---|
| 973 | <td valign="top" width="37%">The platform supports MS Windows style threads.</td> |
---|
| 974 | </tr> |
---|
| 975 | <tr> |
---|
| 976 | <td valign="top" width="48%">BOOST_MSVC_STD_ITERATOR</td> |
---|
| 977 | <td valign="top" width="15%">Standard library</td> |
---|
| 978 | <td valign="top" width="37%">Microsoft's broken version of std::iterator is being |
---|
| 979 | used. This implies that std::iterator takes no more than two template |
---|
| 980 | parameters.</td> |
---|
| 981 | </tr> |
---|
| 982 | <tr> |
---|
| 983 | <td valign="top" width="48%">BOOST_MSVC6_MEMBER_TEMPLATES</td> |
---|
| 984 | <td valign="top" width="15%">Compiler</td> |
---|
| 985 | <td valign="top" width="37%">Microsoft Visual C++ 6.0 has enough member template |
---|
| 986 | idiosyncrasies (being polite) that BOOST_NO_MEMBER_TEMPLATES is defined for |
---|
| 987 | this compiler. BOOST_MSVC6_MEMBER_TEMPLATES is defined to allow compiler |
---|
| 988 | specific workarounds. This macro gets defined automatically if |
---|
| 989 | BOOST_NO_MEMBER_TEMPLATES is not defined - in other words this is treated as a |
---|
| 990 | strict subset of the features required by the standard.</td> |
---|
| 991 | </tr> |
---|
| 992 | <tr> |
---|
| 993 | <td valign="top" width="48%">BOOST_HAS_STDINT_H</td> |
---|
| 994 | <td valign="top" width="15%">Platform</td> |
---|
| 995 | <td valign="top" width="37%">There are no 1998 C++ Standard headers |
---|
| 996 | <stdint.h> or <cstdint>, although the 1999 C Standard does include |
---|
| 997 | <stdint.h>. If <stdint.h> is present, <boost/stdint.h> can |
---|
| 998 | make good use of it, so a flag is supplied (signalling presence; thus the |
---|
| 999 | default is not present, conforming to the current C++ standard).</td> |
---|
| 1000 | </tr> |
---|
| 1001 | </table> |
---|
| 1002 | <h4><a name="helpers"></a>Boost Helper Macros</h4> |
---|
| 1003 | <p>The following macros are either simple helpers, or macros that provide |
---|
| 1004 | workarounds for compiler/standard library defects.</p> |
---|
| 1005 | <table border="1" cellpadding="7" cellspacing="1" width="100%"> |
---|
| 1006 | <tr> |
---|
| 1007 | <td valign="top" width="50%"><p align="center"><b>Macro</b></p> |
---|
| 1008 | </td> |
---|
| 1009 | <td valign="top" width="50%"><p align="center"><b>Description</b></p> |
---|
| 1010 | </td> |
---|
| 1011 | </tr> |
---|
| 1012 | <tr> |
---|
| 1013 | <td valign="top" width="50%">BOOST_DEDUCED_TYPENAME</td> |
---|
| 1014 | <td valign="top" width="50%">Some compilers don't support the use of <code>typename</code> |
---|
| 1015 | for dependent types in deduced contexts. This macro expands to nothing on those |
---|
| 1016 | compilers, and <code>typename</code> elsewhere. For example, replace:<pre>template <class T> void f(T, typename T::type);</pre> |
---|
| 1017 | <p>with:</p> |
---|
| 1018 | <pre>template <class T> void f(T, BOOST_DEDUCED_TYPENAME T::type);</pre> |
---|
| 1019 | </td> |
---|
| 1020 | </tr> |
---|
| 1021 | <tr> |
---|
| 1022 | <td>BOOST_STD_EXTENSION_NAMESPACE</td> |
---|
| 1023 | <td>The namespace used for std library extensions (hashtable classes etc).</td> |
---|
| 1024 | </tr> |
---|
| 1025 | <tr> |
---|
| 1026 | <td valign="top" width="50%">BOOST_STATIC_CONSTANT(Type, assignment)</td> |
---|
| 1027 | <td valign="top" width="50%">On compilers which don't allow in-class |
---|
| 1028 | initialization of static integral constant members, we must use enums as a |
---|
| 1029 | workaround if we want the constants to be available at compile-time. This macro |
---|
| 1030 | gives us a convenient way to declare such constants. For example instead of:<pre>struct foo{ |
---|
| 1031 | static const int value = 2; |
---|
| 1032 | };</pre> |
---|
| 1033 | <p>use:</p> |
---|
| 1034 | <pre>struct foo{ |
---|
| 1035 | BOOST_STATIC_CONSTANT(int, value = 2); |
---|
| 1036 | };</pre> |
---|
| 1037 | </td> |
---|
| 1038 | </tr> |
---|
| 1039 | <tr> |
---|
| 1040 | <td>BOOST_UNREACHABLE_RETURN(result)</td> |
---|
| 1041 | <td>Normally evaluates to nothing, but evaluates to <font face="Courier New">return |
---|
| 1042 | x;</font> if the compiler requires a return, even when it can never be |
---|
| 1043 | reached.</td> |
---|
| 1044 | </tr> |
---|
| 1045 | <tr> |
---|
| 1046 | <td>BOOST_EXPLICIT_TEMPLATE_TYPE(t)<br> |
---|
| 1047 | BOOST_EXPLICIT_TEMPLATE_NON_TYPE(t, v)<br> |
---|
| 1048 | BOOST_APPEND_EXPLICIT_TEMPLATE_TYPE(t)<br> |
---|
| 1049 | BOOST_APPEND_EXPLICIT_TEMPLATE_NON_TYPE(t, v)<br> |
---|
| 1050 | </td> |
---|
| 1051 | <td>Some compilers silently "fold" different function template instantiations if |
---|
| 1052 | some of the template parameters don't appear in the function parameter list. |
---|
| 1053 | For instance: |
---|
| 1054 | <pre> #include <iostream> |
---|
| 1055 | #include <ostream> |
---|
| 1056 | #include <typeinfo> |
---|
| 1057 | |
---|
| 1058 | template <int n> |
---|
| 1059 | void f() { std::cout << n << ' '; } |
---|
| 1060 | |
---|
| 1061 | template <typename T> |
---|
| 1062 | void g() { std::cout << typeid(T).name() << ' '; } |
---|
| 1063 | |
---|
| 1064 | int main() { |
---|
| 1065 | f<1>(); |
---|
| 1066 | f<2>(); |
---|
| 1067 | |
---|
| 1068 | g<int>(); |
---|
| 1069 | g<double>(); |
---|
| 1070 | } |
---|
| 1071 | </pre> |
---|
| 1072 | incorrectly outputs <tt>"2 2 double double "</tt> on VC++ 6. These macros, to |
---|
| 1073 | be used in the function parameter list, fix the problem without effects on the |
---|
| 1074 | calling syntax. For instance, in the case above write: |
---|
| 1075 | <pre> template <int n> |
---|
| 1076 | void f(BOOST_EXPLICIT_TEMPLATE_NON_TYPE(int, n)) { ... } |
---|
| 1077 | |
---|
| 1078 | template <typename T> |
---|
| 1079 | void g(BOOST_EXPLICIT_TEMPLATE_TYPE(T)) { ... } |
---|
| 1080 | </pre> |
---|
| 1081 | Beware that they can declare (for affected compilers) a dummy <i>defaulted</i> parameter, |
---|
| 1082 | so they |
---|
| 1083 | <br> |
---|
| 1084 | <br> |
---|
| 1085 | a) should be always invoked *at the end* of the parameter list |
---|
| 1086 | <br> |
---|
| 1087 | b) can't be used if your function template is multiply declared. |
---|
| 1088 | <br> |
---|
| 1089 | <br> |
---|
| 1090 | Furthermore, in order to add any needed comma separator, an "APPEND_*" version |
---|
| 1091 | must be used when the macro invocation appears after a normal parameter |
---|
| 1092 | declaration or after the invocation of another macro of this same group. |
---|
| 1093 | </td> |
---|
| 1094 | </tr> |
---|
| 1095 | <tr> |
---|
| 1096 | <td valign="top" width="50%">BOOST_USE_FACET(Type, loc)</td> |
---|
| 1097 | <td valign="top" width="50%">When the standard library does not have a comforming |
---|
| 1098 | std::use_facet there are various workarounds available, but they differ from |
---|
| 1099 | library to library. This macro provides a consistent way to access a locale's |
---|
| 1100 | facets. For example, replace:<pre>std::use_facet<Type>(loc);</pre> |
---|
| 1101 | <p>with:</p> |
---|
| 1102 | <pre>BOOST_USE_FACET(Type, loc);</pre> |
---|
| 1103 | <p>Note do not add a std:: prefix to the front of BOOST_USE_FACET.</p> |
---|
| 1104 | </td> |
---|
| 1105 | </tr> |
---|
| 1106 | <tr> |
---|
| 1107 | <td valign="top" width="50%">BOOST_HAS_FACET(Type, loc)</td> |
---|
| 1108 | <td valign="top" width="50%">When the standard library does not have a comforming |
---|
| 1109 | std::has_facet there are various workarounds available, but they differ from |
---|
| 1110 | library to library. This macro provides a consistent way to check a locale's |
---|
| 1111 | facets. For example, replace:<pre>std::has_facet<Type>(loc);</pre> |
---|
| 1112 | <p>with:</p> |
---|
| 1113 | <pre>BOOST_HAS_FACET(Type, loc);</pre> |
---|
| 1114 | <p>Note do not add a std:: prefix to the front of BOOST_HAS_FACET.</p> |
---|
| 1115 | </td> |
---|
| 1116 | </tr> |
---|
| 1117 | <tr> |
---|
| 1118 | <td valign="top" width="50%">BOOST_NESTED_TEMPLATE</td> |
---|
| 1119 | <td valign="top" width="50%">Member templates are supported by some compilers even |
---|
| 1120 | though they can't use the A::template member<U> syntax, as a workaround |
---|
| 1121 | replace:<pre>typedef typename A::template rebind<U> binder;</pre> |
---|
| 1122 | <p>with:</p> |
---|
| 1123 | <pre>typedef typename A::BOOST_NESTED_TEMPLATE rebind<U> binder;</pre> |
---|
| 1124 | </td> |
---|
| 1125 | </tr> |
---|
| 1126 | <tr> |
---|
| 1127 | <td valign="top" width="50%">BOOST_STRINGIZE(X)</td> |
---|
| 1128 | <td valign="top" width="50%">Converts the parameter X to a string after macro |
---|
| 1129 | replacement on X has been performed.</td> |
---|
| 1130 | </tr> |
---|
| 1131 | <tr> |
---|
| 1132 | <td valign="top" width="50%">BOOST_JOIN(X,Y)</td> |
---|
| 1133 | <td valign="top" width="50%">This piece of macro magic joins the two arguments |
---|
| 1134 | together, even when one of the arguments is itself a macro (see 16.3.1 in C++ |
---|
| 1135 | standard). This is normally used to create a mangled name in combination with a |
---|
| 1136 | predefined macro such a __LINE__.</td> |
---|
| 1137 | </tr> |
---|
| 1138 | </table> |
---|
| 1139 | <h4><a name="info_macros"></a>Boost Informational Macros</h4> |
---|
| 1140 | <p>The following macros describe boost features; these are the generally speaking |
---|
| 1141 | the only boost macros that should be tested in user code.</p> |
---|
| 1142 | <table border="1" cellpadding="7" cellspacing="1" width="100%"> |
---|
| 1143 | <tr> |
---|
| 1144 | <td valign="top" width="33%"><p align="center"><b>Macro</b></p> |
---|
| 1145 | </td> |
---|
| 1146 | <td valign="top" width="33%"><p align="center"><b>Header</b></p> |
---|
| 1147 | </td> |
---|
| 1148 | <td valign="top" width="33%"><p align="center"><b>Description</b></p> |
---|
| 1149 | </td> |
---|
| 1150 | </tr> |
---|
| 1151 | <tr> |
---|
| 1152 | <td valign="top" width="33%">BOOST_VERSION</td> |
---|
| 1153 | <td valign="top" width="33%"><boost/version.hpp></td> |
---|
| 1154 | <td valign="top" width="33%">Describes the boost version number in XXYYZZ format |
---|
| 1155 | such that: (BOOST_VERSION % 100) is the sub-minor version, ((BOOST_VERSION / |
---|
| 1156 | 100) % 1000) is the minor version, and (BOOST_VERSION / 100000) is the major |
---|
| 1157 | version.</td> |
---|
| 1158 | </tr> |
---|
| 1159 | <tr> |
---|
| 1160 | <td valign="top" width="33%">BOOST_NO_INT64_T</td> |
---|
| 1161 | <td valign="top" width="33%"><boost/cstdint.hpp><p><boost/stdint.h></p> |
---|
| 1162 | </td> |
---|
| 1163 | <td valign="top" width="33%">Defined if there are no 64-bit integral types: |
---|
| 1164 | int64_t, uint64_t etc.</td> |
---|
| 1165 | </tr> |
---|
| 1166 | <tr> |
---|
| 1167 | <td valign="top" width="33%">BOOST_NO_INTEGRAL_INT64_T</td> |
---|
| 1168 | <td valign="top" width="33%"><boost/cstdint.hpp><p><boost/stdint.h></p> |
---|
| 1169 | </td> |
---|
| 1170 | <td valign="top" width="33%">Defined if int64_t as defined by |
---|
| 1171 | <boost/cstdint.hpp> is not usable in integral constant expressions.</td> |
---|
| 1172 | </tr> |
---|
| 1173 | <tr> |
---|
| 1174 | <td valign="top">BOOST_MSVC</td> |
---|
| 1175 | <td valign="top"><boost/config.hpp></td> |
---|
| 1176 | <td valign="top">Defined if the compiler is really Microsoft Visual C++, as |
---|
| 1177 | opposed to one of the many other compilers that also define _MSC_VER.</td> |
---|
| 1178 | </tr> |
---|
| 1179 | <tr> |
---|
| 1180 | <td valign="top">BOOST_INTEL</td> |
---|
| 1181 | <td valign="top"><boost/config.hpp></td> |
---|
| 1182 | <td valign="top">Defined if the compiler is an Intel compiler, takes the same |
---|
| 1183 | value as the compiler version macro.</td> |
---|
| 1184 | </tr> |
---|
| 1185 | <TR> |
---|
| 1186 | <TD vAlign="top">BOOST_WINDOWS</TD> |
---|
| 1187 | <TD vAlign="top"><boost/config.hpp></TD> |
---|
| 1188 | <TD vAlign="top">Defined if the Windows platform API is available.</TD> |
---|
| 1189 | </TR> |
---|
| 1190 | <tr> |
---|
| 1191 | <td>BOOST_DINKUMWARE_STDLIB</td> |
---|
| 1192 | <td><boost/config.hpp></td> |
---|
| 1193 | <td>Defined if the dinkumware standard library is in use, takes the same value as |
---|
| 1194 | the Dinkumware library version macro _CPPLIB_VER if defined, otherwise 1.</td> |
---|
| 1195 | </tr> |
---|
| 1196 | <tr> |
---|
| 1197 | <td valign="top" width="33%">BOOST_NO_WREGEX</td> |
---|
| 1198 | <td valign="top" width="33%"><boost/regex.hpp></td> |
---|
| 1199 | <td valign="top" width="33%">Defined if the regex library does not support wide |
---|
| 1200 | character regular expressions.</td> |
---|
| 1201 | </tr> |
---|
| 1202 | <tr> |
---|
| 1203 | <td valign="top" width="33%">BOOST_COMPILER</td> |
---|
| 1204 | <td valign="top" width="33%"><boost/config.hpp></td> |
---|
| 1205 | <td valign="top" width="33%">Defined as a string describing the name and version |
---|
| 1206 | number of the compiler in use. Mainly for debugging the configuration.</td> |
---|
| 1207 | </tr> |
---|
| 1208 | <tr> |
---|
| 1209 | <td valign="top" width="33%">BOOST_STDLIB</td> |
---|
| 1210 | <td valign="top" width="33%"><boost/config.hpp></td> |
---|
| 1211 | <td valign="top" width="33%">Defined as a string describing the name and version |
---|
| 1212 | number of the standard library in use. Mainly for debugging the configuration.</td> |
---|
| 1213 | </tr> |
---|
| 1214 | <tr> |
---|
| 1215 | <td valign="top" width="33%">BOOST_PLATFORM</td> |
---|
| 1216 | <td valign="top" width="33%"><boost/config.hpp></td> |
---|
| 1217 | <td valign="top" width="33%">Defined as a string describing the name of the |
---|
| 1218 | platform. Mainly for debugging the configuration.</td> |
---|
| 1219 | </tr> |
---|
| 1220 | </table> |
---|
| 1221 | <h2><a name="guidelines"></a></h2> |
---|
| 1222 | <H4><A name="source"></A>Macros for libraries with separate source code</H4> |
---|
| 1223 | <P>The following macros and helper headers are of use to authors whose libraries |
---|
| 1224 | include separate source code, and are intended to address two issues: fixing |
---|
| 1225 | the ABI of the compiled library, and selecting which compiled library to link |
---|
| 1226 | against based upon the compilers settings.</P> |
---|
| 1227 | <H5>ABI Fixing</H5> |
---|
| 1228 | <P>When linking against a pre-compiled library it vital that the ABI used by the |
---|
| 1229 | compiler when building the library <EM>matches</EM> <EM>exactly</EM> the ABI |
---|
| 1230 | used by the code using the library. In this case ABI means things like |
---|
| 1231 | the struct packing arrangement used, the name mangling scheme used, or the size |
---|
| 1232 | of some types (enum types for example). This is separate from things like |
---|
| 1233 | threading support, or runtime library variations, which have to be dealt with |
---|
| 1234 | by build variants. To put this in perspective there is one compiler |
---|
| 1235 | (Borland's) that has so many compiler options that make subtle changes to the |
---|
| 1236 | ABI, that at least in theory there 3200 combinations, and that's without |
---|
| 1237 | considering runtime library variations. Fortunately these variations can |
---|
| 1238 | be managed by #pragma's that tell the compiler what ABI to use for the types |
---|
| 1239 | declared in your library, in order to avoid sprinkling #pragma's all over the |
---|
| 1240 | boost headers, there are some prefix and suffix headers that do the job, |
---|
| 1241 | typical usage would be:</P> |
---|
| 1242 | <PRE>#ifndef MY_INCLUDE_GUARD |
---|
| 1243 | #define MY_INCLUDE_GUARD |
---|
| 1244 | |
---|
| 1245 | // all includes go here: |
---|
| 1246 | #include <boost/config.hpp> |
---|
| 1247 | #include <whatever> |
---|
| 1248 | |
---|
| 1249 | #ifdef BOOST_HAS_ABI_HEADERS |
---|
| 1250 | # include BOOST_ABI_PREFIX |
---|
| 1251 | #endif |
---|
| 1252 | |
---|
| 1253 | namespace boost{ |
---|
| 1254 | // your code goes here |
---|
| 1255 | } |
---|
| 1256 | |
---|
| 1257 | #ifdef BOOST_HAS_ABI_HEADERS |
---|
| 1258 | # include BOOST_ABI_SUFFIX |
---|
| 1259 | #endif |
---|
| 1260 | |
---|
| 1261 | |
---|
| 1262 | #endif // include guard |
---|
| 1263 | </PRE> |
---|
| 1264 | <P>The user can disable this mechanism by defining BOOST_DISABLE_ABI_HEADERS, or |
---|
| 1265 | they can define BOOST_ABI_PREFIX and/or BOOST_ABI_SUFFIX to point to their own |
---|
| 1266 | prefix/suffix headers if they so wish.</P> |
---|
| 1267 | <H5>Automatic library selection</H5> |
---|
| 1268 | <P>It is essential that users link to a build of a library which was built against |
---|
| 1269 | the same runtime library that their application will be built against - if this |
---|
| 1270 | does not happen then the library will not be binary compatible with their own |
---|
| 1271 | code - and there is a high likelihood that their application will |
---|
| 1272 | experience runtime crashes. These kinds of problems can be extremely |
---|
| 1273 | time consuming and difficult to debug, and often lead to frustrated users and |
---|
| 1274 | authors alike (simply selecting the right library to link against is not as |
---|
| 1275 | easy as it seems when their are 6-8 of them to chose from, and some users seem |
---|
| 1276 | to be blissfully unaware that there even are different runtimes available to |
---|
| 1277 | them).</P> |
---|
| 1278 | <P>To solve this issue, some compilers allow source code to contain #pragma's that |
---|
| 1279 | instruct the linker which library to link against, all the user need do is |
---|
| 1280 | include the headers they need, place the compiled libraries in their library |
---|
| 1281 | search path, and the compiler and linker do the rest. Boost.config |
---|
| 1282 | supports this via the header <boost/config/auto_link.hpp>, before |
---|
| 1283 | including this header one or more of the following macros need to be defined:</P> |
---|
| 1284 | <P> |
---|
| 1285 | <TABLE id="Table1" cellSpacing="1" cellPadding="1" width="100%" border="1"> |
---|
| 1286 | <TR> |
---|
| 1287 | <TD>BOOST_LIB_NAME</TD> |
---|
| 1288 | <TD> |
---|
| 1289 | Required: An identifier containing the basename of the library, for |
---|
| 1290 | example 'boost_regex'.</TD> |
---|
| 1291 | </TR> |
---|
| 1292 | <TR> |
---|
| 1293 | <TD>BOOST_DYN_LINK</TD> |
---|
| 1294 | <TD>Optional: when set link to dll rather than static library.</TD> |
---|
| 1295 | </TR> |
---|
| 1296 | <TR> |
---|
| 1297 | <TD>BOOST_LIB_DIAGNOSTIC</TD> |
---|
| 1298 | <TD>Optional: when set the header will print out the name of the library selected |
---|
| 1299 | (useful for debugging).</TD> |
---|
| 1300 | </TR> |
---|
| 1301 | </TABLE> |
---|
| 1302 | </P> |
---|
| 1303 | <P>If the compiler supports this mechanism, then it will be told to link against |
---|
| 1304 | the appropriately named library, the actual algorithm used to mangle the name |
---|
| 1305 | of the library is documented inside <boost/config/auto_link.hpp> and has |
---|
| 1306 | to match that used to create the libraries via bjam 's install rules.</P> |
---|
| 1307 | <P>Typical usage would be:</P> |
---|
| 1308 | <PRE>// |
---|
| 1309 | // Don't include auto-linking code if the user has disabled it by |
---|
| 1310 | // defining BOOST_WHATEVER_NO_LIB, or if this is one of our own |
---|
| 1311 | // source files (signified by BOOST_WHATEVER_SOURCE): |
---|
| 1312 | // |
---|
| 1313 | #if !defined(BOOST_WHATEVER_NO_LIB) && !defined(BOOST_WHATEVER_SOURCE) |
---|
| 1314 | # define BOOST_LIB_NAME boost_whatever |
---|
| 1315 | # ifdef BOOST_WHATEVER_DYN_LINK |
---|
| 1316 | # define BOOST_DYN_LINK |
---|
| 1317 | # endif |
---|
| 1318 | # include <boost/config/auto_link.hpp> |
---|
| 1319 | #endif |
---|
| 1320 | </PRE> |
---|
| 1321 | <H2>Guidelines for Boost Authors</H2> |
---|
| 1322 | <p>The <a href="../../boost/config.hpp">boost/config.hpp</a> header is used to |
---|
| 1323 | pass configuration information to other boost files, allowing them to cope with |
---|
| 1324 | platform dependencies such as arithmetic byte ordering, compiler pragmas, or |
---|
| 1325 | compiler shortcomings. Without such configuration information, many current |
---|
| 1326 | compilers would not work with the Boost libraries.</p> |
---|
| 1327 | <p>Centralizing configuration information in this header reduces the number of |
---|
| 1328 | files that must be modified when porting libraries to new platforms, or when |
---|
| 1329 | compilers are updated. Ideally, no other files would have to be modified when |
---|
| 1330 | porting to a new platform.</p> |
---|
| 1331 | <p>Configuration headers are controversial because some view them as condoning |
---|
| 1332 | broken compilers and encouraging non-standard subsets. Adding settings for |
---|
| 1333 | additional platforms and maintaining existing settings can also be a problem. |
---|
| 1334 | In other words, configuration headers are a necessary evil rather than a |
---|
| 1335 | desirable feature. The boost config.hpp policy is designed to minimize the |
---|
| 1336 | problems and maximize the benefits of a configuration header.</p> |
---|
| 1337 | <p>Note that:</p> |
---|
| 1338 | <ul> |
---|
| 1339 | <li> |
---|
| 1340 | Boost library implementers are not required to #include |
---|
| 1341 | <boost/config.hpp>, and are not required in any way to support compilers |
---|
| 1342 | that do not comply with the C++ Standard (ISO/IEC 14882). |
---|
| 1343 | <li> |
---|
| 1344 | If a library implementer wishes to support some non-conforming compiler, or to |
---|
| 1345 | support some platform specific feature, #include <boost/config.hpp> is |
---|
| 1346 | the preferred way to obtain configuration information not available from the |
---|
| 1347 | standard headers such as <climits>, etc. |
---|
| 1348 | <li> |
---|
| 1349 | If configuration information can be deduced from standard headers such as |
---|
| 1350 | <climits>, use those standard headers rather than |
---|
| 1351 | <boost/config.hpp>. |
---|
| 1352 | <li> |
---|
| 1353 | Boost files that use macros defined in <boost/config.hpp> should have |
---|
| 1354 | sensible, standard conforming, default behavior if the macro is not defined. |
---|
| 1355 | This means that the starting point for porting <boost/config.hpp> to a |
---|
| 1356 | new platform is simply to define nothing at all specific to that platform. In |
---|
| 1357 | the rare case where there is no sensible default behavior, an #error message |
---|
| 1358 | should describe the problem. |
---|
| 1359 | <li> |
---|
| 1360 | If a Boost library implementer wants something added to config.hpp, post a |
---|
| 1361 | request on the Boost mailing list. There is no guarantee such a request will be |
---|
| 1362 | honored; the intent is to limit the complexity of config.hpp. |
---|
| 1363 | <li> |
---|
| 1364 | The intent is to support only compilers which appear on their way to becoming |
---|
| 1365 | C++ Standard compliant, and only recent releases of those compilers at that. |
---|
| 1366 | <li> |
---|
| 1367 | The intent is not to disable mainstream features now well-supported by the |
---|
| 1368 | majority of compilers, such as namespaces, exceptions, RTTI, or templates. |
---|
| 1369 | </li> |
---|
| 1370 | </ul> |
---|
| 1371 | <h4><a name="defect_guidelines"></a>Adding New Defect Macros</h4> |
---|
| 1372 | <p>When you need to add a new defect macro - either to fix a problem with an |
---|
| 1373 | existing library, or when adding a new library - distil the issue down to a |
---|
| 1374 | simple test case, often at this point other (possibly better) workarounds may |
---|
| 1375 | become apparent. Secondly always post the test case code to the boost mailing |
---|
| 1376 | list and invite comments; remember that C++ is complex and that sometimes what |
---|
| 1377 | may appear a defect, may in fact turn out to be a problem with the authors |
---|
| 1378 | understanding of the standard.</p> |
---|
| 1379 | <p>When you name the macro, follow the BOOST_NO_SOMETHING naming convention, so |
---|
| 1380 | that it's obvious that this is a macro reporting a defect.</p> |
---|
| 1381 | <p>Finally, add the test program to the regression tests. You will need to place |
---|
| 1382 | the test case in a .ipp file with the following comments near the top:</p> |
---|
| 1383 | <pre>// MACRO: BOOST_NO_FOO |
---|
| 1384 | // TITLE: foo |
---|
| 1385 | // DESCRIPTION: If the compiler fails to support foo</pre> |
---|
| 1386 | <p>These comments are processed by the autoconf script, so make sure the format |
---|
| 1387 | follows the one given. The file should be named "boost_no_foo.ipp", where foo |
---|
| 1388 | is the defect description - try and keep the file name under the Mac 30 |
---|
| 1389 | character filename limit though. You will also need to provide a function |
---|
| 1390 | prototype "int test()" that is declared in a namespace with the same name as |
---|
| 1391 | the macro, but in all lower case, and which returns zero on success:</p> |
---|
| 1392 | <pre>namespace boost_no_foo{ |
---|
| 1393 | |
---|
| 1394 | int test() |
---|
| 1395 | { |
---|
| 1396 | // test code goes here: |
---|
| 1397 | // |
---|
| 1398 | return 0; |
---|
| 1399 | } |
---|
| 1400 | |
---|
| 1401 | }</pre> |
---|
| 1402 | <p> |
---|
| 1403 | Once the test code is in place, build and run the program "generate.cpp" that |
---|
| 1404 | you will find in the boost-root/libs/config/tools/ directory. This generates |
---|
| 1405 | two .cpp test files from the new test code, and adds the tests to the |
---|
| 1406 | regression test Jamfile, and the config_test.cpp test program. Finally add a |
---|
| 1407 | new entry to config_info.cpp so that the new macro gets printed out when that |
---|
| 1408 | program is run.</p> |
---|
| 1409 | <h4><a name="feature_guidelines"></a>Adding New Feature Test Macros</h4> |
---|
| 1410 | <p>When you need to add a macro that describes a feature that the standard does |
---|
| 1411 | not require, follow the convention for adding a new defect macro (above), but |
---|
| 1412 | call the macro BOOST_HAS_FOO, and name the test file "boost_has_foo.ipp". Try |
---|
| 1413 | not to add feature test macros unnecessarily, if there is a platform specific |
---|
| 1414 | macro that can already be used (for example _WIN32, __BEOS__, or __linux) to |
---|
| 1415 | identify the feature then use that. Try to keep the macro to a feature group, |
---|
| 1416 | or header name, rather than one specific API (for example BOOST_HAS_NL_TYPES_H |
---|
| 1417 | rather than BOOST_HAS_CATOPEN). If the macro describes a POSIX feature group, |
---|
| 1418 | then add boilerplate code to <a href="../../boost/config/suffix.hpp">boost/config/suffix.hpp</a> |
---|
| 1419 | to auto-detect the feature where possible (if you are wondering why we can't |
---|
| 1420 | use POSIX feature test macro directly, remember that many of these features can |
---|
| 1421 | be added by third party libraries, and are not therefore identified inside |
---|
| 1422 | <unistd.h>).</p> |
---|
| 1423 | <h4><a name="modify_guidelines"></a>Modifying the Boost Configuration Headers</h4> |
---|
| 1424 | <p>The aim of boost's configuration setup is that the configuration headers should |
---|
| 1425 | be relatively stable - a boost user should not have to recompile their code |
---|
| 1426 | just because the configuration for some compiler that they're not interested in |
---|
| 1427 | has changed. Separating the configuration into separate compiler/standard |
---|
| 1428 | library/platform sections provides for part of this stability, but boost |
---|
| 1429 | authors require some amount of restraint as well, in particular:</p> |
---|
| 1430 | <p><<a href="../../boost/config.hpp">boost/config.hpp</a>> should never |
---|
| 1431 | change, don't alter this file.</p> |
---|
| 1432 | <p><<a href="../../boost/config/user.hpp">boost/config/user.hpp</a>> is |
---|
| 1433 | included by default, don't add extra code to this file unless you have to. If |
---|
| 1434 | you do, please remember to update <a href="tools/configure.in">libs/config/tools/configure.in</a> |
---|
| 1435 | as well.</p> |
---|
| 1436 | <p><<a href="../../boost/config/suffix.hpp">boost/config/suffix.hpp</a>> is |
---|
| 1437 | always included so be careful about modifying this file as it breaks |
---|
| 1438 | dependencies for everyone. This file should include only "boilerplate" |
---|
| 1439 | configuration code, and generally should change only when new macros are added.</p> |
---|
| 1440 | <p><<a href="../../boost/config/select_compiler_config.hpp">boost/config/select_compiler_config.hpp</a>>, |
---|
| 1441 | <<a href="../../boost/config/select_platform_config.hpp">boost/config/select_platform_config.hpp</a>> |
---|
| 1442 | and <<a href="../../boost/config/select_stdlib_config.hpp">boost/config/select_stdlib_config.hpp</a>> |
---|
| 1443 | are included by default and should change only if support for a new |
---|
| 1444 | compiler/standard library/platform is added.</p> |
---|
| 1445 | <p>The compiler/platform/standard library selection code is set up so that unknown |
---|
| 1446 | platforms are ignored and assumed to be fully standards compliant - this gives |
---|
| 1447 | unknown platforms a "sporting chance" of working "as is" even without running |
---|
| 1448 | the configure script.</p> |
---|
| 1449 | <p>When adding or modifying the individual mini-configs, assume that future, as |
---|
| 1450 | yet unreleased versions of compilers, have all the defects of the current |
---|
| 1451 | version. Although this is perhaps unnecessarily pessimistic, it cuts down on |
---|
| 1452 | the maintenance of these files, and experience suggests that pessimism is |
---|
| 1453 | better placed than optimism here!</p> |
---|
| 1454 | <h2><a name="rationale"></a>Rationale</h2> |
---|
| 1455 | <p>The problem with many traditional "textbook" implementations of configuration |
---|
| 1456 | headers (where all the configuration options are in a single "monolithic" |
---|
| 1457 | header) is that they violate certain fundamental software engineering |
---|
| 1458 | principles which would have the effect of making boost more fragile, more |
---|
| 1459 | difficult to maintain and more difficult to use safely. You can find a |
---|
| 1460 | description of the principles from the <a href="http://www.objectmentor.com/publications/Principles%20and%20Patterns.PDF"> |
---|
| 1461 | following article</a>.</p> |
---|
| 1462 | <h4>The problem</h4> |
---|
| 1463 | <p>Consider a situation in which you are concurrently developing on multiple |
---|
| 1464 | platforms. Then consider adding a new platform or changing the platform |
---|
| 1465 | definitions of an existing platform. What happens? Everything, and this does |
---|
| 1466 | literally mean everything, recompiles.. Isn't it quite absurd that adding a new |
---|
| 1467 | platform, which has absolutely nothing to do with previously existing |
---|
| 1468 | platforms, means that all code on all existing platforms needs to be |
---|
| 1469 | recompiled?</p> |
---|
| 1470 | <p>Effectively, there is an imposed physical dependency between platforms that |
---|
| 1471 | have nothing to do with each other. Essentially, the traditional solution |
---|
| 1472 | employed by configuration headers does not conform to the Open-Closed |
---|
| 1473 | Principle:</p> |
---|
| 1474 | <p><b><i>"A module should be open for extension but closed for modification."</i></b></p> |
---|
| 1475 | <p>Extending a traditional configuration header implies modifying existing code.</p> |
---|
| 1476 | <p>Furthermore, consider the complexity and fragility of the platform detection |
---|
| 1477 | code. What if a simple change breaks the detection on some minor platform? What |
---|
| 1478 | if someone accidentally or on purpose (as a workaround for some other problem) |
---|
| 1479 | defines some platform dependent macros that are used by the detection code? A |
---|
| 1480 | traditional configuration header is one of the most volatile headers of the |
---|
| 1481 | entire library, and more stable elements of Boost would depend on it. This |
---|
| 1482 | violates the Stable Dependencies Principle:</p> |
---|
| 1483 | <p><b><i>"Depend in the direction of stability."</i></b></p> |
---|
| 1484 | <p>After even a minor change to a traditional configuration header on one minor |
---|
| 1485 | platform, almost everything on every platform should be tested if we follow |
---|
| 1486 | sound software engineering practice.</p> |
---|
| 1487 | <p>Another important issue is that it is not always possible to submit changes to |
---|
| 1488 | <boost/config.hpp>. Some boost users are currently working on platforms |
---|
| 1489 | using tools and libraries that are under strict Non-Disclosure Agreements. In |
---|
| 1490 | this situation it is impossible to submit changes to a traditional monolithic |
---|
| 1491 | configuration header, instead some method by which the user can insert their |
---|
| 1492 | own configuration code must be provided.</p> |
---|
| 1493 | <h4>The solution</h4> |
---|
| 1494 | <p>The approach taken by boost's configuration headers is to separate |
---|
| 1495 | configuration into three orthogonal parts: the compiler, the standard library |
---|
| 1496 | and the platform. Each compiler/standard library/platform gets its own |
---|
| 1497 | mini-configuration header, so that change to one compiler's configuration (for |
---|
| 1498 | example) does not effect other compilers. In addition there are measures that |
---|
| 1499 | can be taken both to omit the compiler/standard library/platform detection code |
---|
| 1500 | (so that adding support to a new platform does not break dependencies), or to |
---|
| 1501 | freeze the configuration completely; providing almost complete protection |
---|
| 1502 | against dependency changes.</p> |
---|
| 1503 | <h2><a name="Acknowledgements"></a>Acknowledgements</h2> |
---|
| 1504 | <p>Beman Dawes provided the original config.hpp and part of this document. Vesa |
---|
| 1505 | Karvonen provided a description of the principles (see <a href="#rationale">rationale</a>) |
---|
| 1506 | and put together an early version of the current configuration setup. John |
---|
| 1507 | Maddock put together the configuration current code, the test programs, the |
---|
| 1508 | configuration script and the reference section of this document. Numerous boost |
---|
| 1509 | members, past and present, have contributed fixes to boost's configuration.</p> |
---|
| 1510 | <p> </p> |
---|
| 1511 | <hr> |
---|
| 1512 | <p>© Beman Dawes 2001</p> |
---|
| 1513 | <p>© Vesa Karvonen 2001</p> |
---|
| 1514 | <p>© John Maddock 2001</p> |
---|
| 1515 | <p> </p> |
---|
| 1516 | <p> </p> |
---|
| 1517 | <p> </p> |
---|
| 1518 | <p> </p> |
---|
| 1519 | <p> </p> |
---|
| 1520 | </body> |
---|
| 1521 | </html> |
---|