[C++] Wozu ist ein "unnamed" namespace gut?

Werbeanzeige

.:!Batzer!:.

Alter Hase

Beiträge: 610

04.01.2012, 22:34

[C++] Wozu ist ein "unnamed" namespace gut?

Hey Leute,

ich bin vor kurzem über das Konzept des "unnamed" namespaces gestolpert.
In dem Code, in dem ich es gesehen habe, wurden Funktionen in der *.cpp Datei definiert und in Methoden
einer Klasse verwendet. Nun ist die Frage warum man da nicht einfach eine private Methode gemacht hat.
Gibt es einen bestimmten Vorteil bei diesem Ansatz?

Ich hoffe die Frage ist nicht zu trivial

Danke

Zum Seitenanfang

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

04.01.2012, 22:38

Dinge in einem unnamed namespace haben internal linkage, d.h. sie sind von anderen .cpp Files aus nicht sichtbar. Wenn z.B. in zwei .cpp Files gleichnamige Funktionen definiert sind:

	C-/C++-Quelltext
1 2 3 4 5 6 7 8 9 10 11 12 13 14	// A.cpp void blub() { std::cout << "blub A" << std::endl; } // B.cpp void blub() { std::cout << "blub B" << std::endl; }

Dann gäbe das einen Linkerfehler von wegen blub already defined in A.obj.

	C-/C++-Quelltext
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	// A.cpp namespace { void blub() { std::cout << "blub A" << std::endl; } } // B.cpp void blub() { std::cout << "blub B" << std::endl; }

Funktioniert dagegen problemlos, die Funktion blub() in A.cpp kann dafür aber auch nur in A.cpp aufgerufen werden.

Falls es dir mal unterkommen sollte: In C löst man das mit dem Schlüsselwort static:

	C-/C++-Quelltext
1 2 3 4 5 6 7 8 9 10 11 12 13	// A.c static void blub() { std::cout << "blub A" << std::endl; } // B.c void blub() { std::cout << "blub B" << std::endl; }

C++ unterstützt das momentan auch noch, diese Verwendung von static ist dort aber deprecated und man sollte stattdessen unnamed namespaces verwenden.

m4studios

Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »dot« (04.01.2012, 23:00)

Zum Seitenanfang

.:!Batzer!:.

Alter Hase

Beiträge: 610

04.01.2012, 22:43

Danke für die Erklärung

Aber wozu eine Methode blub() private deklarieren, wenn man einfach alle privaten Methoden in einen unnamed namespace verpacken kann?
Vorausgesetzt, dass die Funktionen auf keine privaten Member zugreifen müssen.