Объявление пространства имен как макрос - C++
В стандартной библиотеке я нашел то пространство имен std объявляется как макрос.
#define _STD_BEGIN namespace std {
#define _STD_END }
- Действительно ли это - лучшая практика при использовании пространств имен?
- Макрос объявляется в
Microsoft Visual Studio 9.0\VC\include\yvals.h. Но я не мог найти файлы STL включая это. Если это не включено, как это может использоваться?
Любые мысли..?
5 ответов
Вероятно, это не лучший способ, поскольку его трудно читать по сравнению с обычным объявлением пространства имен . Тем не менее, помните, что правила не всегда применяются повсеместно, и я уверен, что есть сценарий, в котором макрос может значительно очистить ситуацию.
«Но я не смог найти файлы STL, включая этот. Если он не включен, как его можно использовать?».
Все файлы, в которых используется этот макрос, так или иначе включают yval.h . Например, включает, , который включает , который включает , который включает , включая . Цепочка может быть глубокой, но она действительно включает ее в какой-то момент.
И я хочу уточнить, это применимо только к этой конкретной реализации стандартной библиотеки; это никоим образом не стандартизировано.
- В целом нет. Макросы, вероятно, использовались в то время, когда пространства имен не были реализованы некоторыми компиляторами, или для совместимости с конкретными платформами.
- Без понятия. Вероятно, файл был включен каким-то другим файлом, который был включен в STL-файл.
Один из подходов, который я видел в библиотеке, которую я недавно использовал, был:
BEGIN_NAMESPACE_XXX()
, где XXX - количество уровней пространства имен, например:
BEGIN_NAMESPACE_3(ns1, ns1, ns3)
примет три аргумента и расширится до
namespace ns1 {
namespace ns2 {
namespace ns2 {
, а соответствующий END_NAMESPACE_3 расширится до
}
}
}
(я добавил символы новой строки и отступ только для ясности)
Я думаю, что единственная причина делать это, если вы хотите легко изменить пространство имен, используемое вашим приложением / библиотекой, или вообще отключить пространства имен по причинам совместимости.
Я мог бы сделать это для библиотек C, которые включены в C++ по ссылке (например, заголовок, который C называет string.h и который C++ называет cstring). В этом случае определение макроса будет зависеть от #ifdef _c_plus_plus.
Я бы не стал делать этого в общем случае. Я не могу назвать ни одного стоящего компилятора, который бы не поддерживал пространства имен, исключения, шаблоны и другие "современные" возможности C++ (современные - в кавычках, потому что эти возможности были добавлены в середине-конце 90-х). На самом деле, по моему определению, компиляторы стоит использовать только в том случае, если они обеспечивают хорошую поддержку соответствующего языка. Это не проблема языка; это простой случай "если бы я выбрал язык X, я бы предпочел использовать его в том виде, в котором он существует сегодня, а не в том, в котором он существовал десять или два года назад". Я никогда не понимал, почему некоторые проекты тратят время на поддержку компиляторов C, существовавших до ANSI, например.