Когда у нас есть какое-либо практическое применение иерархическим пространствам имен в C++?

Это понадобится для больших кодовых баз. Взгляните на boost для примера. Я не думаю, что кто-то назвал бы код ускорения «безумным».

Если учесть тот факт, что на любом уровне иерархии люди могут понять только примерно 10 пунктов, то два уровня дают вам максимум 100. Достаточно большому проекту потребуется больше, поэтому он легко может оказаться на трех уровнях.

Очевидно, это вопрос мнения. Но на самом деле все сводится к организации. Например, у меня есть проект, в котором есть плагин api с функциями / объектами, которые выглядят примерно так:

plugins::v1::function

Когда будет выпущена версия 2.0, они будут помещены в подпространство имен v2. Я планирую только отказаться от рекомендаций, но никогда не удалять элементы v1, которые должны хорошо поддерживать обратную совместимость в будущем. Это всего лишь один пример «разумного» использования. Я полагаю, что некоторые люди будут отличаться, но, как я уже сказал, это вопрос мнения.

Я работаю над приложением XXX в своей компании yyy, и я пишу подсистему GUI. Поэтому я использую yyy :: xxx :: gui в качестве пространства имен.

Иерархические пространства имен действительно используются в том, что они позволяют постепенно уточнять определения. Конечно, один поставщик может создавать два класса с одним и тем же именем. Часто первый уровень занимает название компании, второй определяет продукт, третий (и, возможно, больше) я предоставляю домен.

Есть и другие варианты использования разделения пространства имен. Одна из популярных ситуаций - размещение базовых классов для шаблона фабрики в его собственном пространстве имен, а затем производные фабрики в их собственных пространствах имен по поставщику. Например. System.Data, System.Data.SqlClient и System.Data.OleDbClient.

Это зависит от ваших потребностей и стиля программирования. Но одно из преимуществ namespace - помочь разделить пространство имен (отсюда и название). При использовании единого пространства имен по мере увеличения размера и сложности вашего проекта увеличивается вероятность конфликта имен.

Если вы пишете код, предназначенный для совместного использования или повторного использования, это становится еще более важным.

Вы легко можете оказаться в ситуации, когда вам потребуется более одного уровня. Например, у вашей компании есть гигантское пространство имен для всего своего кода, чтобы отделить его от стороннего кода, и вы пишете библиотеку, которую хотите поместить в собственное пространство имен. Как правило, если у вас очень большая и сложная система с иерархической структурой, разумно использовать несколько уровней пространства имен.

Согласен на заявки. Большинство людей, использующих несколько уровней пространств имен (по моему опыту), пришли из фона Java или .NET, где шум значительно меньше. Я считаю, что хорошие префиксы классов могут заменять несколько уровней пространств имен.

Но я видел хорошее использование нескольких уровней пространства имен в boost (и других библиотеках). Все находится в пространстве имен boost, но библиотекам разрешено (рекомендуется?) Находиться в собственном пространстве имен. Например - пространство имен boost :: this_thread. Это позволяет такие вещи, как ...

boost::this_thread::get_id()
boost::this_thread::interruption_requested()

this_thread - это просто пространство имен для набора бесплатных функций. Вы можете сделать то же самое с классом и статическими функциями (то есть способом определения свободной функции в Java), но зачем делать что-то неестественное, если в языке есть естественный способ сделать это?

Достаточно взглянуть на библиотеку базовых классов .Net, чтобы увидеть, как иерархия пространств имен находит хорошее применение. В некоторых местах он проходит на четыре или пять уровней, но в основном это всего два или три уровня, и организация очень хороша для поиска вещей.

Чем больше кодовая база, тем больше потребность в иерархических пространствах имен. По мере того, как ваш проект становится все больше и больше, вы обнаружите, что вам нужно разбить его на части, чтобы упростить поиск материала.

Например, в настоящее время мы используем двухуровневую иерархию. Однако некоторые из самых больших частей, о которых мы сейчас говорим, разбивают их на 3 уровня.