ZFX + Developia

Verfasst: **15.11.2012, 17:22**

Es nutzt Assimp :-)

Verfasst: **15.11.2012, 22:50**

gut... das ist dann zumindest ein Sympathiepunkt^^

Verfasst: **16.11.2012, 19:11**

Yeah, mein new/delete und new[]/delete[] Ersatz in pre C++ 11 ( siehe http://zfx.info/viewtopic.php?p=34605#p34605 ) nimmt jetzt beliebige Kontruktoren, solange diese nicht mehr als 10 Parameter haben:

Code: Alles auswählen

#ifdef __MEMORY_MANAGER
#define DEFINITION_ALLOCATE(...) \
{ \
	Ftype* p = reinterpret_cast<Ftype*>(MALLOC(sizeof(Ftype))); \
	new(p) Ftype(__VA_ARGS__); \
	return p; \
}

#define DEFINITION_ALLOCATE_ARRAY(count, ...) \
{ \
	size_t* pRaw = reinterpret_cast<size_t*>(MALLOC(sizeof(Ftype)*count+sizeof(size_t))); \
	*pRaw = count; \
	Ftype* p = reinterpret_cast<Ftype*>(pRaw+1); \
	for(size_t i=0; i<count; ++i) \
		new(p+i) Ftype(__VA_ARGS__); \
	return p; \
}

template<typename Ftype             >                                                                                                                       Ftype* allocate(void)                                                                   DEFINITION_ALLOCATE()
template<typename Ftype, typename P1>                                                                                                                       Ftype* allocate(P1 p1)                                                                  DEFINITION_ALLOCATE(p1)
template<typename Ftype, typename P1, typename P2>                                                                                                          Ftype* allocate(P1 p1, P2 p2)                                                           DEFINITION_ALLOCATE(p1, p2)
template<typename Ftype, typename P1, typename P2, typename P3>                                                                                             Ftype* allocate(P1 p1, P2 p2, P3 p3)                                                    DEFINITION_ALLOCATE(p1, p2, p3)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4>                                                                                Ftype* allocate(P1 p1, P2 p2, P3 p3, P4 p4)                                             DEFINITION_ALLOCATE(p1, p2, p3, p4)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4, typename P5>                                                                   Ftype* allocate(P1 p1, P2 p2, P3 p3, P4 p4, P5 p5)                                      DEFINITION_ALLOCATE(p1, p2, p3, p4, p5)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4, typename P5, typename P6>                                                      Ftype* allocate(P1 p1, P2 p2, P3 p3, P4 p4, P5 p5, P6 p6)                               DEFINITION_ALLOCATE(p1, p2, p3, p4, p5, p6)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4, typename P5, typename P6, typename P7>                                         Ftype* allocate(P1 p1, P2 p2, P3 p3, P4 p4, P5 p5, P6 p6, P7 p7)                        DEFINITION_ALLOCATE(p1, p2, p3, p4, p5, p6, p7)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4, typename P5, typename P6, typename P7, typename P8>                            Ftype* allocate(P1 p1, P2 p2, P3 p3, P4 p4, P5 p5, P6 p6, P7 p7, P8 p8)                 DEFINITION_ALLOCATE(p1, p2, p3, p4, p5, p6, p7, p8)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4, typename P5, typename P6, typename P7, typename P8, typename P9>               Ftype* allocate(P1 p1, P2 p2, P3 p3, P4 p4, P5 p5, P6 p6, P7 p7, P8 p8, P9 p9)          DEFINITION_ALLOCATE(p1, p2, p3, p4, p5, p6, p7, p8, p9)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4, typename P5, typename P6, typename P7, typename P8, typename P9, typename P10> Ftype* allocate(P1 p1, P2 p2, P3 p3, P4 p4, P5 p5, P6 p6, P7 p7, P8 p8, P9 p9, P10 p10) DEFINITION_ALLOCATE(p1, p2, p3, p4, p5, p6, p7, p8, p9, p10)

template<typename Ftype             >                                                                                                                       Ftype* allocateArray(size_t count)                                                                         DEFINITION_ALLOCATE_ARRAY(count)
template<typename Ftype, typename P1>                                                                                                                       Ftype* allocateArray(size_t count, P1 p1)                                                                  DEFINITION_ALLOCATE_ARRAY(count, p1)
template<typename Ftype, typename P1, typename P2>                                                                                                          Ftype* allocateArray(size_t count, P1 p1, P2 p2)                                                           DEFINITION_ALLOCATE_ARRAY(count, p1, p2)
template<typename Ftype, typename P1, typename P2, typename P3>                                                                                             Ftype* allocateArray(size_t count, P1 p1, P2 p2, P3 p3)                                                    DEFINITION_ALLOCATE_ARRAY(count, p1, p2, p3)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4>                                                                                Ftype* allocateArray(size_t count, P1 p1, P2 p2, P3 p3, P4 p4)                                             DEFINITION_ALLOCATE_ARRAY(count, p1, p2, p3, p4)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4, typename P5>                                                                   Ftype* allocateArray(size_t count, P1 p1, P2 p2, P3 p3, P4 p4, P5 p5)                                      DEFINITION_ALLOCATE_ARRAY(count, p1, p2, p3, p4, p5)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4, typename P5, typename P6>                                                      Ftype* allocateArray(size_t count, P1 p1, P2 p2, P3 p3, P4 p4, P5 p5, P6 p6)                               DEFINITION_ALLOCATE_ARRAY(count, p1, p2, p3, p4, p5, p6)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4, typename P5, typename P6, typename P7>                                         Ftype* allocateArray(size_t count, P1 p1, P2 p2, P3 p3, P4 p4, P5 p5, P6 p6, P7 p7)                        DEFINITION_ALLOCATE_ARRAY(count, p1, p2, p3, p4, p5, p6, p7)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4, typename P5, typename P6, typename P7, typename P8>                            Ftype* allocateArray(size_t count, P1 p1, P2 p2, P3 p3, P4 p4, P5 p5, P6 p6, P7 p7, P8 p8)                 DEFINITION_ALLOCATE_ARRAY(count, p1, p2, p3, p4, p5, p6, p7, p8)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4, typename P5, typename P6, typename P7, typename P8, typename P9>               Ftype* allocateArray(size_t count, P1 p1, P2 p2, P3 p3, P4 p4, P5 p5, P6 p6, P7 p7, P8 p8, P9 p9)          DEFINITION_ALLOCATE_ARRAY(count, p1, p2, p3, p4, p5, p6, p7, p8, p9)
template<typename Ftype, typename P1, typename P2, typename P3, typename P4, typename P5, typename P6, typename P7, typename P8, typename P9, typename P10> Ftype* allocateArray(size_t count, P1 p1, P2 p2, P3 p3, P4 p4, P5 p5, P6 p6, P7 p7, P8 p8, P9 p9, P10 p10) DEFINITION_ALLOCATE_ARRAY(count, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10)

template<typename Ftype>
void deallocate(const Ftype* p)
{
	if(!p)
		return;
	p->~Ftype();
	FREE(const_cast<Ftype*>(p));
}

template<typename Ftype>
void deallocateArray(const Ftype* p)
{
	if(!p)
		return;
	size_t* pRaw = (reinterpret_cast<size_t*>(const_cast<Ftype*>(p))-1);
	for(size_t i=*pRaw; i-->0;)
		p[i].~Ftype();
	FREE(pRaw);
}
#endif

Haupteffekt:
Ich kann meinen eigenen MemoryManager, der auf dem Testsytem 30 mal so schnell dynamischen Speicher bereit stellt, wie malloc es tut, mit allen Vorteilen, die new über malloc hat, benutzen, ohne new global überschreiben zu müssen oder auf Klassenherarchien, welche new überschreiben, beschränkt zu sein.

Genialer Nebeneffekt:
Damit lassen sich jetzt sogar Arrays mit Non-Default Konstruktoren konstruieren!

PS:
Dank geht an die programmierende Katze für ihre sehr nützliche Hilfe bei der Lösung des Problems

Verfasst: **16.11.2012, 19:23**

Exceptions sind bei dir gänzlich abgeschaltet, oder? Sonst müsstest du die nämlich behandeln. Davon abgesehen solltest du dir darüber im Klaren sein, dass all deine Konstruktorargumente rein semantisch kopiert werden. Tatsächlich kann der Compiler unter bestimmten Voraussetzungen Copy Elision durchführen, mit Sicherheit keine Kopien bekommst du jedoch nur mit const P1 &p1 ....

Verfasst: **16.11.2012, 19:36**

CodingCat hat geschrieben:Exceptions sind bei dir gänzlich abgeschaltet, oder? Sonst müsstest du die nämlich behandeln.

Er könnte auch einen globalen new_handler haben, welcher beispielsweise einfach terminate aufruft.

Verfasst: **16.11.2012, 19:38**

eXile hat geschrieben:
CodingCat hat geschrieben:Exceptions sind bei dir gänzlich abgeschaltet, oder? Sonst müsstest du die nämlich behandeln.
Er könnte auch einen globalen new_handler haben, welcher beispielsweise einfach terminate aufruft.

Nein, hier müsste er die Exception in keinem Fall behandeln (er nutzt den Standard-new-Operator nicht mal, aber selbst wenn). Relevant ist hier, ob Konstruktoren Exceptions werfen können. In diesem Fall müsste der Speicher bei Exception nach Zerstörung aller bereits erfolgreich konstruierten Objekte wieder manuell freigegeben werden.

Verfasst: **16.11.2012, 19:45**

CodingCat hat geschrieben:Nein, hier müsste er die Exception in keinem Fall behandeln (er nutzt den Standard-new-Operator nicht mal, aber selbst wenn).

Stimmt, das ist ja Placement-new, und das ist nothrow.

CodingCat hat geschrieben:Relevant ist hier, ob Konstruktoren Exceptions werfen können. In diesem Fall müsste der Speicher bei Exception nach Zerstörung aller bereits erfolgreich konstruierten Objekte wieder manuell freigegeben werden.

Auch da hast du recht. Man man man; ich hätte einfach obigen Post nicht schreiben sollen. :oops:

Verfasst: **16.11.2012, 20:19**

CodingCat hat geschrieben:Exceptions sind bei dir gänzlich abgeschaltet, oder? Sonst müsstest du die nämlich behandeln. Davon abgesehen solltest du dir darüber im Klaren sein, dass all deine Konstruktorargumente rein semantisch kopiert werden. Tatsächlich kann der Compiler unter bestimmten Voraussetzungen Copy Elision durchführen, mit Sicherheit keine Kopien bekommst du jedoch nur mit const P1 &p1 ....

Stimmt, da muss ich noch konstante Referenzen draus machen. Danke für den Hinweis. Komplett vergessen.
Exceptions sind bei mir in der Tat komplett abgeschaltet, weil die Codebase auch auf Plattformen laufen muss, die keine Exceptions implementiert haben, so dass ich keinerlei Code haben kann, der Exceptions schmeißt oder fängt (es sei denn, in entsprechenden Platform-ifdefs. Dazu kommt natürlich, dass man mit Exceptions an jeder Stelle aufpassen muss, dass auch alles aufgeräumt wird, falls eine Exception fliegt, für den Fall, dass sie wer fängt. Die gesamte Codebase exception-safe zu bekommen, wäre wohl Arbeit für Monate.

Verfasst: **19.11.2012, 12:06**

Ich habe gerade festgestellt, dass sich mit Templates und Friends wunderbar eine Handle-Klasse zum Verstecken interner Daten/Zeiger definieren lässt:

Code: Alles auswählen

template <class Type, class Owner>
class handle
{
	friend Owner;

public:
	/// Type of the value stored.
	typedef Type value_type;
	/// Type of the owner.
	typedef Owner owner_type;

protected:
	/// Value stored.
	value_type value;

	/// Constructs a handle from the given value.
	explicit handle(const value_type &value)
		: value(value) { }
	
	/// Gets the value stored by this handle.
	const value_type& get() const { return this->value; }
	/// Gets the value stored by this handle.
	operator value_type() const { return this->value; }
};

Damit lassen sich in handle<InternalType*, OwnerClass> gespeicherte Zeiger auf InternalType nur von OwnerClass aus lesen oder verändern, obendrein können außerhalb von OwnerClass keine neuen (und höchstwahrscheinlich unsinnigen) Handles erzeugt werden.

Verfasst: **19.11.2012, 12:14**

Und was ist daran Jammer-Thread-Würdig? :)

Verfasst: **19.11.2012, 12:18**

Mist, verklickt und korrigiert. Selbst die 2 Threads sind schon zu viel in diesem Forum. ;)

