namespaces in java-packages-stiel

[Simon2]

Hi Peter,

Du kannst namespaces ebenso zum "Ordnen" verwenden wie packages in Java. Aber es gibt keine "namespace-Zugriffsklasse", d.h. um den Zugriff (private, public, protected) muss sich jede Klasse selbst kümmern.

Gruß,

Simon2.

[Artchi]

Diese Aufteilung wie in Java gibt es in C++ nicht. Packages haben auch pysikalische Auswirkungen (Package A.B gehört in Verzeichnis A/B), und die hast du in C++ nicht.

In C++ ist es üblich einen Namespace für eine Anwendung oder eine Library zu haben. In Java wird dagegen alles in hunderte verschiedene Packages verteilt. Macht niemand in C++. Schon allein deshalb, weil die IDEs einen nicht dabei unterstützen.

Wenn ich eine Library entwickle, die z.B. Raytracing macht. Dann habe ich dafür meistens einen Namespace - fertig. DIe C++-Standardlibrary ist z.B. in einem einzigen Namespace "std". Wenn du diverse GUI-Library benutzt, sind die gesamten Klassen auch nur in einem Namespace (z.B. sind alle FLTK-Klassen im Namespace "fltk").

[and i don't know if ...]

Eigentlich sind namespace und package sehr unterschiedlich. einmal die verzeichnis sache, dann gibt es sowas wie "namespace private" also "package private" auch nicht und in c++ musst du immer den namespace angeben oder mit using in java bruachst du nur das import was ich mit dem c++ include vergleichen würde.

[thordk]

java braucht halt keine "includes", weil das package system sich um alles kümmert. namespaces in c++ ersetzen keine packages. der zugriff gestaltet sich ähnlich, man benötigt entweder den qualifizierten namen einer klasse, um sie verwenden zu können (package.klasse vs. namespace::klasse) oder muss den "namensraum" für den aktuellen scope zugänglich machen (import package.* vs using namespace namespace).
in c++ kann die using declaration allerdings in jedem block, für diesen block, geschehen.

man kann namespaces ähnlich wie packages verwenden, ist allerdings nicht üblich. während es in java als "nicht empfehlenswert" gilt, klassen in das globale package zu schubsen, ist das in c++ für stand-alone projekte sehr üblich.

[linu*x*bie]

Vielen Dank für die zahlreichen Antworten

gut zu wissen, ich hatte schon vorgehabt ein Projekt auf unzählige namespaces und sub-namespaces aufzuteilen

noch eine syntaktische Frage:
In dem von mir o.g. Beispiel sind also Klasse A und B im gleichen namespace "test", richtig? Mich verwirren hierbei die "umschliessenden Klammern". Es sieht dabei so aus, als ob in dem namespace nur das enthalten ist, was in den Klammern eingeschlossen ist. In dem o.g. Beispiel gibts ein "namespace test-Klammerpaar" sowohl in der A.h und der B.h. Ist es der gleiche namespace ?

Gruss

[finix]

linu(x)bie schrieb:

noch eine syntaktische Frage:
In dem von mir o.g. Beispiel sind also Klasse A und B im gleichen namespace "test", richtig? Mich verwirren hierbei die "umschliessenden Klammern". Es sieht dabei so aus, als ob in dem namespace nur das enthalten ist, was in den Klammern eingeschlossen ist. In dem o.g. Beispiel gibts ein "namespace test-Klammerpaar" sowohl in der A.h und der B.h. Ist es der gleiche namespace ?

Ja, natürlich.

Noch ein Unterschied zu Java-Packages: in C++ sind Namespaces tatsächlich hierarchisch.

[linu*x*bie]

Danke

finix schrieb:

Noch ein Unterschied zu Java-Packages: in C++ sind Namespaces tatsächlich hierarchisch.

ähm... was heißt das bitte? In java sind doch packages auch hierarchisch. Dabei geht es aus vom Defaultpackage als Wurzel bis zu den einzellnen subpackages, welche keine weiteren enthalten. Das sind die Blätter. Oder was meinst Du?

[finix]

linu(x)bie schrieb:

Danke

finix schrieb:

Noch ein Unterschied zu Java-Packages: in C++ sind Namespaces tatsächlich hierarchisch.

ähm... was heißt das bitte? In java sind doch packages auch hierarchisch. Dabei geht es aus vom Defaultpackage als Wurzel bis zu den einzellnen subpackages, welche keine weiteren enthalten. Das sind die Blätter. Oder was meinst Du?

Soweit ich informiert bin sind die Punkte in package -Bezeichnern lediglich Konvention.
Im Gegensatz dazu befindet sich hier

namespace javax {
namespace swing {
//...
}
}

// edit:
using namespace javax;
swing::foo bar; // gueltiges C++

das Package "swing" tatsächlich in "javax".

[linu*x*bie]

hmm... glaube das ist in dieser hinsicht auch hierarchisch. Der pkt ist keine Konvention, sonder hat sogar eine physikalische Auswirkung. Demmnach ist javax ein Verzeichnis und swing ein Unterverzeichniss (im Dateisystem).
Konstrukte wie:

import javax.*;

sind möglich. Dies includiert alles im Verzeichnis javax/ bis auf den Inhalt von Unterverzeichnissen. (Vergleichbar mit der using-Direktive in C++).

gruß

[Artchi]

Nein, die Punkte im Java-Package sind nicht eine Konvention, sondern repräsentieren technisch ein Verzeichnis oder Datei.

java.util zwingt zu java/util
java.util.String zwingt zu java/util/String.java

In C++ sind Namepaces (wie gesagt) technisch ganz anders. Auch sind sie im Unterschied zu Packages "offen". Man kann Namespaces überall definieren und auch ergänzen. Die geschweiften Klammern sind einfach der Sichtbarkeitsbereich (Scope).

Beispiel:

// in x.hpp

namespace hallo
{
    class A
    {};
}

Und:

// in y.hpp

namespace hallo
{
    class B
    {};
}

D.h. Namespaces sind offen, da sie überall zus. Typen aufnehmen können. Also am Ende hat Namespace hallo Klasse A und B.

[linu*x*bie]

Aaah...

Gutes Beispiel.

Danke

[Antwort schreiben]

Artchi schrieb:

Nein, die Punkte im Java-Package sind nicht eine Konvention, sondern repräsentieren technisch ein Verzeichnis oder Datei.

java.util zwingt zu java/util
java.util.String zwingt zu java/util/String.java

hallo,
das ist quatsch, packages sind nicht hierarchisch und sind auch nicht zwingend durch unterordner im dateisystem definiert.

[SideWinder]

Ob die in Unterordnern sein müssen weiß ich nicht, allerdings ist es so, dass ansonsten kaum eine Entwicklungsumgebung damit zurecht kommt. Scheint also zumindest Usus zu sein.

Interessanter ist allerdings deine andere Behauptung. Meiner Meinung nach sind Packages schon hierachisch. Es ist zwar nicht der Fall, dass Sub-Packages autom. Zugriff auf ihre Super-Packages haben oder umgekehrt, aber zumindest gliedern sich die Klassen in ein hierachisches Konzept.

MfG SideWinder

[Antwort schreiben]

SideWinder schrieb:

Interessanter ist allerdings deine andere Behauptung. Meiner Meinung nach sind Packages schon hierachisch. Es ist zwar nicht der Fall, dass Sub-Packages autom. Zugriff auf ihre Super-Packages haben oder umgekehrt, aber zumindest gliedern sich die Klassen in ein hierachisches Konzept.

inwiefern "gliedern sie sich in ein hierarchisches konzept" ?
das package a.b hat nix mit dem package a oder dem package a.b.c zu tun