type erasure und std::exception_ptr

[Sone]

Hier die Version mit Skalaren, ich hoffe ich habe nicht zu viel Boilerplate produziert: http://ideone.com/4E9YZS

Mache mich jetzt an die Zeiger-Geschichte.

[hustbaer]

Die Erweiterung auf Skalare ist trivial, das hätte ich dir schon geglaubt dass du das hinbekommst.
Interessant - aber vermutlich unmöglich - ist die Geschichte mit den Zeigern.

[Sone]

hustbaer schrieb:

Die Erweiterung auf Skalare ist trivial, das hätte ich dir schon geglaubt dass du das hinbekommst.

Ich dachte, vielleicht will das ja tatsächlich mal jemand benutzen

vermutlich unmöglich

Es ist nicht unmöglich. Denn die Idee ist logisch. Solange die Idee richtig ist, kann und muss es auch richtigen Code geben. Irgendwo da draußen ist ein sauberer, völlig standardkonformer und hübscher Code, der nur darauf wartet von mir in der IDE eingetippt zu werden.

Das hier ist eine unportable und hässliche Variante. Sie ist Implementationsspezifisch und funktioniert wahrscheinlich nicht, laut Standard ist da ebenfalls nichts garantiert (wahrscheinlich UB, könnte man aber sicher auch ohne UB hinbekommen): http://ideone.com/SShuV3

Schon auf Ideone funktioniert die Variante mit den Skalaren nicht mehr. Obwohl Ideone sogar denselben Compiler verwendet wie ich. Und bei mir klappt es. Daher: Finger weg...
Das funktioniert nur deswegen, weil die Memberfunktion before() bei einigen Compilern die Vererbung berücksichtigt.

[hustbaer]

Der Code den du da aktuell hast kann nichtmal ansatzweise funktionieren.
Denk an Mehrfachvererbung und virtuelle Vererbung.
Und natürlich braucht man auch definiertes Verhalten für den Fall dass der Zeiger nicht konvertierbar ist.

[knivil]

Was ich dazu weiss: http://www.cplusplus.com/forum/articles/18756/

Die Möglichkeit relativ unkompliziert über Basisklassen auf Objekte in Type-Erasure-Containern

Das ist wiederspruechlich: An den Typ/Basistyp von Objekten zu gelangen, deren Typ geloescht ist. Warum sollte ich dann im Vorfeld type erasure anwenden? Auch ist mir unklar, welches Problem geloest werden soll. Nein, "öfters mal nützlich sein" hatte ich noch nie, wobei das kein wirkliches Kriterium ist

Type-Erasure-Containern

Was das sind, weiss ich nicht. Container mit type erased objecten? Dann spielen nur type erased objecte 'ne Rolle und der Container ist unwichtig.

Und warum bei Sone neuerdings alles friend sein muss , ist mir auch unklar.

[Sone]

knivil schrieb:

Und warum bei Sone neuerdings alles friend sein muss , ist mir auch unklar.

Wenn du den Code nicht verstehst, dann verschwende ich nicht meine Zeit damit in dir zu erklären. Soviel sei gesagt: Die Factory braucht Zugriff auf den privaten Konstruktor. Diesen public zu machen, um deinen Ansprüchen genüge zu tun, würde dem User erlauben any_ptr irgendwie zu konstruieren... völliger Blödsinn.

[knivil]

Wenn du den Code nicht verstehst, dann verschwende ich nicht meine Zeit damit in dir zu erklären.

Und du laber mich nicht dumm von der Seite an, auch die friends in deinem Iteratorbeispiel konnten problemlos entfernt weden. Hoehenfluege?

[Sone]

knivil schrieb:

Wenn du den Code nicht verstehst, dann verschwende ich nicht meine Zeit damit in dir zu erklären.

Und du laber mich nicht dumm von der Seite an, auch die friends in deinem Iteratorbeispiel konnten problemlos entfernt weden. Hoehenfluege?

Gut, gut, gut. Tut mir Leid. Erkläre mir bitte, wie man das friend entfernen kann, ohne die Syntax beim Aufruf zu verändern oder die Konstruktoren public zu machen oder sonst irgendwas.

Ich sehe keinen Weg. Und friend ist nur ein Schlüsselwort. Solange der User eine Funktion make_any_ptr aufrufen kann, und any_ptr private Konstruktoren hat, ist doch alles im Lot.

[knivil]

Kurze Erklaerung: Es gibt gewisse Schluesselreize, die Gefahr bedeuten, beispielsweise ist "new". Gleiches gilt fuer "friend". Selbst brauche ich es sehr wenig. Bis jetzt 2 Mal insgesamt. Waehrend fuer "new" direkte Loesungsmoeglichkeiten bestehen, ist "friend" eher ein konzeptionelles Problem. Und bevor ich das angehe, wuerde ich gern wissen, warum man gerne den Typ eines type erased objects haben moechte, bzw. warum man dann in erster Linie ueberhaupt type erasure nutzt. Bei boost::variant erhaelt man das mit 'nem Visitor, ist wohl aber nicht das gesuchte.

[hustbaer]

@knivil
Ein Type Erasure Container ist sowas wie boost::any .

Und die Forderung an den Typ zu kommen ist überhaupt nicht widersprüchlich - das macht man bei Type-Erasure im Prinzip immer. Nur dass es meist hinter spezialisierten privaten Hilfs-Klassentemplates versteckt wird.

Beispiel für wo so etwas nützlich sein könnte wäre eine Registry für Objekte beliebigen Typs. Denk an Dependency Injection Frameworks o.ä. Bzw. auch einfach als Erweiterung von boost::any o.ä.

Was ich nicht verstehe, ist warum bei Fragen wie diesen oft so patzige Antworten kommen. OK, du hast keine Verwendung dafür. Fein. Noted. Kann man aber auch freundlicher sagen.

Das selbe gilt für friend . friend ist ein recht nützlicher Bestandteil von C++, der dabei hilft die Kapselung zu verstärken. Natürlich kann man auch so arbeiten als ob es friend nicht gäbe. Dann wird man friend auch nicht brauchen. Oh Wunder. Was aber nicht heisst dass man dabei unbedingt den besten Code produziert.

[knivil]

Was ich nicht verstehe, ist warum bei Fragen wie diesen oft so patzige Antworten kommen.

Zeig sie mir bitte in meinem Eingangspost. Ansonsten: Fuer geegeben Aktion habe ich mich fuer gegeben Reaktion entschieden. An anderen Tagen haette ich mich anders entschieden.

OK, du hast keine Verwendung dafür. Fein. Noted. Kann man aber auch freundlicher sagen.

Habe ich dazugeschrieben, dass das kein Kriterium. Kann man freundlich sagen, habe mich aber fuer netral entschieden. Es ist definitive nicht unfreundlich. Und zu friend habe ich mich bereits geaessert.

Ein Type Erasure Container ist sowas wie boost::any

Ich dachte boost::any ist einfach nur ein besseres void*.

Und die Forderung an den Typ zu kommen ist überhaupt nicht widersprüchlich - das macht man bei Type-Erasure im Prinzip immer.

Und meine Erfahrung widerspricht dem, deswegen habe ich ja von meiner Erfahrung berichtet. Ich verwende Type erasure im klassischen Sinn.

[hustbaer]

knivil schrieb:

Was ich nicht verstehe, ist warum bei Fragen wie diesen oft so patzige Antworten kommen.

Zeig sie mir bitte in meinem Eingangspost. Ansonsten: Fuer geegeben Aktion habe ich mich fuer gegeben Reaktion entschieden. An anderen Tagen haette ich mich anders entschieden.

OK, du hast keine Verwendung dafür. Fein. Noted. Kann man aber auch freundlicher sagen.

Habe ich dazugeschrieben, dass das kein Kriterium. Kann man freundlich sagen, habe mich aber fuer netral entschieden. Es ist definitive nicht unfreundlich.

Hab deinen (an mich gerichteten) Beitrag nochmal gelesen. Du hast Recht. Sorry. Deine Korrespondenz mit Sone hat da beim ersten mal Lesen auf meine Erinnerung an deinen ersten Beitrag hier abgefärbt.

knivil schrieb:

Ein Type Erasure Container ist sowas wie boost::any

Ich dachte boost::any ist einfach nur ein besseres void*.

Ja, pfuh. Ich weiss nicht ob Type Erasure Container ein viel verwendeter Ausdruck ist. Aber irgendwie muss man es ja nennen. Ich nenne es halt Type Erasure Container. Wie würdest du es nennen (ausser "besseres void*")?

knivil schrieb:

Und die Forderung an den Typ zu kommen ist überhaupt nicht widersprüchlich - das macht man bei Type-Erasure im Prinzip immer.

Und meine Erfahrung widerspricht dem, deswegen habe ich ja von meiner Erfahrung berichtet. Ich verwende Type erasure im klassischen Sinn.

Also ich hätte mir schon hin und wieder mal die Möglichkeit gewünscht aus nem any "Interface-Zeiger" bekommen zu können.
Oder noch besser: gleich nen dynamic_cast ausgehend von void* machen zu können.
Mir ist klar dass das nicht dem "C++ way of doing things" entspricht. Nur manchmal passt der "C++ way of doing things" nicht so gut, und der "C# way of doing things" wäre viel angenehmer für einen bestimmten Programmteil. Da nervt dann der quasi nicht-vorhandene Reflection-Support von C++ etwas.

Ich bei solchen Dingen kein Tagebuch, und da ich auch kein idetisches Gedächtnis habe, und ich mir solche Dinge zugegebenermassen nicht jeden Tag wünsche, kann ich auch kein konkretes Beispiel liefern.