Array von Objekten konstruieren.

volkard

Ja. Und dann noch schauen, welche Konstruktoren der vector alles hat und den coolen nehmen, der die Dir Schleife auch noch abnimmt.

camper

class braindead
{
public:
	static braindead initproto;
private:
	bool bBrain;
public:
	braindead ( bool bPresent )
	{
		bBrain = bPresent;
	}
	braindead ( const braindead& other = initproto )
		: bBrain( initproto.bBrain )
	{}
};

braindead braindead::initproto( true ); // Default-Initialisierung hier unbedingt vermeiden!

int main()
{
	braindead::initproto = false;
	braindead brainless[42];
}

Der Name ist Programm.

Danke Euch beiden!

@camper:

braindead ( const braindead& other = initproto ) // Wozu die Referenz?
        : bBrain( initproto.bBrain )
    {}

Sieht interessant aus. Warum hast du die Referenz in der Parameterliste
des Konstruktors drin?

Würde das nicht ohne gehen?

braindead () // Ohne Referenz.
        : bBrain( initproto.bBrain )
    {}

unskilled

construct0r schrieb:

Danke Euch beiden!

@camper:
braindead ( const braindead& other = initproto ) // Wozu die Referenz?
        : bBrain( initproto.bBrain )
    {}
Sieht interessant aus. Warum hast du die Referenz in der Parameterliste
des Konstruktors drin?

Würde das nicht ohne gehen?
braindead () // Ohne Referenz.
        : bBrain( initproto.bBrain )
    {}

klar - aber so hat er standard-ctor und copy-ctor in einem rutsch implementiert...

bb

unskilled schrieb:

klar - aber so hat er standard-ctor und copy-ctor in einem rutsch implementiert...
bb

aaaaaaaaaah, ach so!

Zeile 17:

braindead braindead::initproto( true ); // Default-Initialisierung hier unbedingt vermeiden!

Wenn ich das richtig sehe, wird damit das eingebettete statische Objekt erzeugt.
Was ist mit

Default-Initialisierung hier unbedingt vermeiden!

gemeint und warum?

volkard

construct0r schrieb:

Was ist mit

Default-Initialisierung hier unbedingt vermeiden!

gemeint und warum?

Weil dann das Objekt zum Initialisieren sich erst eine Referenz auf soch selber holt und eine Kopie des noch nicht inistialisierten selbst anlegt, was vom C++-Standard vermutlich nicht abgedeckt wirdm und wenn es nicht nur um einen bool ginge, sondern um einen string oder noch was dickeres, es auch bestimmt zu feinem Absturz käme.

camper

construct0r schrieb:

Warum hast du die Referenz in der Parameterliste
des Konstruktors drin?

Weil ich es ursprünglich noch etwas anders machen wollte, am Ende stand es zufällig so da. Man kann ja verschieden abwandeln (z.B. durch einen Zeiger, der jeweils auf eine geeignete Generatorfunktion verweist) - ohne dass sich etwas verbessert. Die Notwendigkeit, sich auf die vorherige Initialisierung eines anderen Objektes verlassen zu müssen, ist ein k.O.-Kriterium. Zudem müsste man in multithreaded Programmen wohl mit thread-lokalem Speicher arbeiten oder zusätzlich synhronisieren, was die Sache witer verkompliziert.

pumuckl

Alternativ gibts natürlich auch wieder ne boost Lösung für arrays statt vector

class MyObject
{
	bool bBrain;
public:
	MyObject ( bool bPresent )
	{
		bBrain = bPresent;
	}
};

int main()
{
    boost::array<MyObject, 5> mo = boost::assign::listof(true).repeat(4,true);
    //bzw evtl. auch folgendes:
    boost::array<MyObject, 5> mo = boost::assign::repeat(5,true);
}

Bei letzterem bin ich nicht 100%ig sicher obs klappt, die Doku ist da etwas dürftig.

Nexus

