Зачем реализация BOOST_CURRENT_FUNCTION (которая в итоге состоит всего из одного макроса) помещена в два пространства имён и функцию?

namespace boost
{

namespace detail
{

inline void current_function_helper()
{
    // ...
}

} // namespace detail

} // namespace boost

http://www.boost.org/doc/libs/1_52_0/boost/current_function.hpp

Чем это может быть вызвано? Просто Code Style?

NT>Чем это может быть вызвано? Просто Code Style?

> Btw: what is purpose of current_function_helper()?

The __FUNCSIG__ macro is only defined in functions.

http://www.mail-archive.com/boost@lists.boost.org/msg08283.html

>> Btw: what is purpose of current_function_helper()?

sch>The __FUNCSIG__ macro is only defined in functions.

С чего бы? Это же макрос, на самом деле __FUNCSIG__ как раз и будет помещён в функцию.

Здравствуйте, Nikita.Trophimov, Вы писали:

да, интересно... Первый раз такое вижу

Здравствуйте, Nikita.Trophimov, Вы писали:

NT>С чего бы? Это же макрос, на самом деле __FUNCSIG__ как раз и будет помещён в функцию.

Проверить, будет ли __FUNCSIG__ определен внутри функции, можно только внутри функции. Слово "функция" в предыдущем предложении встречается два раза и относится к двум различным функциям, в первом случае — к той, где BOOST_CURRENT_FUNCTION используется, во втором — к той, где он определяется.

То есть __FUNCSIG__ исполняет в реализации две роли, ту же, которую исполняет __GNUC__, и ту же, которую исполняет __PRETTY_FUNCTION__. Но чтобы __FUNCSIG__ можно было использовать как __GNUC__, его нужно поместить во (вспомогательную) функцию.

Здравствуйте, igna, Вы писали:

I>То есть __FUNCSIG__ исполняет в реализации две роли, ту же, которую исполняет __GNUC__, и ту же, которую исполняет __PRETTY_FUNCTION__. Но чтобы __FUNCSIG__ можно было использовать как __GNUC__, его нужно поместить во (вспомогательную) функцию.
в 2005 студии не нужно

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, igna, Вы писали:

I>>То есть __FUNCSIG__ исполняет в реализации две роли, ту же, которую исполняет __GNUC__, и ту же, которую исполняет __PRETTY_FUNCTION__. Но чтобы __FUNCSIG__ можно было использовать как __GNUC__, его нужно поместить во (вспомогательную) функцию.
V>в 2005 студии не нужно

 . . .
#elif defined(__FUNCSIG__)
# define . . .
#elif . . .
 . . .

Ты знаешь способ вынести этот фрагмент из определения функции?

Здравствуйте, Vain, Вы писали:

V>в 2005 студии не нужно

Пишут, что нужно:

Valid only within a function and returns the signature of the enclosing function (as a string).

здесь

Здравствуйте, rg45, Вы писали:

R> . . .
R>#elif defined(__FUNCSIG__)
R># define . . .
R>#elif . . .
R> . . .

R>Ты знаешь способ вынести этот фрагмент из определения функции?

Компилятор мог бы определять __FUNCSIG__ вне функции как-нибудь. Фактически только для того, чтобы можно было проверить, что этот макрос поддерживается.

Здравствуйте, igna, Вы писали:

V>>в 2005 студии не нужно
I>Пишут, что нужно:
I>

I>Valid only within a function and returns the signature of the enclosing function (as a string).

I>здесь
тем не менее ifdef возвращает true, проверено в 2005/2010 студиях

Здравствуйте, rg45, Вы писали:

I>>>То есть __FUNCSIG__ исполняет в реализации две роли, ту же, которую исполняет __GNUC__, и ту же, которую исполняет __PRETTY_FUNCTION__. Но чтобы __FUNCSIG__ можно было использовать как __GNUC__, его нужно поместить во (вспомогательную) функцию.
V>>в 2005 студии не нужно
R>

R> . . .
R>#elif defined(__FUNCSIG__)
R># define . . .
R>#elif . . .
R> . . .
R>

R>Ты знаешь способ вынести этот фрагмент из определения функции?
зачем его туда вносить?

Здравствуйте, Vain, Вы писали:

V>тем не менее ifdef возвращает true, проверено в 2005/2010 студиях

Ну неудивительно, что разработчики Boost не полагаются на недокументированное поведение компилятора.

I>То есть __FUNCSIG__ исполняет в реализации две роли, ту же, которую исполняет __GNUC__, и ту же, которую исполняет __PRETTY_FUNCTION__. Но чтобы __FUNCSIG__ можно было использовать как __GNUC__, его нужно поместить во (вспомогательную) функцию.

Т.е. даже просто для того, чтобы проверить, определён ли макрос __FUNCSIG__ при помощи препроцессорной директивы #ifdef, нам нужна функция?

V>тем не менее ifdef возвращает true, проверено в 2005/2010 студиях

В MSVS 12 тоже.

Здравствуйте, igna, Вы писали:

V>>тем не менее ifdef возвращает true, проверено в 2005/2010 студиях
I>Ну неудивительно, что разработчики Boost не полагаются на недокументированное поведение компилятора.
непонятно зачем полагаться на поведение которого нет, в этом и был вопрос топикстартера, ваш кеп

Здравствуйте, Nikita.Trophimov, Вы писали:

NT>Т.е. даже просто для того, чтобы проверить, определён ли макрос __FUNCSIG__ при помощи препроцессорной директивы #ifdef, нам нужна функция?

В документации написано "Valid only within a function", так-что если не хочешь полагаться на недокументированное поведение компилятора, то да, нужна функция.

Здравствуйте, Vain, Вы писали:

V>непонятно зачем полагаться на поведение которого нет, в этом и был вопрос топикстартера, ваш кеп

Это какого поведения нет?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Vain, Вы писали:
V>>тем не менее ifdef возвращает true, проверено в 2005/2010 студиях

I>Ну неудивительно, что разработчики Boost не полагаются на недокументированное поведение компилятора.

Есть еще одно соображение. Почему разработчики в качестве аргумента условной директивы использовали именно __FUNCSIG__, а не какой-нибудь другой специфический макрос — _MSC_VER, например? Возможно, __FUNCSIG__ используется не только в MSVC, а в каких-то еще компиляторах? И если так, то решение о месте размещения всего этого хозяйства не могло приниматься только лишь на основании поведения MSVC.

Здравствуйте, igna, Вы писали:

V>>непонятно зачем полагаться на поведение которого нет, в этом и был вопрос топикстартера, ваш кеп
I>Это какого поведения нет?
что ifdef вернёт false