immer init-list?
-
gibt es situationen, wo es sinn macht, die datenelemente einer klasse mittels zuweisung und nicht per init-liste zu initialisieren?
-
abc_ schrieb:
gibt es situationen, wo es sinn macht, die datenelemente einer klasse mittels zuweisung und nicht per init-liste zu initialisieren?
Wenn der Programmablauf in den Konstruktor hineinkommt, sind schon alle Elemente initialisiert. Du hast keine Chance mehr sie zu initialisieren. Alles was danach getrieben wird kann nur noch bestehende Werte verändern.
-
das ist leider keine konkrete antwort auf meine frage.
-
Doch.
-
Ja, die gibt es, wenn es z.B. Sinn macht, im Konstruktor und Copy-Konstruktor eine private Methode init(){...} einzusetzen, weil dies effizienter und wartungsfreundlicher zu schreiben ist als eine Initialiserungsliste.
Beispiel: Scott Meyers, "Effektive C++", Item 12.There is one time, however, when it may make sense to use assignment instead of initialization for the data members in a class. That is when you have a large number of data members of built-in types, and you want them all initialized the same way in each constructor. For example, here's a class that might qualify for this kind of treatment: ¤ Item E12, P20
class ManyDataMbrs {
public:
// default constructor
ManyDataMbrs();// copy constructor
ManyDataMbrs(const ManyDataMbrs& x);private:
int a, b, c, d, e, f, g, h;
double i, j, k, l, m;
};Suppose you want to initialize all the ints to 1 and all the doubles to 0, even if the copy constructor is used. Using member initialization lists, you'd have to write this: ¤ Item E12, P21
ManyDataMbrs::ManyDataMbrs()
: a(1), b(1), c(1), d(1), e(1), f(1), g(1), h(1), i(0),
j(0), k(0), l(0), m(0)
{ ... }ManyDataMbrs::ManyDataMbrs(const ManyDataMbrs& x)
: a(1), b(1), c(1), d(1), e(1), f(1), g(1), h(1), i(0),
j(0), k(0), l(0), m(0)
{ ... }This is more than just unpleasant drudge work. It is error-prone in the short term and difficult to maintain in the long term. ¤ Item E12, P22
However, you can take advantage of the fact that there is no operational difference between initialization and assignment for (non-const, non-reference) objects of built-in types, so you can safely replace the memberwise initialization lists with a function call to a common initialization routine: ¤ Item E12, P23
class ManyDataMbrs {
public:
// default constructor
ManyDataMbrs();// copy constructor
ManyDataMbrs(const ManyDataMbrs& x);private:
int a, b, c, d, e, f, g, h;
double i, j, k, l, m;void init(); // used to initialize data
// members
};void ManyDataMbrs::init()
{
a = b = c = d = e = f = g = h = 1;
i = j = k = l = m = 0;
}ManyDataMbrs::ManyDataMbrs()
{
init();...
}
ManyDataMbrs::ManyDataMbrs(const ManyDataMbrs& x)
{
init();...
}
Because the initialization routine is an implementation detail of the class, you are, of course, careful to make it private, right? ¤ I
-
@Erhard
das mit dem init-idiom ist ja richtig aber technisch gesehen ist es keine initialisierung. Die variablen wurden bereits vom compiler initialisiert bevor du sie zu gesicht bekommst. Also hat Ponto recht und die frage war ja auch ob es noch eine andere Methode gibt member zu initialisieren ausser mit der init-list.
-
die frage war ja auch ob es noch eine andere Methode gibt member zu initialisieren ausser mit der init-list.
Nein, dies ist nicht exakt die Fragestellung. Aber die Sachlage ist dennoch klar. In den meisten Fällen ist die Initialisierungsliste die richtige Wahl außer bei Beispielen wie oben gezeigt.
-
Wenn man Member in einer anderen Reihenfolge als der deklarierten setzen will zum Beispiel. Wenn man foo(5), bar(foo) in der Liste hat und bar vor foo deklariert wurde - bumm.
Davon abgesehen ist die Initialisierungsliste IMHO einfach unübersichtlich und teilweise ganz schön nervig (so sehr, dass ich Sachen lieber in einen scoped_ptr verpacke und den Luxus genieße, sie im Body zu initialisieren). Ich mach jedenfalls einen Bogen drum... *troll*
-
Hier könnte der Schwanz mit dem Hund wackeln. Aber, wenn das so sein soll, dann wackelt er eben ohne Initialisierungsliste.
Scott Meyers, "Effective C++", Item 13:
be sure to list the members in an initialization list in the order in which those members are declared in the class.