Prawdopodobnie duplikat, ale niełatwy do wyszukania ...

Biorąc pod uwagę nagłówek taki jak:

namespace ns1
{
 class MyClass
 {
  void method();
 };
}

Widziałem method()zdefiniowane na kilka sposobów w pliku .cpp:

Wersja 1:

namespace ns1
{
 void MyClass::method()
 {
  ...
 }
}

Wersja 2:

using namespace ns1;

void MyClass::method()
{
 ...
}

Wersja 3:

void ns1::MyClass::method()
{
 ...
}

Czy istnieje „właściwy” sposób, aby to zrobić? Czy któryś z tych „błędów” nie oznacza tego samego?

Wersja 2 jest niejasna i niełatwa do zrozumienia, ponieważ nie wiesz, do której przestrzeni nazw MyClassnależy i jest po prostu nielogiczna (funkcja klasy nie znajduje się w tej samej przestrzeni nazw?)

Wersja 1 ma rację, ponieważ pokazuje, że w przestrzeni nazw definiujesz funkcję.

Wersja 3 jest słuszna również dlatego, że użyłeś ::operatora rozpoznawania zakresu do odniesienia się do MyClass::method ()w przestrzeni nazw ns1. Wolę wersję 3.

Zobacz przestrzenie nazw (C ++) . To najlepszy sposób, aby to zrobić.

Pięć lat później pomyślałem, że wspomnę o tym, co zarówno ładnie wygląda, jak i nie jest złe

using ns1::MyClass;

void MyClass::method()
{
  // ...
}

Używam wersji 4 (poniżej), ponieważ łączy ona większość zalet wersji 1 (zwięzłość definicji resoekcyjnej) i wersji 3 (maksymalnie wyraźna). Główną wadą jest to, że ludzie nie są do tego przyzwyczajeni, ale ponieważ uważam, że jest to technicznie lepsze od alternatyw, nie mam nic przeciwko.

Wersja 4: użyj pełnej kwalifikacji przy użyciu aliasów przestrzeni nazw:

#include "my-header.hpp"
namespace OI = outer::inner;
void OI::Obj::method() {
    ...
}

W moim świecie często używam aliasów przestrzeni nazw, ponieważ wszystko jest jawnie kwalifikowane - chyba że nie może (np. Nazwy zmiennych) lub jest to znany punkt dostosowywania (np. Swap () w szablonie funkcji).

Wersja 3 sprawia, że ​​powiązanie między klasą a przestrzenią nazw jest bardzo wyraźne, kosztem częstszego pisania. Wersja 1 unika tego, ale przechwytuje powiązanie z blokiem. Wersja 2 ma tendencję do ukrywania tego, więc unikałbym tego.

Przewodnik Google po stylu C ++ dyktuje wersję 1, ale bez wcięć.

Wybieram Num.3 (czyli wersję pełną). Jest to bardziej typowe, ale intencja jest dokładna dla Ciebie i dla kompilatora. Problem, który opublikowałeś w obecnej postaci, jest w rzeczywistości prostszy niż w prawdziwym świecie. W prawdziwym świecie istnieją inne zakresy definicji, a nie tylko członkowie klas. Twoje definicje nie są zbyt skomplikowane w przypadku samych klas - ponieważ ich zakres nigdy nie jest ponownie otwierany (w przeciwieństwie do przestrzeni nazw, zasięgu globalnego itp.).

Num.1 może się to nie powieść w przypadku zakresów innych niż klasy - wszystko, co można ponownie otworzyć. Możesz więc zadeklarować nową funkcję w przestrzeni nazw, używając tego podejścia, lub twoje inline mogą zostać zastąpione przez ODR. Będzie to potrzebne w przypadku niektórych definicji (w szczególności specjalizacji szablonów).

Num.2 Jest to bardzo delikatne, szczególnie w dużych bazach kodu - gdy zmieniają się nagłówki i zależności, twój program nie skompiluje się.

Num.3 Jest to idealne rozwiązanie, ale dużo do pisania - co swoją intencją jest, aby zdefiniować coś . To robi dokładnie to, a kompilator włącza się, aby upewnić się, że nie popełniłeś błędu, definicja nie jest niezgodna z jej deklaracją itp.

Okazuje się, że to nie tylko „kwestia stylu kodowania”. Num. 2 prowadzi do błędu łączenia podczas definiowania i inicjalizacji zmiennej zadeklarowanej extern w pliku nagłówkowym. Spójrz na przykład w moim pytaniu. Definicja stałej w przestrzeni nazw w pliku cpp

Wszystkie drogi są właściwe, a każda ma swoje zalety i wady.

W wersji 1 masz tę zaletę, że nie musisz pisać przestrzeni nazw przed każdą funkcją. Wadą jest to, że otrzymasz nudną identyfikację, szczególnie jeśli masz więcej niż jeden poziom przestrzeni nazw.

W wersji 2 sprawiasz, że kod jest bardziej przejrzysty, ale jeśli masz więcej niż jedną przestrzeń nazw implementowaną w CPP, jedna może mieć bezpośredni dostęp do funkcji i zmiennych drugiej, czyniąc twoją przestrzeń nazw bezużyteczną (dla tego pliku cpp).

W wersji 3 będziesz musiał wpisać więcej, a linie funkcji mogą być większe niż ekran, co jest niekorzystne dla efektów projektowych.

Jest też inny sposób, w jaki niektórzy go używają. Jest podobny do pierwszej wersji, ale bez problemów z identyfikacją.

To jest tak:

#define OPEN_NS1 namespace ns1 { 
#define CLOSE_NS1 }

OPEN_NS1

void MyClass::method()
{
...
}

CLOSE_NS1

Do Ciebie należy wybór, który jest lepszy w każdej sytuacji =]