[gelöst] Compilerfehlerfehler C2280 bei std::vector

Programmiersprachen, APIs, Bibliotheken, Open Source Engines, Debugging, Quellcode Fehler und alles was mit praktischer Programmierung zu tun hat.

[gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon joggel » 19.02.2018, 17:29

Hallo,

Ich habe ein Problem bei einen meiner Klassen und std::vector.
Ich speicher Instanzen der Klasse Building in eine std::Vector.
Jetzt habe ich eine Membervariable (SFML::Shader) in diese Building-Klasse aufgenommen und VC++ 2017 spuckt mir diesen Compilerfehler aus.
Ich glaube, dass liegt daran, dass diese SFML::Shader-Klasse keinen Kopierkonstruktor hat.

Wie löse ich dieses Problem?

Das Problem ist ja, dass man die diese SFML::Shader-Instanz nicht einfach kopieren kann, da es ja nur eine Repräsentation eines OGL-Zustandes ist... denke ich mir mal.

Sollte ich vlt mit std::unique<SFML::Shader> arbeiten, und in meiner Buidling-Klasse einen Kopierkonstruktor schreiben, der den Eigentum dieser Instanz übernimmt?
Zuletzt geändert von joggel am 20.02.2018, 08:19, insgesamt 1-mal geändert.
CEO of Dirty Codez Production®
Benutzeravatar
joggel
Establishment
 
Beiträge: 1380
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: Compilerfehlerfehler C2280 bei std::vector

Beitragvon joggel » 20.02.2018, 08:18

Okay, ich habe sie Shader-Instanz shared_ptr gehalten, und es funktioniert.
Ich verstehe zwar nicht, wieso es nicht als unique_ptr funktioniert, aber es funktioniert erstmal...
CEO of Dirty Codez Production®
Benutzeravatar
joggel
Establishment
 
Beiträge: 1380
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon Schrompf » 20.02.2018, 08:52

Das stimmt so, wie Du das sagst: SFML::Shader hat keinen Kopierkonstruktor und ist wahrscheinlich aufgrund des Alters noch nicht move-enabled. Da wäre in der Tat ein std::unique_ptr die bessere Wahl. Was für Fehlermeldungen bekommst Du denn, wenn Du den unique_ptr im vector speichern willst? Der unique_ptr hat natürlich auch keinen Kopierkonstruktor, aber Du müsstest ihn stressfrei moven können.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Schrompf
Thomas Ziegenhagen
Moderator
 
Beiträge: 3774
Registriert: 26.02.2009, 00:44
Wohnort: Dresden
Benutzertext: Lernt nur selten dazu

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon joggel » 20.02.2018, 10:29

Ich bin mir gerade unsicher welche Fehlermeldung das war.
Ich werde es nachher noch einmal mit unique_ptr testen...
CEO of Dirty Codez Production®
Benutzeravatar
joggel
Establishment
 
Beiträge: 1380
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon joggel » 20.02.2018, 18:30

Hab ich mich doch recht erinnert.
Wenn ich die SFML::Shader Klasse als unique_pointer speicher, dann bekomme ich ebenfalls die Selbe Fehlermeldung.
Was mich halt wie gesagt etwas verwundert....
CEO of Dirty Codez Production®
Benutzeravatar
joggel
Establishment
 
Beiträge: 1380
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon dot » 20.02.2018, 18:35

In der Regel ist die tatsächliche Fehlermeldung (also das was der Compiler in deinem konkreten Code konkret ausspuckt) zusammen mit dem Stück Code das den Fehler erzeugt ungefähr 100000000% informativer als der Link zur generischen Doku des jeweiligen Compiler Error Code ohne Kontext... ;)
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1649
Registriert: 06.03.2004, 19:10

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon joggel » 20.02.2018, 18:51

