Чи є кращий спосіб виразити вкладені простори імен у C ++ всередині заголовка

Я перейшов з C ++ на Java та C # і думаю, що використання просторів імен / пакетів там набагато краще (добре структуровано). Потім я повернувся до C ++ і спробував використовувати простори імен так само, але необхідний синтаксис жахливий у заголовковому файлі.

namespace MyCompany
{
    namespace MyModule
    {
        namespace MyModulePart //e.g. Input
        {
            namespace MySubModulePart
            {
                namespace ...
                {
                    public class MyClass    

Мені теж здається дивним (щоб уникнути глибокого відступу):

namespace MyCompany
{
namespace MyModule
{
namespace MyModulePart //e.g. Input
{
namespace MySubModulePart
{
namespace ...
{
     public class MyClass
     {

Чи існує коротший спосіб висловити вищезазначене? Мені чогось не вистачає

namespace MyCompany::MyModule::MyModulePart::...
{
   public class MyClass

Оновлення

Гаразд, деякі кажуть, що концепція використання в Java / C # та C ++ відрізняється. Дійсно? Я думаю, що (динамічне) завантаження класів не є єдиною метою просторів імен (це дуже технічно аргументована перспектива). Чому б мені не використовувати його для читабельності та структурування, наприклад, думати про "IntelliSense".

В даний час немає логіки / клею між простором імен і тим, що ви можете там знайти. Java та C # роблять це набагато краще ... Навіщо включати <iostream>та мати простір імен std? Гаразд, якщо ви говорите, що логіка повинна покладатися на заголовок, чому #include не використовує дружній синтаксис "IntelliSense", як #include <std::io::stream>або <std/io/stream>? Я думаю, що відсутність структурування у бібліотеках за замовчуванням є однією з слабких сторін C ++ порівняно з Java / C #.

Якщо унікальність для завзятих конфліктів - це одна Точка (а це також точка С # та Java), хороша ідея - використовувати назву проекту або назву компанії як простір імен, чи не так Ви вважаєте?

З одного боку, кажуть, що C ++ є найбільш гнучким ... але всі сказали "не робити цього"? Мені здається, що C ++ може робити багато речей, але має жахливий синтаксис навіть у найпростіших справах у багатьох випадках порівняно з C #.

Оновлення 2

Більшість користувачів заявляє, що створювати глибше вкладання, ніж два рівні, - це нісенітниця. Гаразд, то як щодо Windows :: UI :: Xaml та Windows :: UI :: Xaml :: Controls :: Простіри імен примітивів у розробці Win8? Я думаю, що використання простором імен Microsoft має сенс, і це насправді глибше, ніж просто 2 рівні. Я думаю, що більші бібліотеки / проекти потребують більш глибокого вкладання (я ненавиджу імена класів, такі як ExtraLongClassNameBecauseEveryThingIsInTheSameNameSpace ... тоді ви також можете розмістити все у глобальному просторі імен.)

Оновлення 3 - Висновок

Більшість кажуть "не робіть цього", але ... навіть підсилення має більш глибоке вкладання, ніж один-два рівні. Так, це бібліотека, але: якщо ви хочете використовувати код багаторазового використання - поводьтесь із власним кодом як з бібліотекою, яку ви надасте комусь іншому. Я також використовую більш глибоке вкладання для цілей виявлення, використовуючи простори імен.

C ++ 17 може спростити визначення вкладеного простору імен:

namespace A::B::C {
}

еквівалентно

namespace A { namespace B { namespace C {
} } }

Див. (8) на сторінці простору імен на cppreference:
http://en.cppreference.com/w/cpp/language/namespace

Щоб уникнути справді глибокого відступу, я зазвичай роблю це так:

namespace A { namespace B { namespace C
{
    class X
    {
        // ...
    };
}}}

Я повністю підтримую відповідь Петерхена, але хочу додати щось, що стосується іншої частини вашого запитання.

Оголошення просторів імен є одним з дуже рідкісних випадків у C ++, коли мені насправді подобається використання #defines.

#define MY_COMPANY_BEGIN  namespace MyCompany { // begin of the MyCompany namespace
#define MY_COMPANY_END    }                     // end of the MyCompany namespace
#define MY_LIBRARY_BEGIN  namespace MyLibrary { // begin of the MyLibrary namespace
#define MY_LIBRARY_END    }                     // end of the MyLibrary namespace

Це також позбавляє потреби в коментарях біля закриваючої фігурної дужки простору імен (Ви коли-небудь прокручували вниз до нижньої частини великого вихідного файлу та намагалися додати / видалити / збалансувати фігурні дужки, у яких бракувало коментарів про те, яка фігурна дужка закриває яку область? Не цікаво .).

MY_COMPANY_BEGIN
MY_LIBRARY_BEGIN

class X { };

class Y { };

MY_LIBRARY_END
MY_COMPANY_END

Якщо ви хочете помістити всі оголошення простору імен в один рядок, ви можете зробити це, а також трохи (досить потворно) магії препроцесора:

// helper macros for variadic macro overloading
#define VA_HELPER_EXPAND(_X)                    _X  // workaround for Visual Studio
#define VA_COUNT_HELPER(_1, _2, _3, _4, _5, _6, _Count, ...) _Count
#define VA_COUNT(...)                           VA_HELPER_EXPAND(VA_COUNT_HELPER(__VA_ARGS__, 6, 5, 4, 3, 2, 1))
#define VA_SELECT_CAT(_Name, _Count, ...)       VA_HELPER_EXPAND(_Name##_Count(__VA_ARGS__))
#define VA_SELECT_HELPER(_Name, _Count, ...)    VA_SELECT_CAT(_Name, _Count, __VA_ARGS__)
#define VA_SELECT(_Name, ...)                   VA_SELECT_HELPER(_Name, VA_COUNT(__VA_ARGS__), __VA_ARGS__)

// overloads for NAMESPACE_BEGIN
#define NAMESPACE_BEGIN_HELPER1(_Ns1)             namespace _Ns1 {
#define NAMESPACE_BEGIN_HELPER2(_Ns1, _Ns2)       namespace _Ns1 { NAMESPACE_BEGIN_HELPER1(_Ns2)
#define NAMESPACE_BEGIN_HELPER3(_Ns1, _Ns2, _Ns3) namespace _Ns1 { NAMESPACE_BEGIN_HELPER2(_Ns2, _Ns3)

// overloads for NAMESPACE_END
#define NAMESPACE_END_HELPER1(_Ns1)               }
#define NAMESPACE_END_HELPER2(_Ns1, _Ns2)         } NAMESPACE_END_HELPER1(_Ns2)
#define NAMESPACE_END_HELPER3(_Ns1, _Ns2, _Ns3)   } NAMESPACE_END_HELPER2(_Ns2, _Ns3)

// final macros
#define NAMESPACE_BEGIN(_Namespace, ...)    VA_SELECT(NAMESPACE_BEGIN_HELPER, _Namespace, __VA_ARGS__)
#define NAMESPACE_END(_Namespace, ...)      VA_SELECT(NAMESPACE_END_HELPER,   _Namespace, __VA_ARGS__)

Тепер ви можете зробити це:

NAMESPACE_BEGIN(Foo, Bar, Baz)

class X { };

NAMESPACE_END(Baz, Bar, Foo) // order doesn't matter, NAMESPACE_END(a, b, c) would work equally well

Foo::Bar::Baz::X x;

Для вкладеності глибше трьох рівнів вам потрібно було б додати допоміжні макроси до бажаної кількості.

Простори імен С ++ використовуються для групування інтерфейсів, а не для розділення компонентів або вираження політичного поділу.

Стандарт намагається заборонити використання просторів імен, подібних до Java. Наприклад, псевдоніми простору імен надають спосіб легко використовувати глибоко вкладені або довгі імена простору імен.

namespace a {
namespace b {
namespace c {}
}
}

namespace nsc = a::b::c;

Але namespace nsc {}тоді це буде помилкою, оскільки простір імен може бути визначений лише за допомогою його оригінального-імені простору імен . По суті, стандарт робить речі простими для користувача такої бібліотеки, але важкими для реалізатора . Це відбиває людей писати подібні речі, але пом'якшує наслідки, якщо вони це роблять.

У вас повинен бути один простір імен на інтерфейс, визначений набором пов’язаних класів та функцій. Внутрішній або необов’язковий підінтерфейси можуть переходити у вкладені простори імен. Але на глибині більше двох рівнів повинен бути дуже серйозний червоний прапор.

Розгляньте можливість використання символів підкреслення та префіксів ідентифікаторів там, де ::оператор не потрібен.

Ні, і будь ласка, не роби цього.

Призначення просторів імен полягає насамперед у вирішенні конфліктів у глобальному просторі імен.

Другорядною метою є місцеве скорочення символів; наприклад, комплексUpdateUI метод може використовувати a using namespace WndUIдля використання коротших символів.

Я працюю над проектом 1.3MLoc, і єдиними просторами імен, які ми маємо, є:

• імпортовані зовнішні бібліотеки COM (головним чином, щоб ізолювати конфлікти заголовків між #import та #include windows.h)
• Один рівень просторів імен "відкритого API" для певних аспектів (інтерфейс, доступ до БД тощо)
• Простори імен "Деталізація реалізації", які не є частиною загальнодоступного API (анонімні простори імен у .cpp, або ModuleDetailHereBeTygersпростори імен у бібліотеках лише для заголовків)
• Переліки - це найбільша проблема на моєму досвіді. Вони забруднюють, як божевільні.
• Я все ще відчуваю, що це занадто багато просторів імен

У цьому проекті назви класів тощо використовують дво- або трибуквенний код "регіону" (наприклад, CDBNodeзамість DB::CNode). Якщо ви віддаєте перевагу останньому, є місце для другого рівня "публічних" просторів імен, але не більше.

До цих класів можуть входити переліки для класів тощо (хоча я згоден, що це не завжди добре, і іноді важко сказати, чи варто це робити)

Також рідко потрібен простір імен "компанія", за винятком випадків, коли у вас є великі проблеми зі сторонніми бібліотеками, які розподіляються у вигляді двійкових файлів, не надають власний простір імен, і їх неможливо легко вкласти в один (наприклад, у двійковій системі) розподіл). Тим не менше, на моєму досвіді примусити їх до простору імен зробити набагато простіше.

[редагувати] Відповідно до подальшого запитання Стегі:

Гаразд, то як щодо Windows :: UI :: Xaml та Windows :: UI :: Xaml :: Controls :: Простіри імен примітивів у розробці Win8? Я думаю, що використання простором імен Microsoft має сенс, і це насправді глибше, ніж просто 2 рівні

Вибачте, якщо я не був достатньо чітким: два рівні - це не жорсткий межа, і більше - це не суттєво погано. Я просто хотів зазначити, що вам рідко потрібно більше двох, з мого досвіду, навіть на великій основі коду. Вкладання глибше або неглибоко - це компроміс.

Зараз випадок з Microsoft може бути іншим. Імовірно, набагато більша команда, і весь код - це бібліотека.

Я припускаю, що Microsoft наслідує тут успіх бібліотеки .NET, де простори імен сприяють виявленню великої бібліотеки. (.NET має близько 18000 типів.)

Далі я б припустив, що в просторі імен є оптимальні (порядок) символи. скажімо, 1 не має сенсу, 100 звучить правильно, 10000 - це явно багато.

TL; DR: Це компроміс, і у нас немає твердих цифр. Грайте безпечно, не перестарайтеся в будь-якому напрямку. "Не робіть цього" походить просто від "У вас з цим проблеми, у мене будуть проблеми з цим, і я не бачу причини, чому б вам це було потрібно".

Ось цитата з документів Lzz (Lazy C ++):

Lzz розпізнає такі конструкції C ++:

визначення простору імен

Неіменований простір імен та всі вкладені декларації виводяться у вихідний файл. Це правило має перевагу над усіма іншими.

Ім'я названого простору імен може бути кваліфікованим.

   namespace A::B { typedef int I; }

еквівалентно:

   namespace A { namespace B { typedef int I; } }

Звичайно, якість джерел, яка залежить від таких інструментів, є спірною ... Я б сказав, це більше цікавість, показуючи, що синтаксична хвороба, індукована C ++, може набувати різної форми (у мене теж є ...)

Обидва стандарти (C ++ 2003 та C ++ 11) дуже чітко визначають, що ім'я простору імен є ідентифікатором. Це означає, що потрібні явно вкладені заголовки.

У мене враження, що це не є великою проблемою, щоб дозволити розміщення кваліфікованого ідентифікатора крім простої назви простору імен, але з якихось причин це заборонено.

Ви можете використовувати цей синтаксис:

namespace MyCompany {
  namespace MyModule {
    namespace MyModulePart //e.g. Input {
      namespace MySubModulePart {
        namespace ... {
          class MyClass;
        }
      }
    }
  }
}

// Here is where the magic happens
class MyCompany::MyModule::MyModulePart::MySubModulePart::MyYouGetTheIdeaModule::MyClass {
    ...
};

Зверніть увагу, що цей синтаксис дійсний навіть у C ++ 98, і він майже подібний до того, що зараз доступний у C ++ 17 із вкладеними визначеннями простору імен .

Щасливого розкладання грошей!

Джерела:

• http://seanmiddleditch.com/unnest-c-namespaces/
• http://www.nuonsoft.com/blog/2017/08/01/c17-nested-namespaces/

Ця стаття досить добре висвітлює тему: Папір простору імен

Що в основному це зводить. Чим довші ваші простори імен, тим більша ймовірність того, що люди збираються використовувати using namespaceдирективу.

Отже, дивлячись на наступний код, ви можете побачити приклад, коли це вам зашкодить:

namespace abc { namespace testing {
    class myClass {};
}}

namespace def { namespace testing {
    class defClass { };
}}

using namespace abc;
//using namespace def;

int main(int, char**) {
    testing::myClass classInit{};
}

Цей код буде скомпільовано чудово, однак, якщо ви прокоментуєте рядок, //using namespace def;тоді простір імен "тестування" стане неоднозначним, і у вас виникнуть колізії імен. Це означає, що ваша кодова база може перейти від стабільної до нестабільної, включивши сторонню бібліотеку.

У C #, навіть якщо ви мали використовувати, using abc;і using def;компілятор може розпізнати це testing::myClassабо навіть просто myClassзнаходиться лише у abc::testingпросторі імен, але C ++ не розпізнає це, і це виявляється як зіткнення.

Так, вам доведеться робити це як

namespace A{ 
namespace B{
namespace C{} 
} 
}

Однак ви намагаєтесь використовувати простори імен таким чином, щоб вони не використовувались. Перевірте це питання, можливо, вам це стане в нагоді.

[EDIT:]
Оскільки c ++ 17 вкладені простори імен підтримуються як стандартна мовна функція ( https://en.wikipedia.org/wiki/C%2B%2B17 ). На сьогодні ця функція не підтримується в g ++ 8, але її можна знайти у компіляторі clang ++ 6.0.

[ВИСНОВОК:]
Використовуйте clang++6.0 -std=c++17як команду компіляції за замовчуванням. Тоді все повинно працювати нормально - і ви зможете компілюватиnamespace OuterNS::InnerNS1::InnerNS2 { ... } файлів.

[ОРИГІНАЛЬНА ВІДПОВІДЬ:]
Оскільки це питання вже застаріле, я припускаю, що Ви пішли далі. Але для інших, хто все ще шукає відповіді, я придумав таку ідею:

(Чи можу я зробити тут рекламу для Emacs :)?) Опублікувати зображення набагато простіше і легше для читання, ніж просто поштовий індекс. Я не маю наміру подавати повноцінний огляд усіх кутових випадків, просто я мав намір надихнутись. (Я повністю підтримую C # і вважаю, що в багатьох випадках C ++ повинен використовувати деякі функції ООП, оскільки C # популярний головним чином завдяки порівнянній простоті використання).