Im Moment beschäftige ich mich ein bisschen mit Namespaces, wie ich gelesen habe ein tolles Mittel um Variablen und Funktionen zu gruppieren. Leider bin ich hier auf einige Probleme gestoßen, für die ich keine Lösungen finde (möglicherweise bin ich auch nur zu dumm die richtigen Suchbegriffe in google einzugeben). (Ich benutze VS2008, nur für den Fall, dass das einen Unterschied machen könnte.)

Mein erstes Problem ist das anlegen des Namespace, mit Variablen und Funktionen auf die man von überall her zugreifen können soll:
Zunächst habe ich die names.h in der ich meine namespaces sammeln will

//names.h
namespace Func
{
	std::string filename = "Ini";
		int add(int a, int b)
	{
		return a+b;
	}
}

Lege ich den Namespace Func so an bekomme ich einen Linkerfehler (error LNK2005: "int __cdecl Func::add(int,int)" (?add@Func@@YAHHH@Z) already defined in main.obj), sobald ich names.h an mehreren Stellen im Code includiere. Soblad ich aber den Namespace Func als Unter-Namespace zu einem unbenannten Namespace defniniere geht es:

//names.h
namespace
{
	namespace Func
	{
		std::string filename = "Ini";

		int add(int a, int b)
		{
			return a+b;
		}
	}
}

Ist das so gedacht, oder gibt es hierfür einen "richtigen" Weg um einen global zugreifbaren namespace zu erstellen?

Das zweite Problem ist, dass scheinbar pro Klasse in die ich die names.h inlcudiere eine eigene Instanz des namespace Func habe. Sprich mache ich in Klasse A eine Änderung an Func::filename könnte ich diese Änderung in Klasse B Func::filename nicht ablesen. Func::filename auf static zu setzen ändert leider auch nichts an diesem Verhalten.

Was mache ich da falsch? Beim Namespace std funktionieren solche Sachen ja auch ohne Probleme.

Mit dem anonymen Namespace hast du nur die Symptome beseitigt, nicht das grundlegende Problem.

Deine Probleme haben nichts mit Namespaces zu tun, du machst grundlegende Fehler mit Headern:
1. Du hast keine Includeguards

Doch, hab ich. Hab sie nur der Übersichtlichkeit halber weg gelassen. Die ganze datei sieht so aus:

#ifndef CONF
#define CONF

#include <string>

namespace
{
	namespace Func
	{
		std::string filename = "Ini";

		int add(int a, int b)
		{
			return a+b;
		}
	}
}
#endif

Ich hatte sie am Anfang nicht drin, aber sie rein zu machen hat leider nichts geändert (was der Hauptgrund war warum ich sie nicht mit rein genommen habe, weil es scheinbar am Ergebnis nichts geändert hat)

SeppJ schrieb:

2. Du hast Definitionen von nicht-inline Funktionen und Variablen im Header.

Mit dem anonymen Namespace hast du nur die Symptome beseitigt, nicht das grundlegende Problem.

Ok, da muss ich zugeben, dass ich nicht genau weiss was du damit meinst, bzw. inwiefern das zu Problemen führt.

Daher: In Header gehören nur Deklarationen (außer du machst alles inline, aber mach das nicht ohne genau zu wissen, was das bedeutet und warum das funktioniert!). Also

extern std::string filename;
int add(int a, int b);

Und dann machst du noch eine cpp-Datei mit den tatsächlichen Definitionen dazu. Und das hat alles nichts mit Namespaces zu tun, sondern sind Grundlagen der Modularisierung von Programmen. Namespaces darfst du natürlich trotzdem gerne verwenden.

Außerdem solltest du noch überlegen, ob globale Variablen wirklich sinnvoll sind (in der Regel sind sie das nicht) und ob du wirklich eine Funktion zum Addieren von zwei Zahlen brauchst. Kleiner Tipp: Die gibt es schon in der Standardbibliothek und nennt sich + .

Ja, globale Variable sind selten sinnvoll, da hast du schon recht. Nur habe ich gelesen, dass man auf diese Weise heutzutage Kostanten setzt (z.B. für festgelegte Farbdefinitionen, die überall gleich sein sollen). Meine Idee war auch das ganze als Träger einer beim Programmstart ausgelesenen Config zu machen, aber ich denke dafür nehm ich doch besser eine Klasse.

Das mit dem add war auch nur ein einfaches Beispiel. Bevor ich solche Sachen in richtigen Programmen benutze teste ich das gern in (für sich genommen) unsinnigen Testprogrammen. Normalerweise bin ich nicht so massochistisch veranlagt, dass ich die Addition zweier Ganzzahlen reimplementieren muss.

Vielen Dank auf jeden Fall für die Hilfe.

Nur habe ich gelesen, dass man auf diese Weise heutzutage Kostanten setzt

Definitiv nicht
Man macht auch heut nur Dinge global, die frueher auch schon global waren.
Also Dinge die nur einmalig im Programm vorkommen koennen Und wo das durchschleifen durch die Komplette Objecthirarchie die Funktions / Construktor Aufrufe zum Alptraum werden lassen.
Nur dann !!!

Nen Makro ist immerhin auch sowas wie Global ! (falls du das meinst mit Konstanten ersetzen)

Und dann versteckt man die globalen Obkekte ganz gerne hinter einem Namensraum, richtig, aber meist zu der klasse, wo die syntaktisch hingehoeren.

Fuer deinen Fall, schau dir das Singleton Muster an. Glaub das ist sowas wie du suchst. Und ja am ende ists auch (ne gut versteckte) globale Variable.

Ciao ...

Fuer deinen Fall, schau dir das Singleton Muster an. Glaub das ist sowas wie du suchst. Und ja am ende ists auch (ne gut versteckte) globale Variable.

Äh, meinst du jetzt als träger globaler Konstanter oder als Träger der Config-Daten?