2012-12-28 17 views
5

Po pierwsze, przepraszam za mój angielski.Połączyć dwie lub więcej przestrzeni nazw C++ w jedną

Ok, pracuję program, który wykonuje określony proces. Ten proces wymaga zdefiniowania niektórych klas i funkcji. Wszystkie muszą być zorganizowane w bloki, aby uzyskać do nich dostęp.

Mój pierwszy pomysł był do pracy z przestrzeniami nazw (C++), aby uzyskać coś takiego:

namespace LoadSystem 
{ 
    namespace ParseBlock1 
    { 
     class ClassA {...} 
     class ClassB {...} 
     class ClassC {...} 
    } 
    namespace ParseBlock2 
    { 
     class ClassA {...} 
     class ClassB {...} 
     class ClassC {...} 
    } 
} 

Tak, czytałem, aby uzyskać najlepszy pomysł, czy to jest dobre czy nie. Już przeczytałem, że nie mogę używać wielu zagnieżdżonych przestrzeni nazw, więc dla mojego celu minimalne poziomy to dwa, jak pokazano powyżej.

Moim celem jest możliwość dodawania kolejnych ParseBlocks do przestrzeni nazw . Będzie przechowywany w jednym pliku .h, więc będą tylko interfejsy klas. Ponieważ w jednym bloku może być wiele klas, chcę podzielić definicję każdego bloku na inne pliki .h, aby główny plik .h był mały.

Więc skończyło się od pomysłu definiowania plikowi block1.h i block2.h, każdy z konstrukcji takiego:

namespace LoadSystem 
{ 
    namespace ParseBlock1 
    { 
     class ClassA {...} 
     class ClassB {...} 
     class ClassC {...} 
    } 
} 

i

namespace LoadSystem 
{ 
    namespace ParseBlock2 
    { 
     class ClassA {...} 
     class ClassB {...} 
     class ClassC {...} 
    } 
} 

i zaimportować je w pliku load_system.h. Tak więc, za każdym razem, gdy muszę dodać kolejny blok, piszę potrzebne pliki, a na końcu, po prostu zaimportuję nowy blockX.h do głównego load_system.h.

Następnie muszę mieć dostęp do obu bloków z tej samej przestrzeni nazw za pomocą LoadSystem::ParseBlock1::Class1 lub LoadSystem::ParseBlock2::Class1.

Testowałem to z prostymi wartościami całkowitymi i to działa. Przestrzenie nazw łączą się i mogę uzyskać dostęp do wartości bez żadnego ostrzeżenia (użyłem gcc -Wall -Werror -Wextra -pedantic).

Czy ta kombinacja przestrzeni nazw jest poprawna, czy nie. Może to działa, ale może nie powinienem tego używać, nie wiem.

Również, chcę wiedzieć, czy ten proces importowania „master” nagłówka pliku (który importuje inne pliki nagłówka) jest poprawne, czy nie (używam potrzebne #ifndef, #define i #endif makr strzec od wiele importów), używam czegoś takiego:

# ifndef LOAD_SYSTEM_H_ 
# define LOAD_SYSTEM_H_ 

# include "block1/block1.h" 
# include "block2/block2.h" 

# endif 

Proszę, pomóż mi, jeśli to prawda, czy nie.

Dzięki za wszystko.

+2

O ile wiem, jest to całkowicie poprawny sposób korzystania z przestrzeni nazw. Możesz mieć wiele z nich i używać ich równolegle, bez problemu. (Nie wiem, czy naprawdę potrzebujesz tych wszystkich przestrzeni nazw, trudno powiedzieć bez zrozumienia, co robią wszystkie klasy i jak są one używane.) – jogojapan

+1

Twój angielski jest bardzo dobry. Wprowadziłem drobne poprawki, aby poprawić płynność i formatowanie. – wallyk

+0

jogojapan: Dzięki, w końcu (czytając odpowiedzi) rozumiem, że ten proces "łączenia" nie jest błędem. Dzięki. Tapetyk: Cóż, projekt określa pewną logiczną architekturę, więc myślę, że muszę spróbować przedstawić tę architekturę na kodzie: P, ale czytając odpowiedzi tutaj i myśląc bardziej o sytuacji i naturze przestrzeni nazw, myślę, że ja będzie zarządzać tylko jednym poziomem: P (nazwa programu, coś jak MySystem :: Class1, MySystem :: Class2, etc). –

Odpowiedz

2

Zawsze można rozszerzyć istniejący obszar nazw, aby część była w porządku.

Ta część jest jedyną, która ma prostą techniczną odpowiedź.

Jeśli chodzi o "główny plik nagłówkowy", jest bardziej subiektywny, a to kwestia osobistych preferencji. Wolę, aby dołączone nagłówki mogły być dołączone osobno bez żadnych wymagań wstępnych (takich jak przedkładanie innych rzeczy przed nimi).Jeśli tak, to wszystko jest w porządku dla mnie, ale jeśli nie, to użytkownicy twojego kodu będą musieli w praktyce zawierać duży plik nagłówka, aby uzyskać trochę mniejszy nagłówek, co może negatywnie wpłynąć na czas budowy (a jeśli nie 't, ale same zawierają wymagania wstępne, a następnie mają kruchy kod, który może przestać działać po aktualizacji nagłówka).

+0

Wielkie dzięki za odpowiedź. Jak już wspomniałem powyżej, spróbuję teraz pracować tylko z jednym poziomem przestrzeni nazw (nazwą programu). I tak, rozumiem, że importowanie wielu nagłówków do pliku kodu wpływa na czas kompilacji, a także, być może, na rozmiar binarny. Tak więc spróbuję pracować z bezpośrednimi wywołaniami importu (import plików klas zamiast głównego pliku nagłówkowego). Dzięki za pomoc: D –

Powiązane problemy