Przestawiłem się z C ++ na Javę i C # i myślę, że użycie przestrzeni nazw / pakietów jest tam znacznie lepsze (dobrze zorganizowane). Potem wróciłem do C ++ i próbowałem użyć przestrzeni nazw w ten sam sposób, ale wymagana składnia jest okropna w pliku nagłówkowym.

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

Poniższe zdanie wydaje mi się dziwne (aby uniknąć głębokiego wcięcia):

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

Czy istnieje krótszy sposób wyrażenia powyższej rzeczy? Brakuje mi czegoś takiego

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

Aktualizacja

Ok, niektórzy twierdzą, że koncepcja użycia w Javie / C # i C ++ jest inna. Naprawdę? Myślę, że (dynamiczne) ładowanie klas nie jest jedynym celem przestrzeni nazw (jest to bardzo techniczna perspektywa). Dlaczego nie powinienem go używać do czytelności i strukturyzacji, np. „IntelliSense”.

Obecnie nie ma logiki / kleju między przestrzenią nazw a tym, co można tam znaleźć. Java i C # robią to znacznie lepiej ... Dlaczego w tym<iostream> i posiadający przestrzeń nazwstd? Ok, jeśli powiesz, że logika powinna polegać na nagłówku, dlaczego #include nie używa przyjaznej składni „IntelliSense”, takiej jak#include <std::io::stream> lub<std/io/stream>? Myślę, że brakująca struktura w domyślnych bibliotekach to jedna słabość C ++ w porównaniu do Java / C #.

Jeśli wyjątkowość gorących konfliktów to jeden punkt (który jest także punktem C # i Javy), dobrym pomysłem jest użycie nazwy projektu lub nazwy firmy jako przestrzeni nazw, nie uważasz?

Z jednej strony mówi się, że C ++ jest najbardziej elastyczny ... ale wszyscy powiedzieli „nie rób tego”? Wydaje mi się, że C ++ może robić wiele rzeczy, ale ma okropną składnię nawet dla najłatwiejszych rzeczy w wielu przypadkach w porównaniu z C #.

Aktualizacja 2

Większość użytkowników twierdzi, że tworzenie głębszego zagnieżdżenia niż dwa poziomy jest nonsensem. Ok, więc co z obszarem nazw Windows :: UI :: Xaml i Windows :: UI :: Xaml :: Controls :: Primitives w rozwoju Win8? Myślę, że użycie przestrzeni nazw przez Microsoft ma sens i jest rzeczywiście głębsze niż tylko 2 poziomy. Myślę, że większe biblioteki / projekty wymagają głębszego zagnieżdżenia (nienawidzę nazw klas, takich jak ExtraLongClassNameBecauseEveryThingIsInTheSameNameSpace ... wtedy możesz umieścić wszystko w globalnej przestrzeni nazw.)

Aktualizacja 3 - Wnioski

Większość mówi „nie rób tego”, ale… nawet doładowanie ma głębsze zagnieżdżanie niż jeden lub dwa poziomy. Tak, to jest biblioteka, ale: Jeśli chcesz kod wielokrotnego użytku - traktuj swój kod jak bibliotekę, którą dasz komuś innemu. Używam także głębszego zagnieżdżania dla celów odkrywania przy użyciu przestrzeni nazw.