Пространства имен C++, сравнение с пакетами Java
Я сделал набор Java, кодирующего недавно, и привык для очень определенных систем именования пакета с глубоким вложением, например. com.company.project.db. Это хорошо работает в Java, AS3/Flex и C#. Я видел ту же парадигму, примененную в C++ также, но я также услышал, что это плохо для просмотра пространств имен C++ как прямые дубликаты к пакетам Java.
Это верно, и почему? Как пространства имен/пакеты подобны и отличаются? Какие проблемы, вероятно, видно при использовании глубоко вложенных пространств имен?
5 ответов
в пространстве имен C ++ предстоит разделение доступных имен. Пакеты Java оказываются в модулях. Иерархия именования - это только один аспект этого.
Нет ничего плохого, Per-SE, с глубоко вложенными пространствами имен в C ++, за исключением того, что они не требуются, поскольку не требуется никакой модульной системы, а дополнительные слои просто добавляют шум. Обычно достаточно, чтобы иметь один или два уровня пространства имен, с нечетным дополнительным уровнем для внутренних деталей (часто только что называется деталями).
Существуют также дополнительные правила на пространства имен C ++, которые могут уловить вас, если он изменился - такой как , зависимый от аргументов , и правила вокруг разрешения на родительские уровни. Wrt Последнее, возьми:
namespace a{ namespace b{ int x; } }
namespace b{ string x; }
namespace a
{
b::x = 42;
}
Это законно? Это очевидно, что происходит? Вам нужно знать прецедентство разрешения пространства имен, чтобы ответить на эти вопросы.
Вы можете иметь вложенные пространства имен в C ++.
Они не работают так же, как в Java, хотя, очевидно,. Пакеты Java действительно намного лучше определены, и нет реальной статической инициализации странности. С пространствами имен C ++ полезны, но все равно есть справедливый случай опасности.
В C ++ базовая единица дизайна и реализации - это класс, а не пространство имен. Пространства имен были предназначены как средство предотвращения столкновений имени в крупных библиотеках, а не для выражения концепций.
Классы имеют несколько преимуществ над пространствами имен:
- У них могут быть конструкторы и деструкторы
- , они могут иметь частные члены
- , они не могут быть восстановлены
, однако, я бы выглядел дважды при любых глубоко вложенных отношениях Отказ Это действительно не хороший способ проектирования программного обеспечения, а также приводит к нечитаемому коду, будьте ли вы классы Juse или пространства имен.
Я добавлю в пару вещей, которые я слышал, но не знаю правдивость, пожалуйста, помогите подтвердить / развеять их.
Производительность C ++ (как-то), затронутая длинными полноэкранными указанными именами методов, например,
namepace1 :: namespace2 :: namespace3 :: Classx :: Method123 ()Вы можете ударить ограничение на допустимую длину символа в Компилятор / линкер
Java-пакеты не вложены, они плоские. Любое явное вложение - не более чем соглашение об именовании.
Например, пакет com.company.project.db не имеет никакого отношения к com.company.project или com.company.project.db.x. Код в com.company.project.db не имеет больше доступа к коду в com.company.project.db.x, чем код в a.b.c.