Okay.
Also, ich habe jetzt einfach nur den Member der Klasse Building als unique_ptr<sf::Shader> gespeichert.
Und ich habe Instanzen der Klasse Building dann in ein std::vector<Building> gespeichert.

    1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\include\xmemory0(840): error C2280: "Building::Building(const Building &)" : Es wurde versucht, auf eine gelöschte Funktion zu verweisen
    1>f:\programmierung\projekte\game_proto\game_proto\building.h(89): note: Compiler hat hier "Building::Building" generiert
    1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\include\xmemory0(959): note: Siehe Verweis auf die Instanziierung der gerade kompilierten Funktions-Vorlage "void std::allocator<_Ty>::construct<_Objty,const _Ty&>(_Objty *,const _Ty &)".
    1> with
    1> [
    1> _Ty=Building,
    1> _Objty=Building
    1> ]
    1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\include\xmemory0(959): note: Siehe Verweis auf die Instanziierung der gerade kompilierten Funktions-Vorlage "void std::allocator<_Ty>::construct<_Objty,const _Ty&>(_Objty *,const _Ty &)".
    1> with
    1> [
    1> _Ty=Building,
    1> _Objty=Building
    1> ]
    1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\include\xmemory0(1097): note: Siehe Verweis auf die Instanziierung der gerade kompilierten Funktions-Vorlage "void std::allocator_traits<_Alloc>::construct<_Ty,const _Ty&>(std::allocator<_Ty> &,_Objty *,const _Ty &)".
    1> with
    1> [
    1> _Alloc=std::allocator<Building>,
    1> _Ty=Building,
    1> _Objty=Building
    1> ]
    1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\include\xmemory0(1096): note: Siehe Verweis auf die Instanziierung der gerade kompilierten Funktions-Vorlage "void std::allocator_traits<_Alloc>::construct<_Ty,const _Ty&>(std::allocator<_Ty> &,_Objty *,const _Ty &)".
    1> with
    1> [
    1> _Alloc=std::allocator<Building>,
    1> _Ty=Building,
    1> _Objty=Building
    1> ]
    1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\include\vector(928): note: Siehe Verweis auf die Instanziierung der gerade kompilierten Funktions-Vorlage "void std::_Wrap_alloc<std::allocator<_Ty>>::construct<_Ty,const _Ty&>(_Ty *,const _Ty &)".
    1> with
    1> [
    1> _Ty=Building
    1> ]
    1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\include\vector(928): note: Siehe Verweis auf die Instanziierung der gerade kompilierten Funktions-Vorlage "void std::_Wrap_alloc<std::allocator<_Ty>>::construct<_Ty,const _Ty&>(_Ty *,const _Ty &)".
    1> with
    1> [
    1> _Ty=Building
    1> ]
    1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\include\vector(947): note: Siehe Verweis auf die Instanziierung der gerade kompilierten Funktions-Vorlage "void std::vector<Building,std::allocator<_Ty>>::emplace_back<const _Ty&>(const _Ty &)".
    1> with
    1> [
    1> _Ty=Building
    1> ]
    1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\include\vector(947): note: Siehe Verweis auf die Instanziierung der gerade kompilierten Funktions-Vorlage "void std::vector<Building,std::allocator<_Ty>>::emplace_back<const _Ty&>(const _Ty &)".
    1> with
    1> [
    1> _Ty=Building
    1> ]
    1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\include\vector(946): note: Bei der Kompilierung von Klasse Vorlage der void std::vector<Building,std::allocator<_Ty>>::push_back(const _Ty &)-Memberfunktion
    1> with
    1> [
    1> _Ty=Building
    1> ]
    1>f:\programmierung\projekte\game_proto\game_proto\world.cpp(213): note: Siehe Verweis auf die Instanziierung der gerade kompilierten Funktions-Vorlage "void std::vector<Building,std::allocator<_Ty>>::push_back(const _Ty &)".
    1> with
    1> [
    1> _Ty=Building
    1> ]
    1>f:\programmierung\projekte\game_proto\game_proto\world.h(104): note: Siehe Verweis auf die Klasse Vorlage-Instanziierung "std::vector<Building,std::allocator<_Ty>>", die kompiliert wird.
    1> with
    1> [
    1> _Ty=Building
    1> ]
    1>f:\programmierung\projekte\game_proto\game_proto\building.h(89): note: "Building::Building(const Building &)": Die Funktion wurde implizit gelöscht, weil eine Datenmember eine Funktion "std::unique_ptr<sf::Shader,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)" aufruft, die gelöscht wurde oder auf die nicht zugegriffen werden kann.
    1> with
    1> [
    1> _Ty=sf::Shader
    1> ]
    1>c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\include\memory(1857): note: "std::unique_ptr<sf::Shader,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)": Die Funktion wurde explizit gelöscht.
    1> with
    1> [
    1> _Ty=sf::Shader
    1> ]
    1>Code wird generiert...