Verfasst: **19.11.2012, 23:39**

Endlich lückenlose LOD-Übergänge in meinem Dual Contouring :)

Verfasst: **20.11.2012, 17:32**

Der this-Zeiger lässt sich mit der gleichen Syntax __restricten, mit der er sich consten lässt:

Code: Alles auswählen

class Foo
{
   void method(...) __restrict { ... }
};

Quelle mit weiteren Erläuterungen und Beispielen: http://www.codercorner.com/blog/?p=732

Verfasst: **20.11.2012, 18:56**

Krishty hat geschrieben:Eine Ergänzung zu __restrict auf Seite 76: Bei Visual C++ hat es keine Auswirkung mehr, weil LTCG Aliasing mittlerweile sehr gut ausschließen kann; selber dekorieren lohnt nicht mehr.

Krishty hat geschrieben:Der Grund, dass ich nie einen Unterschied sehe, ist also x64.

Auf x64 im Release kompilieren oder nie geschehen.

Verfasst: **20.11.2012, 19:02**

Genau; wollte ich gerade sagen. Selbst ich setze deshalb __restrict nicht ein.

Anderes Anti-Jammer: Ein freundlicher Raubkopierer hat sich die Mühe gegeben, die aus dem Rohschnitt stammenden entfernten Szenen wieder mit der Endfassung von Starship Troopers zu vereinigen. Das Resultat hat mehr Sex, Gewalt, Neoliberalismus, Militarismus, und ein minimal anderes Ende. Das macht zwar keinen anderen Film draus, hätte aber ruhig von Anfang an so sein können.

