boost::array<int, 4> test = { 1, 2, 3, 4 };   // ok

Wie funktioniert es, wenn ich das array auf dem Heap anlege? Rein syntaktisch, meine ich. Ich suche also sowas wie

boost::array<int, 4>* test = new boost::array<int, 4>() = { 1, 2, 3, 4 };

aber es sollte compilieren Ich kann übrigens auf die Initialisierung nicht verzichten, da es in Wirklichkeit keine ints sind und auch nichts, was einen Standardkonstruktor hat.

Danke, an den ersten, der dieses Rätsel lösen kann.

Aber wieso willst du ein statisches Array ( boost::array ist eigentlich nur ein Wrapper für C-Arrays) dynamisch anlegen? Wäre da std::vector nicht eher was?

boost::array<int, 4> const temp = { 0, 1, 2, 3 };
boost::array<int, 4>* p = new boost::array<int, 4>(temp);

Womöglich ist der Kompiler klug genug, dies wegzuoptimieren

Grüssli

Womöglich ist der Kompiler klug genug, dies wegzuoptimieren

Falls nicht (was ich hier befürchte) hat man viele unnötige Konstruktionen - denk dran, es geht Optimizer nicht um int s. Je nachdem kann sich das beim Quadtree ziemlich negativ auswirken. Abgesehen davon weisst du nicht, ob die Objekte überhaupt kopierfähig sind.

class ChildCollection {
	public:
		ChildCollection(const Area& parentArea);
		boost::array<Quadtree, 4>::iterator begin();
		boost::array<Quadtree, 4>::iterator end();

	private:
		boost::array<Quadtree, 4> children;
	};

Aber ich kann das array natürlich wieder nicht richtig initialisieren. Ich seh's jedenfalls nicht, wie das in der Initialisierliste gehen soll und nen Standardkonstruktor gibts nicht, da es für den Quadtree auch keinen gibt. Es endet also wieder mit Quadtree* als array-Element, dann kann ich mir aber die eigene Klasse sparen.

Die STL-Container fallen auch weg, weil deine Objekte nicht kopierbar sind (Zeiger und SmartPointer sind wahrscheinlich unnötig/mühsam). Naheliegend wären für mich die Boost.PointerCointainer, z.B. boost::ptr_vector . Oder du schreibst einen eigenen Container, was allerdings nicht mit wenig Aufwand verbunden ist, wenn du auch Iteratoren unterstützen willst.

Ich bin mir allerdings eh nicht ganz sicher, was du genau tun willst. Sollte ChildCollection -Konstruktor nicht vier Parameter haben? Oder erstellst du die Quadtree -Unterbäume erst im Konstruktor selbst?

Du hast mich immerhin auf ptr_array gebracht, das hört sich schon mal besser an als alles was ich bisher ausprobiert habe. Kann iterieren, brauche keinen eigenen Destruktor, fast schon geil. Nur die child Quadtrees sind auf dem Heap allokiert. Da komm ich wahrscheinlich nicht drum herum, wenn ich es nicht schaffe, ein Array zu initialisieren. Im Moment ist das meine favorisierte Lösung.

Die QuadTrees sollten auch auf dem Heap allokiert sein. Ich kann mir vorstellen, dass das Ganze grösser werden könnte, und mit dem Heap bist du diesbezüglich viel flexibler. Ich denke hingegen eher nicht, dass der Performancenachteil durch dynamische Allokationen derart dramatisch sein sollte...

Initialisieren kannst du das dann entweder über copy-construction (einfach zuweisen - intern wird dann der copy-ctor aufgerufen), oder über eine in-place-factory (was die unnötige Kopie vermeiden würde).

p.S.: boost::optional ist IMO eine sehr interessante, aber oft "übersehene" Library.

Ich tendiere jetzt trotzdem eher zum unschönen array<Quadtree*, 4>, außer ich krieg das ptr_array noch zum laufen.

@Optimizer,

#include <boost/ptr_container/ptr_array.hpp>

int main()
{
	boost::ptr_array<boost::nullable<int>, 4> arr;

	arr.replace<0>(new int(0));
	arr.replace<1>(new int(1));
	arr.replace<2>(new int(2));
	arr.replace<3>(new int(3));

	return 0;
}

Wenn du die Objekte im ptr_array nicht wieder auf 0 zurücksetzen möchtest, dann kannst du auf boost::nullable verzichten. Ohne boost::nullable darfst du aber nie bei replace eine 0 übergeben, sonst hast eine Exception am Hals.

Grüssli

Damit hab ich jetzt endgültig 2 Indirektionen zu den Kindknoten hin, aber ansonsten ist alles ziemlich geil, zum Beispiel kann ich die Kinder alle entfernen indem ich einfach den auto_ptr resette.