(Diese Formatierung, also ganz ohne, finde ich etwas übersichtlicher als die Fehlermeldung in einen Code-Tag zu packen)

Das ist das einzige was ich gemacht habe...erstmal!!

Edit:
Was mir gerade designTechnisch einfällt, und womit ich das Problem auch umgehenn könnte:
Die Shader irgendwo global halten, und dann lediglich eine refernz darauf beim zeichnen übergeben.
So lade ich ja JEDES MAL, wenn ich eine Instanz von Building erstelle, einen Shader (ist ja aber IMMER der gleiche Shader)...
CEO of Dirty Codez Production®
Benutzeravatar
joggel
Establishment
 
Beiträge: 1380
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon dot » 20.02.2018, 19:24

Naja, was hier passiert ist: std::unique_ptr ist nicht kopierbar, daher hat deine Klasse Building, in der dieser unique_ptr sich nun offenbar befindet, keinen impliziten Copy C'tor mehr...

Die Frage die du dir an dieser Stelle stellen solltest ist: Wieso genau muss Building kopiert werden? Irgendwo in deinem Programm passiert genau das jedenfalls...
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1649
Registriert: 06.03.2004, 19:10

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon joggel » 20.02.2018, 19:36

Aha, okay. Verstehe.

Nun habe ich mir einen Zuweisungsoperator implementiert, damit dieser beim Copy C'tor aufgerufen wird.
(Ich brauch ja nicht explizit einen Copy C'tor schreiben).

Und zwar schreibe ich so etwas:
Code: Ansicht erweitern :: Alles auswählen

Building& Building::operator=(const Building& otherBuilding)
{
        if (this != &otherBuilding)
        {
                mFragShader = otherBuilding.getFragShader();
        }
        return *this;
}
 


Meine getFragShader-Funktion sieht ganz simpel aus:
Code: Ansicht erweitern :: Alles auswählen

std::unique_ptr<sf::Shader> getFragShader() const { return std::move(mFragShader); }
 


...ABER, es wird mir folgende Fehlermeldung ausgespuckt (ausgelöst durch den Inhalt in meiner getFragShader-Funktion) :
    Schweregrad Code Beschreibung Projekt Datei Zeile Unterdrückungszustand
    Fehler (aktiv) E1776 Auf "Funktion "std::unique_ptr<_Ty, _Dx>::unique_ptr(const std::unique_ptr<_Ty, _Dx>::_Myt &) [mit _Ty=sf::Shader, _Dx=std::default_delete<sf::Shader>]" (deklariert in Zeile 1857 von "c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\include\memory")" kann nicht verwiesen werden (ist eine gelöschte Funktion).

    Game_Proto f:\Programmierung\Projekte\Game_Proto\Game_Proto\Building.h 81
    Fehler C2280 "std::unique_ptr<sf::Shader,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)" : Es wurde versucht, auf eine gelöschte Funktion zu verweisen Game_Proto f:\programmierung\projekte\game_proto\game_proto\building.h 81


Edit:
Die Frage die du dir an dieser Stelle stellen solltest ist: Wieso genau muss Building kopiert werden? Irgendwo in deinem Programm passiert genau das jedenfalls...

Ja, genau. Und zwar wenn ich eine Instanz von Building in den std::vector per push_back speicher. Da wird doch die Instanz kopiert, oder?
Oder wäre es da schlauer, diese Instanzen auch gleich als std::unique_ptr oder std::shared_ptr zu speichern?

Edit 2:
Wenn ich so darüber nachdenke, ist das ja auch vollkommen "schwachsinnig"!!! Bei meinem kopieren (getFragShader()) wird der Besitz des Objektes FragShader ja "verschoben" (std::move(...)), so das der ursprüngliche Eigentümer das nicht mehr verwenden kann. Aber bei einer Kopie(!!!), bei der das Original ja noch erhalten werden soll, ist das ja total tödlich!!
CEO of Dirty Codez Production®
Benutzeravatar
joggel
Establishment
 
Beiträge: 1380
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon MasterQ32 » 20.02.2018, 22:15

Joggel: Wie erstellst du dein Building im Vektor?

Es gibt grob gesagt drei Möglichkeiten:
Code: Ansicht erweitern :: Alles auswählen

std::vector<Building> vec;

// a)
Building b(foo);

vec.push_back(b);

// b)
vec.push_back(Building(foo));

// c)
vec.emplace_back(foo);
 


Bei a) und b) werden ein Copy-Constructor benötigt, bei c) nicht. Wenn du push_back nutzt, brauchst du zwangsweiße einen copy-ctor, bei emplace_back nicht (das erstellt dein objekt direkt im vektor und kopiert es nicht in den vektor)
Wer checkt diese Shaderprogrammierung denn?
JCL: Kein Mensch zwingt Sie jedoch, mit Shadern oder ueberhaupt mit Gamestudio zu arbeiten. Es gibt schliesslich auch andere schoene Hobbies, wie zum Beispiel das Sammeln von Bierdeckeln – JCL quotes
Benutzeravatar
MasterQ32
Felix Queißner
Establishment
 
