Vortrag über Ideen für eine neue Sprache für Spieleentwickler [youtube]

Ethon

volkard schrieb:

Ja, auch ein Punkt, den ich doof finde: Objekte wegmoven, ohne daß der Bezeichner verschwindet. Ich hätte gerne
ding.foo();
aufruf(move(ding));
//ding.foo();//gäbe compilerfehler

Hmm:

if(random() % 2)
    foo(move(bar));
bar.foobar();

Marthog

Ethon schrieb:

Hmm:

if(random() % 2)
    foo(move(bar));
bar.foobar();

Wie in Rust: Sobald es auch nur einen Weg gibt, auf dem ein Objekt uninitialisiert ist oder weggemoved wurde, gibt es einen Compilerfehler. Der Programmierer hat dann sicherzustellen, dass es bei allen Wegen gueltig ist. In deinem Beispiel koennte man z.B. ein else einbauen oder ein neues Objekt erzeugen.

EDIT: In C++ sind alle Methodenaufrufe von Standardklassen ausser die pointer undefiniertes Verhalten, wenn das Objekt weggemoved wurde und nicht neu zugewiesen wurde.

volkard

Ethon schrieb:

volkard schrieb:
Ja, auch ein Punkt, den ich doof finde: Objekte wegmoven, ohne daß der Bezeichner verschwindet. Ich hätte gerne
ding.foo();
aufruf(move(ding));
//ding.foo();//gäbe compilerfehler
Hmm:
if(random() % 2)
    foo(move(bar));
bar.foobar();

Verboten. Auch nach geiftem move ist der Bezeichner weg. Wer sowas machen will, darf smartpointers/optional etc nehmen.

Kellerautomat

Und was machst du dann mit Membern?

volkard

Kellerautomat schrieb:

Und was machst du dann mit Membern?

Auch wegwerfen, wie üblich.

Kellerautomat

struct Foo
{
        string s;
        string t;

        void f()
        {
                string throwaway = move(s);
                void(throwaway);
        }

        void g()
        {
                cout << s;
        }
};

Foo foo;
foo.f();
foo.g(); // error, objekt tot?
f.s = ...; // nope
f.t = ...; // ok/error?

Und was, wenn ich das Objekt wiederbenutzen will? Und wie siehts aus, wenn es gar keinen Namen fuer das Objekt gibt?

volkard

Du stellt Dich jetzt aber störrisch.

Members aus einem lebenden Objekt kann man nicht wegmoven.

Wenn Du es wiederbenutzen willst, dann willste es nicht wegmoven.

Wenn keinen Namen fürs Objekt gibt, ist es Dir doch egal. Der Compiler destruiert es ganz normal am Ende des Ausdrucks, außer es wurde schon im Ausdruck weggemovet.

Kellerautomat

volkard schrieb:

Members aus einem lebenden Objekt kann man nicht wegmoven.

Warum nicht? Unnoetige Beschraenkung.

volkard schrieb:

Wenn Du es wiederbenutzen willst, dann willste es nicht wegmoven.

Oh doch. Ein ServerSocket hat einen ClientSocket als Member und akzeptiert da Verbindungen mit. Sobald eine Verbindung da ist, wird der ClientSocket weggemoved und neu verwendet fuer die naechste Verbindung. Das ganze natuerlich Async.

volkard schrieb:

Wenn keinen Namen fürs Objekt gibt, ist es Dir doch egal. Der Compiler destruiert es ganz normal am Ende des Ausdrucks, außer es wurde schon im Ausdruck weggemovet.

vector<Movable> v;
move(v[0]);
v[0]; // ???

volkard

Kellerautomat schrieb:

volkard schrieb:

Members aus einem lebenden Objekt kann man nicht wegmoven.

Warum nicht? Unnoetige Beschraenkung.

Damit man es nicht nötog hat, überhaupt von toten Objekten auszugehen.
Wer evtl tote Objekt haben mag nimmt smartpointers oder boost::optional oder sowas.

Kellerautomat schrieb:

volkard schrieb:

Wenn Du es wiederbenutzen willst, dann willste es nicht wegmoven.

Oh doch. Ein ServerSocket hat einen ClientSocket als Member und akzeptiert da Verbindungen mit. Sobald eine Verbindung da ist, wird der ClientSocket weggemoved und neu verwendet fuer die naechste Verbindung. Das ganze natuerlich Async.

Eben da nimmste smartpointers oder boost::optional oder sowas.

Kellerautomat schrieb:

volkard schrieb:

Wenn keinen Namen fürs Objekt gibt, ist es Dir doch egal. Der Compiler destruiert es ganz normal am Ende des Ausdrucks, außer es wurde schon im Ausdruck weggemovet.
vector<Movable> v;
move(v[0]);
v[0]; // ???

Auch nicht möglich.

Kellerautomat

volkard schrieb:

Eben da nimmste smartpointers oder boost::optional oder sowas.

Also eine unnoetige Allokation oder semantisch komplett falsche Klasse weil... volkard das so besser gefaellt?

volkard schrieb:

Auch nicht möglich.

Und das wird wie verhindert? Woher weiss der Compiler, ob v[0] gerade gueltig ist oder nicht?

volkard

Kellerautomat schrieb:

volkard schrieb:

Eben da nimmste smartpointers oder boost::optional oder sowas.

Also eine unnoetige Allokation oder semantisch komplett falsche Klasse weil... volkard das so besser gefaellt?

Nur das, was jetzt soo viele Klassen innendrin selber machen müssen, um movable zu sein.

Kellerautomat schrieb:

volkard schrieb:

Auch nicht möglich.

Und das wird wie verhindert? Woher weiss der Compiler, ob v[0] gerade gueltig ist oder nicht?

Es kann nicht ungültig sein. :p