Verfasst: **23.11.2012, 13:14**

: Be water my friends

Verfasst: **23.11.2012, 13:38**

Schick! Schon in Voxeln mit Fluss-Simulation, oder erstmal nur ne Ebene mit Physikwirkung? In beiden Fällen aber gute Arbeit!

Verfasst: **24.11.2012, 00:40**

hehe

Verfasst: **24.11.2012, 04:40**

Wollt ihr endlich Edit and Continue unter x64 in Visual Studio? Dann stimmt ab!

Der entsprechende Eintrag ist:

EnC Survey hat geschrieben:64-bit Native EnC: (Currently Native EnC is only supported on x86-32 bit platform, this choice is about extending support for Native EnC to x64)

Abstimmen Kinners! Abstimmen!

Bild

Die gegenwärtige Situation von Edit and Continue bildlich zusammengefasst. Wenn ihr nichts daran ändert habt ihr hieran persönlich Schuld.

Verfasst: **24.11.2012, 09:07**

Wie viele Stunden verbringen Sie durchschnittlich mit Visual C++ 2012 pro Woche?
– 80 oder so.

Wie viele Stunden haben Sie Visual C++ 2012 seit der Freigabe im August benutzt?
– 601 oder mehr.

Auf dem Papier hört sich mein Leben echt jämmerlich an … aber dann lese ich sowas:

Currently you cannot debug files with more than 64K lines. We cannot set breakpoints on line numbers greater than that.

Echt lustige Sachen in dem Survey. Die meisten Fragen suggerieren, dass sie längst wissen, was wir wollen (z.B. IntelliSense während des Debuggens); aber uns nochmal extra durch die Ringe hüpfen lassen, damit sie harte Zahlen dafür vorlegen können.

14. Briefly describe your current experience using Native EnC.
– I attend a VS2010, x86-compatible code base for the sole purpose of downgrading my VS2012 x64 code to it whenever I need to use EnC.

Einige Features sind auch einfach lächerlich. Wie wichtig ist mir, dass ich meinen Quelltext in EnC kommentieren kann? Seid ihr völlig bescheuert?! Wenn sich die Semantik nicht ändert, hat das intrinsisch zu funktionieren. Wie kaputt muss eine Implementierung sein, dass das nicht geht?!

Aber trotzdem ganz nett die Abstimmung. Mal sehen, was draus wird. Von der letzten Abstimmung über den Optimizer habe ich nie mehr wieder was gehört.

Verfasst: **24.11.2012, 13:06**

Ich habe mein assert()-Makro gerade so modifiziert, dass ein Klick auf Wiederholen tatsächlich in die Zeile mit der Assertion springt statt in die Funktion. Wie viel Lebenszeit mir das spart

Verfasst: **24.11.2012, 19:14**

Krishty hat geschrieben:Auf dem Papier hört sich mein Leben echt jämmerlich an … aber dann lese ich sowas:
Currently you cannot debug files with more than 64K lines. We cannot set breakpoints on line numbers greater than that.