Beiträge: 1204
Registriert: 07.10.2012, 14:56

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon joggel » 21.02.2018, 08:19

Ich erstelle es wie a).

Danke, ich glaube das löst mein Problem auf die optimalste Weise!!
CEO of Dirty Codez Production®
Benutzeravatar
joggel
Establishment
 
Beiträge: 1380
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon Schrompf » 21.02.2018, 08:29

Nein. a) bis c) funktionieren weiterhin nicht. push_back() kopiert das Objekt, emplace_back() kopierkonstruiert es. Dort muss ein std::move() rein, oder das wird gar nix.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Schrompf
Thomas Ziegenhagen
Moderator
 
Beiträge: 3774
Registriert: 26.02.2009, 00:44
Wohnort: Dresden
Benutzertext: Lernt nur selten dazu

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon MasterQ32 » 21.02.2018, 08:45

Ich muss dich enttäuschen, Schrompf, aber emplace_back ruft normalerweise placement new auf:
Appends a new element to the end of the container. The element is constructed through std::allocator_traits::construct, which typically uses placement-new to construct the element in-place at the location provided by the container. The arguments args... are forwarded to the constructor as std::forward<Args>(args)....

...

The following code uses emplace_back to append an object of type President to a std::vector. It demonstrates how emplace_back forwards parameters to the President constructor and shows how using emplace_back avoids the extra copy or move operation required when using push_back.


http://en.cppreference.com/w/cpp/contai ... place_back

Daher ist c) tatsächlich die korrekte Vorgehensweise, um move-only objekte in einem vektor zu konstruieren
Wer checkt diese Shaderprogrammierung denn?
JCL: Kein Mensch zwingt Sie jedoch, mit Shadern oder ueberhaupt mit Gamestudio zu arbeiten. Es gibt schliesslich auch andere schoene Hobbies, wie zum Beispiel das Sammeln von Bierdeckeln – JCL quotes
Benutzeravatar
MasterQ32
Felix Queißner
Establishment
 
Beiträge: 1204
Registriert: 07.10.2012, 14:56

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon dot » 21.02.2018, 11:40

b) und c) funktionieren beide, bei a) muss ein move rein, dann klappt das auch.
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1649
Registriert: 06.03.2004, 19:10

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon Schrompf » 21.02.2018, 12:11