Oder wenns auch nach der Initialisierung sein darf: std::fill() . Nachzuschauen auf www.cplusplus.com...

Allerdings ist die Verwendung von STL-Containern (evtl. std::tr1::array als Array-Wrapper) sicher keine schlechte Idee.

Ich würds lieber mit einer Schleife und Zeigern machen, also jedes Objekt einzeln mit new erzeugen. So ist jedes Objekt individuell inizialisierbar.

pumuckl

ich++ schrieb:

Ich würds lieber mit einer Schleife und Zeigern machen, also jedes Objekt einzeln mit new erzeugen. So ist jedes Objekt individuell inizialisierbar.

Dafür hast du sie dann nicht in einem Array, also nicht hintereinander im Speicher. Einzeinitialisierungen gehen auch mit boost::assign:

boost::array<MyObject, 5> mo = boost::assign::list_of(true),false,true,true,false;

Nexus

pumuckl schrieb:

Einzeinitialisierungen gehen auch mit boost::assign:
boost::array<MyObject, 5> mo = boost::assign::list_of(true),false,true,true,false;

1. Meinst du nicht so?

boost::array<MyObject, 5> mo = boost::assign::list_of(true)(false)(true)(true)(false);

Der MSVC++ zumindest akzeptiert die Komma-Variante nicht. Mit Klammern gehts, aber da finde ich die ()()-Möglichkeit etwas schöner:

boost::array<MyObject, 5> mo = (boost::assign::list_of(true),false,true,true,false);

2. Ist das bei PODs, wie boost::array eines ist, unnötig, da dort die Aggregatsinitialisierungsliste verwendet werden kann. So kann man nämlich direkt initialisieren und muss sich keine Gedanken um die zweifelhafte Wegoptimierung des temporären Containers machen.

boost::array<MyObject, 5> mo = {true, false, true, true, false};

pumuckl schrieb:

Dafür hast du sie dann nicht in einem Array, also nicht hintereinander im Speicher.

Ich habe die Zeiger auf die Objekte hintereinander im Speicher:

MyObject* my_object_array[N];
for ( int i=0; i<N; i++ )
 my_object_array = new MyObject ( ... /* Individuelle Konstruktion */

unskilled

nein - die objekte an sich befinden sich eben _nicht_ hintereinander im speicher - lediglich die pointer darauf befinden sich hintereinander im speicher:

array:     _____ eins
----      /
| 0|  ----+-------- null
| 1|  ----´
| .| .
| .| .       ___ n
| .| .      |
| N|  ------´
----

noch dazu, muss N zur compile-zeit bekannt sein...

bb

edit: und außerdem musst du dich ums freigeben auch noch selbst kümmern... alles in allem eine höchst unkomfortable lösung, die mind. fehleranfälliger und langsamer(je nach dem, was du willst) etc. sein wird...

unskilled schrieb:

nein - die objekte an sich befinden sich eben _nicht_ hintereinander im speicher - lediglich die pointer darauf befinden sich hintereinander im speicher:

ich++ schrieb:

Ich habe die Zeiger auf die Objekte hintereinander im Speicher:

ich++ schrieb:

unskilled schrieb:

nein - die objekte an sich befinden sich eben _nicht_ hintereinander im speicher - lediglich die pointer darauf befinden sich hintereinander im speicher:

ich++ schrieb:

Ich habe die Zeiger auf die Objekte hintereinander im Speicher:

Verwirrung im Strafraum.

unskilled

Gelling schrieb:

ich++ schrieb:

unskilled schrieb:

nein - die objekte an sich befinden sich eben _nicht_ hintereinander im speicher - lediglich die pointer darauf befinden sich hintereinander im speicher:

ich++ schrieb:

Ich habe die Zeiger auf die Objekte hintereinander im Speicher:

Verwirrung im Strafraum.

oh verdammt waren aber wenigsten drei kurze wörtchen, die ich da überlesen hab
naja - die anderen nachteile bleiben...
ich geh dann mal besser ;o)

bb