ich schreibe hier gerade eine klasse die 2 const member hat

bei dem einen konstruktor werden diese beiden als parameter direkt übergeben und dann per initialisierungs liste gesetzt

bei dem anderen Ctor allerdings werden diese beiden werte erst aus einer datei gelesen...

problem also: VC++ meckert dass man die beiden const member nicht per initliste initialisiert und danach kann ich sie ja nicht mehr ändern

mein ansatz:
entweder per schmutzigem trick das const ind em fall umgehen
oder (aber ich glaube nicht dass es klappt) man erzeugt ein temporäres objekt dieser klasse mit den ausgelesenen werten und belegt das eigendliche objekt mit dem temp objekt
da wäre noch zu zusagen dass es keinen copy Ctor und keine zuweisungsoperator gibt weil es für das anwendungs gebiet etwas schwachsinnig ist

was kann ich machen?
und wie?

Oder täusche ich mich da?

Nachtrag: Also bei mir (xlC V5) läuft das hier

#include <iostream>
#include <fstream>
#include <string>

using namespace std;

string get(string const& s) {
   ifstream in(s.c_str());
   string ret;
   in >> ret;
   return ret;
}

struct A {
   string const s;
   A() : s("default") {}
   A(string const& in)  : s(get(in)) {}
};

int main() {
   A a1;
   A a2("main.cpp");
   cout << "a1: " << a1.s << "\n";
   cout << "a2: " << a2.s << "\n";
   return 0;
}

...und ich wüsste auch nicht, was dagegen spräche - weder sprach- noch designtechnisch.
Dass "const" nur für die Lebenszeit von Objekten gilt, ist ja nicht neu ... sonst wären ja auch const-Funktionsparameter (oder const lokale Variablen) nicht erlaubt.

Gruß,

Simon2.

klappt so

mh hätte ich eigendlich selbst drauf kommen können -.-

Also grundsätzlich macht dein Konstruktor Dinge, welcher er gar nicht tun sollte, bzw. nicht in seinen Aufgabenbereich gehört.

Grüssli

...Das Problem kommt meiner Meinung nach vor allem von einem Design-/Denkfehler. ...

Naja ... so ganz pauschal würde ich das nicht sehen. Es kann IMHO durchaus in Ordnung sein (designtechnisch), wenn const-Member auch über komplexere Wege initialisiert werden können als einfache Wertübergabe per Ctor ... und auch, wenn diese Wege, die scheitern können.
Das bedeutet aber nicht, dass diese Aufgabe automatisch die komplette "Erzeugungsverantwortung" für die Fachklasse haben muss.

Gruß,

Simon2.

ich schreibe ein snake spiel (bzw es ist eig soweit fertig) und einmal soll man die grösse per Ctor angeben können um in einem rechteck ohne alles spielen zu können

und einmal soll man einen dateinamen angeben können. in dieser datei sind dann levelkoordinaten gespeichert

das snake spiel ist in einer klasse (weswegen ein copy Ctor und ein zuweiser blöd sind) und die breite und höhe ist als const unsigned int angegeben und die sollen halt aus der datei gelesen werden

so wie simon2 es erklärt hat klappts auch gut

ok ich muss zugeben es ist nicht gut designt aber das ist meine rstes spiel und mein erstes richtig projekt mit klassen

@Skym0sh0,
Vielleicht nur zwei Dinge (von womöglich vielen :)):
1. Ich würde ein LevelLoader oder sowas ausserhalb der Klasse schreiben. Sowas gehört meiner Meinung nach ausgelagert.
2. Es ist fraglich, ob diese Grössen wirklich const sein sollten. Man sollte es mit const auch nicht übertreiben
Kann es wirklich nicht sein, dass sich diese Grössen verändern? Wäre doch durchaus möglich, vielleicht sogar als Spielfeature

Grüssli

@Simon2,
Sobald die Klasse komplexere Wege gehen muss, welche durch Regionen führen, welche sie nicht betrifft, dann gehört sowas ausgelagert. Der Konstruktor soll nur die eigenen Variablen initialisiseren. Die komplexen Wege sollten vorher getätigt werden.
Ich denke das darf man durchaus so pauschal sagen, wie auch beim dynamic_cast . ...

Gerne.
Ich war ja auch nicht gegen das Auslagern (mache ich in meinem Beispiel ja auch), sondern nur gegen die "Erzeugungsverantwortung".
In diesem Fall, bei dem es letztlich nur um eine Datenquelle handelt, reicht IMHO die lockere Kopplung (get() hat einen eigentständigen Sinn und ist nicht nur zur Erzeugung von A da) vollkommen aus.
Sobald die "äußere" Funktionalität aber noch für die Lebenszeit des Objekts Relevanz hat (z.B. wenn in unserem Beispiel eine Änderung in der Datei auch den Zustand eines erzeugten A-Objektes bewirken soll), fände ich eine engere Kopplung auch besser. ... aber als reine Datenquelle geht das schon in Ordnung.

Leicht OT: Ich denke, es gibt hier 2 (gleich korrekte) Vorstellungen von "pauschal":
a) Die Aussage trifft in den meisten/wesentlichen Fällen zu. Der Rest sind "Die Regel bestätigende Ausnahmen".
b) Die Aussage trifft genau IMMER zu.
Vermutlich meintest Du eher "pauschal-a)" während ich "pauschal-b)" meinte.

Gruß,

Simon2.