Hm. Korrigiere mich, wenn ich falsch liege, aber nach meinem Verständnis konstruiert emplace_back() das Objekt im Array anhand der übergebenen Parameter. In diesem Fall würde c) also so aussehen:

Code: Ansicht erweitern :: Alles auswählen
Foo f;
vector.emplace_back(f); // calls Foo::Foo(const Foo&)
 


Und das dürfte der Kopierkonstruktor sein. Den Move-Konstruktor darf er nicht benutzen, weil Foo f einen Namen hat und demzufolge keine RValue sein kann.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Schrompf
Thomas Ziegenhagen
Moderator
 
Beiträge: 3774
Registriert: 26.02.2009, 00:44
Wohnort: Dresden
Benutzertext: Lernt nur selten dazu

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon joggel » 21.02.2018, 12:20

Also... ich habe es gerade mal getestet.
Und so weit ich das in meinem Code korrekt gemacht habe (anstatt Building bldng = Building(); vec.push_back(bldng ) habe ich geschrieben vec.emplace_back(), da keine Argumente dem C'tor übergeben werden), bekomme ich wieder diese Fehlermeldung, wenn ich die sf::Shader-Klasse als Member in meine Building-Klasse aufnehme.

Edit:
Gerade etwas gegoogelt. Sollte ich vlt so einen Move-Konstruktor implementieren?
Na toll... dieser Move-C'tor scheint die Lösung meines Problems zu sein...
Ach verdammt!! Da habe ich ja wieder das Problem, das SFML (sf::Shader) nicht move-fähig ist :x
Zuletzt geändert von joggel am 21.02.2018, 12:36, insgesamt 1-mal geändert.
CEO of Dirty Codez Production®
Benutzeravatar
joggel
Establishment
 
Beiträge: 1380
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon dot » 21.02.2018, 12:35

Ich denk, an dieser Stelle ist es das Beste, dich auf das hier zu verweisen: http://thbecker.net/articles/rvalue_ref ... on_01.html

Das sollte helfen das Problem zu verstehen und zu einer Lösung zu kommen. Das soll nicht heißen dass ich dir keine Antwort geben will, aber einfach nur den richtigen Code hinzuschreiben wird dir viel weniger helfen als dieser Artikel... ;)

Edit: Du brauchst keinen Move Constructor implementieren, der implizite Move Constructor sollte hier völlig ausreichend sein (sofern dein Building nicht irgendwelche anderen merkwürdigen Member hat).
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1649
Registriert: 06.03.2004, 19:10

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon joggel » 22.02.2018, 10:42

Erstmal danke für den Link. Ich muss mich da mal etwas intensiver beschäftigen. Auch mit den ganzen neuen Features von C++, bin noch im Jahr '99 ;) ^^

Meine Lösung:
Ich habe einen move-operator implementiert
Code: Ansicht erweitern :: Alles auswählen

Building& Building::operator=(Building&& building)
{
        if (this != &building)
        {
                mShader = building.moveShader();
        }
        return *this;
}
 

moveShader sieht wie folgt aus:
std::unique_ptr<sf::Shader> moveShader() { return std::move(mShader); }


Dann habe ich explizit einen move-C'tor erstellen müssen(!):
Code: Ansicht erweitern :: Alles auswählen

        Building(Building&& otherBuilding)
        {
                *this = std::move(otherBuilding);
        }
 


Das Speichern einer Building-Instanz im std::vector habe ich wie folgt realisiert:
vec.push_back(Building());


Es scheint nun zu funktionieren. Ich hoffe das ist eine/die saubere Lösung, und kein dreckiger "Hack"...