Krishty hat geschrieben:Einige Features sind auch einfach lächerlich. Wie wichtig ist mir, dass ich meinen Quelltext in EnC kommentieren kann? Seid ihr völlig bescheuert?! Wenn sich die Semantik nicht ändert, hat das intrinsisch zu funktionieren. Wie kaputt muss eine Implementierung sein, dass das nicht geht?!

Genau das habe ich mir auch gedacht, als ich das gelesen habe. Ich sehe es schon kommen: In Visual Studio 2014 gibt es Edit and Continue, dann steht da so ein fettes Sternchen daneben und da drunter steht etwas in der Art wie: Sie dürfen nur Kommentare und Leerzeichen einfügen. Viel Spaß!

Verfasst: **27.11.2012, 13:08**

Es ist faszinierend wie manche Konventionen zu einer großartigen Konsistenz führen. So zum Beispiel das Iterator-Range-Konzept der STL, durch dessen inklusiven Anfang und exklusives Ende in nahezu allen weiteren Rechnungen die Addition/Subtraktion zusätzlicher Einsen entfällt, womit sich Fencepost Errors enorm einfach vermeiden lassen. Das ist für die meisten vermutlich ganz natürlich.

Überrascht hat mich heute, dass etwas Ähnliches auch für das Entfernen einzelner Elemente aus Ranges gilt. Iteriert man gewohnheitsmäßig vorwärts über Ranges und sucht dabei nach bestimmten Elementen, welche bei Auffinden entfernt werden, so rutschen mit jeder Entfernung Elemente von hinten nach und der Iterator muss künstlich dazu bewegt werden, im nächsten Schleifendurchlauf noch einmal auf dieselbe Elementposition zu zeigen. Folgt man hingegen der C++-Konvention zu Konstruktions- und umgekehrter Destruktionsreihenfolge, die obendrein bei Nebenwirkungen zu wesentlich konsistenterem Verhalten führt, entfällt auch diese Sonderbehandlung. Iteriert man beim Entfernen rückwärts über die Elemente, so wurden bei Entfernen eines Elements alle nachrutschenden Elemente bereits gefiltert. Ganz egal, ob im aktuellen Schleifendurchlauf ein Element entfernt wurde oder nicht, das nächste zu verarbeitende Element ist immer eine Position weiter vorne.

Verfasst: **27.11.2012, 23:31**

Der Nutzen von Funktionsselektion via Overload Resolution und Tag-Typen an Stelle von Template-Spezialisierungen ist nicht zu unterschätzen, insbesondere weil sich damit das Klammerchaos bisweilen drastisch reduzieren lässt. So konnte ich meinen multi_vector (Erinnerung: Variadisches Template für automatisiertes Structure-of-Arrays-Layout) gerade sowohl in Bezug auf Benutzbarkeit als auch in Bezug auf Compile-Zeit-Fehlerverhalten mit solchen Tag-Typen stark verbessern:

Code: Alles auswählen

// Vorher
entities.get<reflected>()[idx]...
entities.get<transformation>()[idx]...

// Nachher
entities(reflected)[idx]...
entities(transformation)[idx]...

// Wie?
enum registry_tag { registry };
enum reflected_tag { reflected };
enum transformation_tag { transformation };
...

typedef multi_vector_t<>::make<
		Registry, registry_tag,
		Entity*, reflected_tag,
		Transformation, transformation_tag,
		...
	>::type entities_t;

// In multi_vector
using Base::operator (); // Rekursive Dekomposition mittels private-Vererbungshierarchie
vector_type& operator ()(Tag) { return v; } // Füge Overloads für Tag der aktuellen Hierarchieebene hinzu
const vector_type& operator ()(Tag) const { return v; }

Lasst euch von multi_vector_t nicht irritieren, das ist nur ein hässlicher Hack, der das variadische Template multi_vector<...> notdürftig pre-C++11 umsetzt.

Verfasst: **27.11.2012, 23:57**

CodingCat hat geschrieben:als auch in Bezug auf Compile-Zeit-Fehlerverhalten

Bezieht sich das jetzt nur auf die Lesbarkeit der Fehlermeldung, oder werden dadurch tatsächlich weitere Fehlerfälle erkannt? Ich kann mir nämlich gerade kein Beispiel denken, in dem das mehr Fehlerfälle erkennt als in der Template-Variante.

Verfasst: **28.11.2012, 00:05**

