Soll ich überall std :: und boost :: verwenden?

7

In meinem C ++ - Code verwende ich nicht die Deklarationen using namespace std; oder using namespace boost; . Das macht meinen Code länger und bedeutet mehr Tipparbeit. Ich habe darüber nachgedacht, die "using" -Deklarationen zu verwenden, aber ich erinnere mich an einige Leute, die dagegen argumentierten. Was ist die empfohlene Praxis? Standard und Boost sind so üblich, dass es nicht viel schaden sollte?

    
quant_dev 12.07.2009, 09:27
quelle

7 Antworten

16

Ich verwende using namespace nur in C ++ - Dateien, nicht in Headern. Außerdem wird der Loch-Namespace in den meisten Fällen nicht benötigt. Zum Beispiel könnten Sie using boost::shared_ptr oder using std::tr1::shared_ptr schreiben, um einfach zwischen shared_ptr Implementierungen zu wechseln.

Beispiel:

%Vor%     
Kirill V. Lyadvinsky 12.07.2009, 09:36
quelle
15

Using namespace ... wurde nicht nur zum Spaß erfunden.

Wenn Sie einen guten Grund haben, es zu benutzen, dann tun Sie es (und der häufige Gebrauch von Sachen aus diesen Namensräumen ist der genaue gute Grund). Höre nicht auf Fanatiker, die dir sagen, dass alles, was sie aus dunklen Gründen nicht tun wollen, selbst böse ist.

Eine gute Argumentationsquelle ist C ++ FAQ Lite: Ссылка

Ich habe es gelesen und entschied mich trotzdem dafür, es so zu benutzen, wie du es willst. Jetzt können Sie Ihre eigene informierte Entscheidung treffen: -)

    
ypnos 12.07.2009 09:31
quelle
6

Meine eigenen Regeln sind:

  • in Headerdateien sind alle Namen explizit qualifiziert, z. std::string , std::cout usw. an ihrem Verwendungsort
  • in Quelldateien, setzen Sie using Klauseln für die häufig verwendeten Namen am Anfang der Datei z. mit std::string;
  • Verwenden Sie niemals using namespace xxxx; im Produktionscode.
anon 12.07.2009 10:02
quelle
4

Die Tatsache, dass der Code mit :: std :: prefixes überladen ist, ist beim Lesen des Codes tatsächlich ärgerlich. Sie möchten jedoch wissen, in welchem ​​Namensraum ein Symbol so einfach wie möglich war ...

Nun, ist das nicht der Job der IDE?

Solange meine IDE keine 'kurzen Dateinamen anzeigen' unterstützt, lehne ich% code% Deklarationen für allgemein bekannte Symbole an (d. h. die STL, boost, ...). Lesbarkeit zuerst!

    
xtofl 12.07.2009 09:35
quelle
4

Ein Faktor, den Sie beachten sollten, ist, dass der Namensraum std so benannt ist, um ihn kurz zu machen. Ein std:: Präfix ist nur 5 Zeichen, kaum das Ende der Welt. Anders als .NET Namespaces wie System.Collections.Generic . Es ist so konzipiert, dass es einfach zu tippen ist.

Aus diesem Grund gebe ich normalerweise nur das Präfix std ein. Boost ist auch nicht schlecht, also tippe ich das normalerweise auch aus.

Ich nenne die Sub-Namespaces ( boost::filesystem zum Beispiel) normalerweise etwas kürzer ( namespace fs = boost::filesystem zum Beispiel)

Die Verwendung von typedefs hilft auch sehr. Und wenn ich oft auf einen Typ verweisen muss, füge ich einfach einen using hinzu.

Aber ich versuche generell, using in den Headern zu vermeiden, und wenn ich sie verwende, ziehe ich es vor, sie in den Funktionsumfang zu legen, um den tatsächlichen Namespace nicht zu verschmutzen.

C ++ bietet viele Tools, mit denen Sie den Namespace nicht angeben müssen, ohne den globalen Namespace zu verschmutzen.

    
jalf 12.07.2009 12:20
quelle
1

In Header-Dateien, ja. Das liegt daran, dass "using std :: name_of_std_member;" oder mit "using namespace std;" in einer Header-Datei bewirkt, dass alle anderen Dateien, die diese Header-Datei enthalten, das Symbol im globalen Gültigkeitsbereich sehen und somit den Zweck von Namespaces vereiteln. In Quelldateien ist es jedoch vollkommen in Ordnung, "using namespace std;" um die Symbole dieses Namensraums mit dem Präfix "std ::" verfügbar zu machen.

    
Michael Aaron Safyan 12.07.2009 19:05
quelle
0

Ich verwende using namespace nur innerhalb von Funktionskörpern . In Header-Dateien qualifiziere ich den Namespace immer explizit.

Selten (wenn ich den Code eines Kollegen kopieren möchte), verwende ich using namespace im Namensraumbereich (dh für die gesamte Übersetzungseinheit).

    
Alexandre C. 03.02.2011 20:34
quelle

Tags und Links