Was mich aber etwas an diesem Desgin stört, sofern dies eben der gängige weg ist, ist dass ich dadurch solche öffentlichen Funktionen wie Building::moveShader haben muss, die ja keinerlei Sinn haben, außer eben für std::move(..). Das zerstört, nach meinem geschmack, mir etwas das Design; denn alle Funktionen der zB Building-Klasse sollten ja auch nur Aufgaben erfüllen die typisch für ein Building (Gebäude) sind, und nicht irgend eine Aufgabe erfüllen, die zB dafür da sind, um eine Instanz korrekt in einem std::vector zu speichern....
Aber okay, vlt ist das hier der Fall, weil diese konkrete Klasse (sf::shader) noch nicht für die move-semantik ausgelegt ist.
CEO of Dirty Codez Production®
Benutzeravatar
joggel
Establishment
 
Beiträge: 1380
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon Schrompf » 22.02.2018, 11:19

Also erstmal: Designproblem - den Shader als Instanz in Building zu haben impliziert Besitz. Das heißt, jedes Building hat seinen eigenen Shader. Willst Du das überhaupt? Shader sind für mich Helfer beim Rendering, also üblicherweise im Besitz des Renderers oder einer irgendwie gearteten Ressourcenverwaltung. Das Building hat bestenfalls einen Verweis (Referenz oder Zeiger) auf den Shader, den es benutzen will. Und dann erledigt sich der ganze Move-Kram eh.

Zweitens: Du bist in einer Member Function. Du musst keine öffentliche Funktion bauen, nur um an den Shader der anderen Building-Instanz ranzukommen. Du kannst dem einfach direkt in die Karten greifen. Und da das der Move-Konstruktor ist, weißt Du auch mit Sicherheit, dass das andere Objekt danach stirbt. Eine Move-Zuweisung sieht also üblicherweise so aus:

Code: Ansicht erweitern :: Alles auswählen
Building& Building::operator = (Building&& b) {
  mShader = b.mShader;
  b.mShader = nullptr;
}
 


Den Selbsttest kannst Du meiner Meinung nach knicken. Irgendwelche Buchautoren konstruieren da elaborierte Use Cases für den Fall, dass irgendein Trottel mal a = a; schreibt, aber ganz ehrlich: wie blöd muss man für sowas sein. Und wie verzweifelt als Programmierer, damit man Runtime-Performance verbrennt, nur um so einen exotischen Quatschfall abzufangen.

Drittens: wenn Du einen Move-Zuweisungsoperator schreibst, solltest Du auch immer auch einen Move-Konstruktor schreiben. Da gilt das Gleiche wie für Kopierkonstruktor / Zuweisung: hast Du das eine, willst Du quasi zwangsweise auch das andere haben.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Schrompf
Thomas Ziegenhagen
Moderator
 
Beiträge: 3774
Registriert: 26.02.2009, 00:44
Wohnort: Dresden
Benutzertext: Lernt nur selten dazu

Re: [gelöst] Compilerfehlerfehler C2280 bei std::vector

Beitragvon joggel » 22.02.2018, 12:08

Ja, stimmt. Das mit dem Selbsttest ist schwachsinn...entstand durch copy&paste.
Das ich auf private membervariablen einer anderen Instanz zugreifen kann ist mir jetzt neu...werd ich testen.
Die Designfrage mit dem shader: das zeichnen, die Sprite(s) und sonst noch halte ich alle in der Klasse.
Also in meinem fall ist die klasse eine repräsentation der Logik UND Grafik. Der Shader findet eben auch nur beim Gebäude verwendung.
Man kann sich da streiten was besser ist. Klar, performanter und resourcen-sparender wäre es wenn man sowas in einer Resourcenverwaltung auslagert...aber hier für diesen kleinen Anwendungsfall hielt ich das für übertrieben... "Nur ein kleines Spiel". Außerdem gibt es vlt maximal 3 gebäude auf der Karte...

Danke Dir erstmal.

Edit:
Tatsache!! Ich kann auf die privaten Member einer fremden Instanz zugreifen...
CEO of Dirty Codez Production®
Benutzeravatar
joggel
Establishment
 
Beiträge: 1380
Registriert: 06.11.2007, 19:06
Wohnort: Dresden


Zurück zu Programmiersprachen, Quelltext und Bibliotheken

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste