ich habe eine Struktur namens Settings in der alle Programmeinstellungen beim Start eingelesen werden. Die Settings stehen in einer Ini-Datei. Geparst wird das ganze mit boost::spirit.

Jetzt benötigen jedoch andere Klassen auch die Daten aus der Ini-Datei. Derzeit läuft das bei mir so das ich immer einen Pointer der Settings Struktur durch schleife. Nun meine Frage macht das sinn sowas zu globalisieren, oder immer wieder übergeben, oder einfach neu initialisieren.

Übergeben:
übergeben ist glaube ich der sauberste weg, was mir nicht gefällt wenn zum Beispiel ein Klassenauf stattfindet: A -> B -> C
Klasse A ruft B auf und die wiederum C Wenn Klasse A und B die Settings Struktur nicht benötigt, jedoch Klasse C muss ich das kommplett durch schleifen, was ein wenig nervig ist.

Neu initialisieren:
Das Problem was ich da sehe ist das die Ini-Datei immer neu geparst werden muss, nun weiß ich nicht ob das Kritisch ist oder ein Flaschenhals werden könnte. Natürlich kommt es immer auf die Größe der Datei an und wie diese geparst wird. Ist sowas sinnvoll

Globalisierung:
Überall liest man das dies schlecht ist, jedoch ist es in meinem Fall Erleichterung

Habt Ihr eventuell eine Idee?

Anbei mal so eine Ini-Datei und die Struktur damit man sich mal ein Bild machen kann.

config.ini

[global]
log_path_error=/var/log/g5server/error.log
log_level=3
running_mode=daemon

[database]
hostname=localhost
username=test
password=123
dbname=test

Struktur:

typedef struct {
    std::string running_mode;
    std::string log_path_error;
    int log_level;
} server_configuration;

Zudem noch ein paar Fragen zu deinem Text:

jd schrieb:

übergeben ist glaube ich der sauberste weg, was mir nicht gefällt wenn zum Beispiel ein Klassenauf stattfindet: A -> B -> C
Klasse A ruft B auf und die wiederum C Wenn Klasse A und B die Settings Struktur nicht benötigt, jedoch Klasse C muss ich das kommplett durch schleifen, was ein wenig nervig ist.

Wie rufen sich Klassen auf? Ich kann also nicht nachvollziehen, wie oder was du hier nervig findest, da es gar nicht möglich ist.

jd schrieb:

Überall liest man das dies schlecht ist, jedoch ist es in meinem Fall Erleichterung

Bis du anfängst zu Debuggen oder das Projekt warten musst. Die einzige Erleichterung, welche du wahrscheinlich hast, ist in deiner Schreibfaulheit zu finden. Schreibfaulheit sollte aber nicht das Programmdesign beeinflussen

jd schrieb:

typedef struct {
    std::string running_mode;
    std::string log_path_error;
    int log_level;
} server_configuration;

In C++ kann man direkt schreiben:

struct server_configuration {
    std::string running_mode;
    std::string log_path_error;
    int log_level;
};

struct und class sind in C++ äquivalent. struct ist einfach nur per default public und class per default private .
Und noch eine Anmerkung zu diesem struct . Öffentliche Attribute sind eine GANZ SCHLECHTE Idee ausser in wenigen Ausnahmen. Dadurch geht die ganze Kapselung und somit jegliches OOP verloren.

Grüssli

danke erstmal für eine fixe Antwort. Erstmal etwas zu dem Projekt es ist eine TCP-Server Applikation, die Kommunikation läuft via XML ab, Das Programm kann mehere Clients zu lassen etc. Hier mal ein bleispiel:

class A
{
	public:
		A(server_settings* settings) {}
		void god_mode() { b.get_request(); }
	private:
		server_settings* settings_;
		B b_;
}

class B
{
	public:
		void get_request() { c.handle_request(); }
	private:
		C c_;
}

class C
{
	public:
		C() {}
		C(server_settings* settings) {}
		void handle_request() {}
	private:
		server_settings* settings_;
}

int main()
{
	server_settings settings = server_settings::parse_config("config.ini");
	A a(&settings);
	return 0;
}

Wenn ich nun server_settings in der Klasse C haben will, muss es Klasse B auch haben, damit ich das durch schleifen kann, oder ich initialisiere die Struktur neu und somit wird die config file auch neu geparst was ich eigentlich nicht will.

Mir kommt das irgendwie unüberlegt vor wenn die Struktur immer mit schleife, eventuell irre ich mich auch.

Würde mir das Singleton-Pattern helfen? Wenn es nur eine Instanz im Programmablauf geben darf und ich diese mit new auf den Heap schmeiße, sollte quasi die Config nur einmal geparst werden. Somit brauche ich 1. nicht durch schleifen und 2. Kann einfach mir die Vorhandene Instanz in der Klasse, wo ich es benötige hohlen. Wäre das eine vertretbare Option?

Dravere schrieb:

struct und class sind in C++ äquivalent. struct ist einfach nur per default public und class per default private .
Und noch eine Anmerkung zu diesem struct . Öffentliche Attribute sind eine GANZ SCHLECHTE Idee ausser in wenigen Ausnahmen. Dadurch geht die ganze Kapselung und somit jegliches OOP verloren.

Das habe ich auch noch vor das einmal zu überdenken und zu überarbeiten

so long
jd

Wenn ich nun server_settings in der Klasse C haben will, muss es Klasse B auch haben, damit ich das durch schleifen kann, oder ich initialisiere die Struktur neu und somit wird die config file auch neu geparst was ich eigentlich nicht will.

Mir kommt das irgendwie unüberlegt vor wenn die Struktur immer mit schleife, eventuell irre ich mich auch.

Du brauchst server_settings ja in B nicht zu speichern. Eine Parameterübergabe im Konstruktor reicht.

A::A(server_settings* settings)
: settings_(settings)
, b_(settings)
{
}

B::B(server_settings* settings)
: c_(settings)
{
}

C::C(server_settings* settings)
: settings_(settings)
{
}

jd schrieb:

Würde mir das Singleton-Pattern helfen? Wenn es nur eine Instanz im Programmablauf geben darf und ich diese mit new auf den Heap schmeiße, sollte quasi die Config nur einmal geparst werden. Somit brauche ich 1. nicht durch schleifen und 2. Kann einfach mir die Vorhandene Instanz in der Klasse, wo ich es benötige hohlen. Wäre das eine vertretbare Option?

Grundsätzlich ist das eine Möglichkeit, allerdings ist ein Singleton nur eine objektorientierte globale Variable und bringt einige Probleme mit sich (beispielsweise, wenn es um Zerstörung bei Abhängigkeiten zu anderen Klassen geht). In deinem Beispiel ist es ja wirklich kein Problem, die Variable mitzutragen. Nur deswegen würde ich die Nachteile von Singletons nicht in Kauf nehmen wollen.