Brian Silverman | ea861c1 | 2018-08-04 17:43:02 -0700 | [diff] [blame^] | 1 | //// |
| 2 | Copyright 2002, 2017 Peter Dimov |
| 3 | |
| 4 | Distributed under the Boost Software License, Version 1.0. |
| 5 | |
| 6 | See accompanying file LICENSE_1_0.txt or copy at |
| 7 | http://www.boost.org/LICENSE_1_0.txt |
| 8 | //// |
| 9 | |
| 10 | # Current Function Macro, <boost/current_function.hpp> |
| 11 | :toc: |
| 12 | :toc-title: |
| 13 | :idprefix: |
| 14 | |
| 15 | ## BOOST_CURRENT_FUNCTION |
| 16 | |
| 17 | The header `<boost/current_function.hpp>` defines a single macro, `BOOST_CURRENT_FUNCTION`, |
| 18 | similar to the C99 predefined identifier `\\__func__`. |
| 19 | |
| 20 | `BOOST_CURRENT_FUNCTION` expands to a string literal containing |
| 21 | the (fully qualified, if possible) name of the enclosing function. If there is |
| 22 | no enclosing function, the behavior is unspecified. |
| 23 | |
| 24 | Some compilers do not provide a way to obtain the name of the current enclosing |
| 25 | function. On such compilers, or when the macro `BOOST_DISABLE_CURRENT_FUNCTION` |
| 26 | is defined, `BOOST_CURRENT_FUNCTION` expands to `"(unknown)"`. |
| 27 | |
| 28 | `BOOST_DISABLE_CURRENT_FUNCTION` addresses a use case in which the programmer |
| 29 | wishes to eliminate the string literals produced by `BOOST_CURRENT_FUNCTION` from |
| 30 | the final executable for security reasons. |