Die Klasse "Sprite" soll in einer single linked list verwendet werden.
Das mache ich wie folgt:

typedef public boost::intrusive::link_mode<boost::intrusive::auto_unlink> NLLinkMode;
typedef public boost::intrusive::slist_base_hook< NLLinkMode > NLAutoUnlinkHook;

class NLEXPORT NLSprite : public NLBoundingBox, public NLAutoUnlinkHook
{
public:
   void unlink()     {  NLAutoUnlinkHook::unlink();  }
   bool is_linked()  {  return NLAutoUnlinkHook::is_linked();  }
};

Hier ist schon das erste Problem. Sobald das NLEXPORT, welches beim Build als __declspec(dllexport) definiert ist davor steht, geht nur noch der auto_unlink. Alles andere generiert boost::static asserts.
Benutze ich als beispiel safe_link, gibt es hier einen Compilerfehler:

void unlink()
   {
      BOOST_STATIC_ASSERT(( (int)boost_intrusive_tags::link_mode == (int)auto_unlink ));
      node_algorithms::unlink(static_cast<node*>(this));
      node_algorithms::init(static_cast<node*>(this));
   }

Aber okay, mit dem auto_unlink kann man sich ja abfinden. Es funkioniert so auch in meinem Programm, wenn ich das ganze mit

class ShootingManager : public boost::noncopyable
{
	typedef boost::intrusive::slist<IWeapon, boost::intrusive::constant_time_size<false> > TShotList;

   TShotList m_shots;
};

in eine Liste stecke. Keine Memory Leaks, alles in Ordnung. Fein.

Jetzt kommt das Problem:
In meiner Klasse SpriteBatcher brauche ich eine Map mit SpriteKlassen, sortiert nach ShaderId, damit ich nicht jeden Frame die ganzen Sprites erst sortieren und zusammensuchen muss:

class NLEXPORT SpriteBatcher
{
public:
	typedef boost::intrusive::slist<NLSprite, boost::intrusive::constant_time_size<false> > TSpriteListC;	
	typedef boost::ptr_map<u32, TSpriteListC> TList;

private:
  TList m_sprites;
};

Aber schon hagelt es wieder Fehler:

MSVC Compiler schrieb:

1>D:\Source\Packages\boost\boost/intrusive/slist.hpp(2088) : error C2248: 'boost::intrusive::slist_impl<Config>::slist_impl' : cannot access private member declared in class 'boost::intrusive::slist_impl<Config>'
1> with
1> [
1> Config=boost::intrusive::slistopt<boost::intrusive::detail::base_hook_traits<NightLight::NLSprite,boost::intrusive::slist_node_traits<void *>,auto_unlink,boost::intrusive::default_tag,2>,unsigned int,false,false,false>
1> ]
1> D:\Source\Packages\boost\boost/intrusive/slist.hpp(153) : see declaration of 'boost::intrusive::slist_impl<Config>::slist_impl'
1> with
1> [
1> Config=boost::intrusive::slistopt<boost::intrusive::detail::base_hook_traits<NightLight::NLSprite,boost::intrusive::slist_node_traits<void *>,auto_unlink,boost::intrusive::default_tag,2>,unsigned int,false,false,false>
1> ]
1> This diagnostic occurred in the compiler generated function 'boost::intrusive::slist<T,O1>::slist(const boost::intrusive::slist<T,O1> &)'
1> with
1> [
1> T=NightLight::NLSprite,
1> O1=boost::intrusive::constant_time_size<false>
1> ]

Kann mir wer diesen Fehler bitte erklären? Ich hab von diesem ganzen Meta Template Zeug einfach zu wenig Ahnung und bin echt am verzweifeln. Danke euch vielmals. Ansonsten werde ich wohl selbst eine single linked list schreiben müssen.
Man muss allerdings dazu sagen dass mir hier manchmal sogar der MSVC abstürzt wenn ich nicht haufenweise typedefs verwende mit der Meldung ich möge meinen Code vereinfachen.

ich kann Deine Fehler nicht nachvollziehen.

Scorcher24 schrieb:

Man muss allerdings dazu sagen dass mir hier manchmal sogar der MSVC abstürzt wenn ich nicht haufenweise typedefs verwende mit der Meldung ich möge meinen Code vereinfachen.

.. Du benutzt nicht zufällig das MS-VS6?

Gruß
Werner

D.h. wenn du Klassen schreibst die Boost.Intrusive Container als Member enthalten, dann sind diese ebenfalls nicht kopierbar.
Wieso es MSVC genau zerreisst weiss ich auch nicht genau, aber wenn du genau guckst wirst du feststellen dass er beim Compilieren des Copy-Ctor von boost::intrusive::slist auf die Schnauze fällt.

Warum geht es ohne __declspec(dllexport)? Weil der Compiler implizit definierte Funktionen (default-ctor, copy-ctor, assignment und dtor) erst dort generiert, wo sie das erste mal verwendet werden. Wenn du nie versuchst deine Klasse zu kopieren versucht er auch nie den copy-ctor zu generieren, und fliegt nie auf die Schnauze. __declspec(dllexport) ändert das Spiel allerdings, da du dem Compiler damit ja sagst er muss alle Methoden exportieren. Und MSVC exportiert dann auch implizit definierte Funktionen, d.h. er versucht sie zu definieren, und dabei würfelt es ihn.

Lösung: mach deine Klassen die Boost.Intrusive Container enthalten noncopyable.

Hmm, nur welche Lösung nehme ich dann zum vor-sortieren meiner Sprites?
Lässt sich für ptr_map kein allocator über die template parameter deklarieren der eben nicht kopiert sondern nur den Pointer übernimmt?

Oder, wenn du unbedingt willst, dann mach eine eigene Klasse/Struct, die als Member nur die Shader-ID und die Intrusive List hat. Die Objekte dieser Klasse steckst du dann in ein Intrusive Set.

OK, wenn ich so drüber nachdenke könnte das evtl. sogar Performence-Vorteile bringen, je nachdem wie das Intrusive Set implementiert ist. Müsste man ausprobieren was schneller ist.

ps.:

Aber deswegen dann auch die Fehlermeldung beim deklarieren der Map.

Die Map hatte ich erst übersehen. Dann ist mir auch klar warum MSVC die Fehlermeldung bringt. Ich dachte erst MSVC hätte selbst versucht nen Copy-Ctor für deine Klasse zu erstellen, trotz unkopierbarem Member. Und das wäre etwas seltsam gewesen

Falls es dich interessiert (wenn nicht hör auf zu lesen :p):
Ich habe einfach eine neue Klasse erstellt, NLSpriteList.
Der managed nicht nur eine Liste von Sprites, sondern auch gleichzeitig das VBO dazu. Jeder Spritelist wird ein Shader zugewiesen.

Die Überklasse dazu wird dann SpriteListBatcher heissen und diesem wird ein SpriteSheet zugewiesen. Für jedes SpriteSheet brauchts dann nen extra Batcher und für jeden Shader nen extra VBO.

Ich denke so ist das am günstigsten und stressfrei gelöst.
Jedenfalls bin ich grade von ~400 GL Calls runter auf ~100 GL Calls pro Frame.

Da geht aber noch was, ich hab noch gar nicht alles durch um das umzustellen :D.
Die Frames sind zumindest um einiges stabiler geworden ohne VSYNC.