A
Shade Of Mine schrieb:
Ich vermute ueber eine art pimpl? habe ich aber bereits erwaehnt dass das moeglich ist.
Ja, aber wenn es nur von std::exception abgeleitete Exceptions gäbe, wäre das nicht nötig gewesen:
typedef std::exception* PCppException; // mittels $HPPEMIT
class PASCALIMPLEMENTATION ECppException : public Sysutils::Exception
{
private:
System::AnsiString FTypeName;
PCppException *FException; // zeigt auf die statisch, also z.B. auf dem
// Stack allozierte innere Exception,
// die dann vom entsprechenden Handler
// destruiert würde
__fastcall ECppException(char * _TypeName, void * ExcDesc)/* overload */;
...
public:
__property PCppException StdException = {read=FCppException};
...
};
Sofern oben erwähnte Regeln existierten, wäre das dann auch in Standard-C++ machbar. Zeig mir mal, wie du das machst unter Berücksichtigung der gegenwärtigen "Zusatzfeatures", die ich für eine Beschränkung halte.
Shade Of Mine schrieb:
aber ich sehe immernoch keinen grund warum es ein design fehler ist, dass ich alles werfen darf.
Es fällt einfach unter dein "wozu braucht man das" und behindert o.g. Mechanismen.
Shade Of Mine schrieb:
ein vorteil ist, dass ich exception chaining haben kann ohne wrapper zu brauchen.
Wie das?
Shade Of Mine schrieb:
oder aber ich werfe exception ohne allokationen zu haben - da ich eine exception pre-allocaten kann und dann werfe wenn ich muss.
Das geht genauso mit std::exception-Typen.
Shade Of Mine schrieb:
kann ich problemlos haben wenn ich will.
Dann zeig mal her. Das glaube ich nämlich nicht.
Shade Of Mine schrieb:
genauso wie java, dass keine value semantik anbietet?
ich meine, es gibt ja nichtmal call by reference...
ist das auch undurchdacht?
Lies genauer. Ich sagte ja, daß es nicht undurchdacht, sondern eine evolutionäre Fehlbildung ist.
Bei Java wird das nicht undurchdacht, sondern gewollt gewesen sein. Aber ich weiß nicht, weshalb du andauernd den Vergleich mit Java forcierst. Sieh dir doch mal z.B. in Delphi die Trennung von Records (für die es z.B. Operatorenüberladungen gibt) und Klassen (die immer polymorph sind und sämtlich von TObject ableiten) an. In .NET ist das IIRC ähnlich. Das hätte man für C++ noch ein wenig ausbauen können, hätte dann mit structs die Wertesemantik wie heute, in Klassen aber z.B. standardmäßig keinen Kopierkonstruktor, standardmäßig Heap-Allokation, immer eine VTable etc.