eXile hat geschrieben:
CodingCat hat geschrieben:als auch in Bezug auf Compile-Zeit-Fehlerverhalten
Bezieht sich das jetzt nur auf die Lesbarkeit der Fehlermeldung, oder werden dadurch tatsächlich weitere Fehlerfälle erkannt? Ich kann mir nämlich gerade kein Beispiel denken, in dem das mehr Fehlerfälle erkennt als in der Template-Variante.

Ja, das bezieht sich natürlich auf die Fehlermeldung. In Bezug auf Korrektheit gibt es keine Unterschiede. Der große Unterschied ist, dass Spezialisierungen nicht einfach so über Klassengrenzen hinweg funktionieren, weshalb im Falle von Spezialisierungen unzählige "rekursive" Hilfsaufrufe notwendig werden, was sich im Fehlerfall am Ende in kilometerlangen Template-Instanziierungs-Traces äußert. Damit verbunden wäre im Übrigen auch großes Chaos beim Debuggen, sofern man den Debugger nicht dazu angewiesen bekommt, entsprechende Hilfsaufrufe zu überspringen. Mit Overload Resolution und Namensimport mittels using hat man hingegen überall nur einen einfachen Funktionsaufruf, was die Sache enorm verbessert, bezüglich Debug-Code-Generierung, Debugger-Tauglichkeit und Compiler-Fehlerverhalten. Sogar IntelliSense liefert dann brauchbare Information.

Verfasst: **29.11.2012, 21:36**

https://www.humblebundle.com/ Das Humble THQ Bundle (achtung Saint Row ist nicht in Deutschland verfügbar, also kann man ruhig "weniger" zahlen ;))

Verfasst: **29.11.2012, 23:48**

Man kann es aktivieren, wenn man sich ueber einen Proxy einloggt. Spielbar ist es danach wohl ganz normal in Dt.

Verfasst: **30.11.2012, 00:04**

ah, daran hatte ich auch schon gedacht. schön dass es funktioniert, werde ich gleich mal ausprobieren.

Verfasst: **02.12.2012, 00:10**

Auf die Gefahr hin, dass ich alle schon längst mit überflüssigen C++ Hacks langweile, hier meine neuste Entdeckung: Halbe Move Semantics in C++03, in jenen STL-Containern welche ohne Reallokation auskommen:

Code: Alles auswählen

struct RAIIFoo
{
   Resource resource;

   // Normaler RAII-Code
   RAIIFoo(...)
      : resource(...) {}
   ~RAIIFoo()
   {
      if (resource != invalid)
         free(resource);
   }

   // Container erfordern Default Construction und Copy Construction
   RAIIFoo()
      : resource(invalid) {}
   RAIIFoo(const RAIIFoo &right)
      : resource(invalid)
   {
      // Stelle sicher, dass keine initialisierten Objekte kopiert und so
      // Ressourcen durch mehrere Objekte gleichzeitig verwaltet werden
      assert(right.resource == invalid);
   }

   void swap(RAIIFoo &right)
   {
      std::swap(resource, right.resource);
   }
};

std::list<RAIIFoo> list;

// Konstruiere RAII-Objekt
RAIIFoo foo(...);
// Verschiebe per Swap in Liste
list.push_back(RAIIFoo());
list.back().swap(foo);

vector ohne Vorallokation fällt selbstverständlich nicht in die Kategorie unterstützter Container, worauf die Assertion im Copy Constructor dann zur Laufzeit aufmerksam macht. Wenn ihr richtig reserve()t, ist auch das Speichern in Vektoren möglich.

Wenn möglich, nutzt ihr natürlich einfach std::move(), wie es inzwischen praktisch jeder Compiler unterstützt, der auch nur einen Hauch von C++11 kennt:

Code: Alles auswählen

struct RAIIFoo
{
   Resource resource;

   RAIIFoo(...)
      : resource(...) {}
   RAIIFoo(RAIIFoo &&right)
      : resource(right.resource)
   {
      right.resource = invalid;
   }
   ~RAIIFoo()
   {
      if (resource != invalid)
         free(resource);
   }
};

std::list<RAIIFoo> list;

// Konstruiere RAII-Objekt "in" Liste
list.push_back(RAIIFoo(...));

// ... oder konstruiere erste und verschiebe dann
RAIIFoo foo(...);
list.push_back(std::move(foo));
// Achtung: foo genau wie nach swap ab hier ungültig

ZFX + Developia

Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Jammer-Thread

Re: Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread

Re: Anti-Jammer-Thread