spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Du solltest auf jeden Fall den Artikel nochmal lesen und das Problem verstehen, das dort diskutiert wird. Hier alle möglichen Kombinationen um irgendwo ein & hinzupacken durchzuprobieren, wird dich nicht weit bringen. Rumprobieren wird dich generell nicht weit führen. Versuch einfach mal in Ruhe zu verstehen, was das Problem ist...

Zitat von »dot«

Ich verstehe ehrlich gesagt nicht, was genau das Problem damit sein soll, eine sf::Texture als Member der Klasse zu haben, die doch offenbar genau dafür gedacht ist, die Texture zu besitzen!?

Das Problem tritt auf, wenn der Besitzer kopiert wird Ich glaube das ist dir durchaus bewusst, aber die Aussage, dass du das nicht verstehst, finde ich wenig hilfreich. Ein Member vom Typ NCTexture wäre da allerdings absolut problemfrei. Bis auf dass er dann für jede Textur einen Member und eine Methode anbieten muss. Das war ja der ursprüngliche Punkt, weswegen ein einfacher NCTexture-Member als auf die Dauer unpassend beschrieben wurde.

Ich sehe aber nicht, wo unser Fragesteller hier versucht oder angedeutet hätte, dass der Besitzer irgendwo kopiert werden soll und der offensichtliche Zweck der diskutierten Klassen lässt dies auch nicht vermuten. Ich sehe absolut kein Problem mit sf::Texture als Member. Imo wäre es wesentlich sinnvoller gewesen, einfach auf die korrekte Verwendung der SFML, nämlich dass nur das sf::Sprite Member der Bullet Klasse sein sollte, während die sf::Texture dazu irgendwo zentral gehalten wird (das sf::Sprite macht doch schon automatisch das Richtige, indem es eine Referenz auf die sf::Texture hält), hinzuweisen, anstatt den offensichtlich noch sehr unerfahrenen Fragesteller hier seitenlang unnötig zu verwirren...

Genau das hatte ich getan. Was daraus wird, liegt nicht in meiner Hand. Dennoch ist es aus meiner Sicht äußerst ratsam eine sf::Texture auf jeden Fall non-copyable zu machen, damit auch versehentliches Kopieren bei falscher Verwendung durch einen Anfänger durch den Compiler von vornherein unterbunden wird. Solche Compile-Time-Checks findest sicher auch du nicht verkehrt.