Kellerautomat

audacia schrieb:

Das ist ja lustig. Und wenn die Exceptions anders hießen, würdest du dich evtl. überwinden, sie zu verwenden, anstatt sie von Hand nachzubauen?

Noe. Ich will n Feature, das die guten Faelle von Exceptions erlaubt, waehrend es die schlechten verhindert.

volkard schrieb:

Nur das, was jetzt soo viele Klassen innendrin selber machen müssen, um movable zu sein.

Also extra Arbeit, weil volkards move sowas nicht erlaubt.

volkard schrieb:

Es kann nicht ungültig sein. :p

Was soll das denn jetzt heissen? Willst du v[0] einfach ungueltige Syntax machen oder was?

Und zu dem read-Problem: Da koennte man dann eigentlich uninitialized verwenden, dann brauchst du keinen Default Ctor. Vielleicht haste dann Recht, was Entities angeht. Da kann man auch uninitialized nehmen.

volkard

Kellerautomat schrieb:

volkard schrieb:

Nur das, was jetzt soo viele Klassen innendrin selber machen müssen, um movable zu sein.

Also extra Arbeit, weil volkards move sowas nicht erlaubt.

Die Vorteile würden überwiegen.

Kellerautomat schrieb:

volkard schrieb:

Es kann nicht ungültig sein. :p

Was soll das denn jetzt heissen? Willst du v[0] einfach ungueltige Syntax machen oder was?

v[0] gäbe eine normale referenz zurück. also kann man das nicht wegmoven.

audacia

Kellerautomat schrieb:

audacia schrieb:

Das ist ja lustig. Und wenn die Exceptions anders hießen, würdest du dich evtl. überwinden, sie zu verwenden, anstatt sie von Hand nachzubauen?

Noe. Ich will n Feature, das die guten Faelle von Exceptions erlaubt, waehrend es die schlechten verhindert.

Bei "Fälle von Exceptions" geht es dir aber doch um Anwendungsszenarios, oder? Ansonsten verstehe ich nicht, wo du da in der Semantik eine Unterscheidung vornehmen willst. Kannst du das mal ausführen?

volkard schrieb:

v[0] gäbe eine normale referenz zurück. also kann man das nicht wegmoven.

Und was ist dann hier:

Movable u;
Movable v[10];
move (u); // u ist fortan unberührbar
move (v[rand () % 10]); // ...und v?

Gerade sowas brauche ich ja, wenn ich meinen eigenen Vector implementiere.

Kellerautomat

volkard schrieb:

v[0] gäbe eine normale referenz zurück. also kann man das nicht wegmoven.

Ok. D.h. eine normale Referenz kann man nicht moven, weil man nur Observer ist. Das ergibt sogar Sinn. Aber wie willst du dann Objekte wieder aus einem vector rausbekommen, wenn man ihn nicht mehr braucht?

volkard

Kellerautomat schrieb:

volkard schrieb:

v[0] gäbe eine normale referenz zurück. also kann man das nicht wegmoven.

Ok. D.h. eine normale Referenz kann man nicht moven, weil man nur Observer ist. Das ergibt sogar Sinn. Aber wie willst du dann Objekte wieder aus einem vector rausbekommen, wenn man ihn nicht mehr braucht?

resize, clear, überschreiben.

Kellerautomat

volkard schrieb:

resize, clear, überschreiben.

Ich meine aus Sicht des Users. Ich will das Objekt aus dem vector wieder zurueck.

Kellerautomat

audacia schrieb:

Bei "Fälle von Exceptions" geht es dir aber doch um Anwendungsszenarios, oder?

Korrekt.

audacia schrieb:

Ansonsten verstehe ich nicht, wo du da in der Semantik eine Unterscheidung vornehmen willst. Kannst du das mal ausführen?

Das versuche ich gerade herauszufinden. Wo ist die Linie, wo Exceptions falsch sind? Ich kann schwer komplett gegen Exceptions argumentieren, wenn ich sie selbst in manchen Faellen verwendet habe. Die Frage ist, was unterscheidet meine Faelle von denen anderer Leute? Gibt es Regeln, denen man folgen kann, um ein Programm zu schreiben, das Exceptions 100%-ig richtig verwendet? Kann man ein Feature bauen, das genau auf diese Faelle zugeschnitten ist?

volkard

audacia schrieb:

volkard schrieb:

v[0] gäbe eine normale referenz zurück. also kann man das nicht wegmoven.

Und was ist dann hier:
Movable u;
Movable v[10];
move (u); // u ist fortan unberührbar
move (v[rand () % 10]); // ...und v?
Gerade sowas brauche ich ja, wenn ich meinen eigenen Vector implementiere.

Ich denke eher an

vector<ifstream> streams;
streams.emplace_back("c:/autoexec.bat");
move(streams[0]);//geht nicht

vector<movable<ifstream>> streams;
streams.emplace_back("c:/autoexec.bat");
move(streams[0]);//geht
streams[0]->close();//absturz, selber schuld

ifstream in("c:/autoexec.bat");
move(in);//geht
//in ist jetzt weg. 
in.close();//compilerfehler

volkard

Kellerautomat schrieb:

volkard schrieb:

resize, clear, überschreiben.

Ich meine aus Sicht des Users. Ich will das Objekt aus dem vector wieder zurueck.

Anschauen kannste es jederzeit. Rausmoven? Hmm, könnte mir sogar Algos vorstellen, wo man das machen will.
Zur Not damit keine toten Objekte im vector verbleiben müssen eine Methode.

ifstream meiner=v.erase_move(rand()%10);

Und wer die Gefahr liebt

ifstream meiner=move(move_cast(v[0]));
//bald kackt hier was abm außer ich repriere es schnell. 
new(&v[0]) ifstream("/dev/urandom");