Jammer-Thread

[dot]

I feel you man...

[eXile]

Lulz des Tages: Windows 7 kann keine Fonts von einem Netzlaufwerk aus installieren. Es kommt keine Fehlermeldung, sondern es passiert einfach: Nichts.

[CodingCat]

Nur um sicherzugehen, dass ja niemand mehr kostenlos Windows-Desktop-Anwendungen entwickelt, wird das neue Windows SDK auch keinen Kommandozeilencompiler mehr enthalten. Und ich dachte schon, ich könnte vielleicht bei der VS 10 IDE bleiben.

[dot]

Ja, das ist in der Tat sehr traurig. Aber eben eine Marketingentscheidung um Metro zu pushen. Ich bin mir sicher dass sich das nach dem Release von Windows 8 wieder bessern wird...

[glassbear]

Jetzt bin ich von Stuttgart nach Kalifornien (San Diego) umgezogen für einen neuen Job und schon flattert mir von Google eine Email ins Haus, ob ich mich nicht bewerben will, mein CV gefällt ihnen so :?: :?: :?:

[Chromanoid]

Du Armer :)

[Krishty]

Verdammtes Visual C++ zeigt mir falsche Debug-Informationen in Release-Builds an. Jetzt muss ich zusehen, dass ich den Belastungstest irgendwie in der 20× langsameren Debug-Version wiederhole. Sind ja bloß ein paar Stunden. Super.

[eXile]

@pat_wilson @daniel_collin @twoscomplement geom shaders on OSX+AMD aren't weird, they very predictably always run on the CPU!

Sowas kann man sich nicht ausdenken.

[CodingCat]

Im Sumpf von undefined und implementation-defined behavior: Cast zwischen unverwandten Datentypen mit reinterpret_cast oder union?

Nach C-Standard wäre es union C { TypeA a; TypeB b; }; TypeB *b = &((C*)a)->b;. Im neuen C++-Standard wird diese Unterscheidung offensichtlich nicht gemacht, ich bin mir nicht Mal sicher, ob in C++ derlei nicht sogar immer undefiniertes Verhalten ist.

Da die meisten C++-Compiler auch irgendwie C-kompatibel sind, wäre man mit TypeB *b = &reinterpret_cast<C*>(a)->b; wohl auf der sicheren Seite. Tollerweise sind im aktuellen VC++ natürlich nach altem C++-Standard unions von Typen mit Konstruktoren noch nicht erlaubt, was mir letztlich nur ein direktes TypeB *b = reinterpret_cast<TypeB*>(a); lässt.

Oder sollte ich lieber zu albernen Doppelcasts wie TypeB *b = reinterpret_cast<TypeB*>( reinterpret_cast<char*>(a) ); übergehen? Der erste Cast wäre dann laut C++-Standard zwar erlaubt, der zweite isoliert ebenfalls, aber da der entstehende temporäre char-Zeiger tatsächlich weder auf ein Array von char-Objekten noch auf ein Array von TypeB-Objekten zeigt, ist die Kombination wohl ebenfalls verboten. Zumindest spricht der C++-Standard in der entsprechenden Regel immer vom Typ der Objekte, auf die gezeigt wird, und nicht vom Typ des aktuellen Zeigers auf dieselben.

Nachträgliche Anmerkung: Bezüglich erlaubt und verboten spreche ich natürlich immer von einer anschließenden Dereferenzierung des Zeigers mit dem neuen Typ.

[dot]

Cast zwischen unverwandten Datentypen mit reinterpret_cast oder union?

Die erste Frage sollte sein: Wieso überhaupt Cast zwischen unverwandten Typen? ;)

[CodingCat]

Ich glaube, diese Frage habe ich mir jetzt oft genug gestellt. ;) Ich sehe in diesem Fall keinen anderen Weg, Datenpolymorphismus zu kriegen. Letztlich handelt es sich um eine union, nur nicht um eine, die ich zentral definieren kann.

[dot]

Ich verwend dann üblicherweise einen einfachen reinterpret_cast. Denn es gibt afaik sowieso keinen Standardkonformen Weg das zu tun...

[CodingCat]

Naja, das nächste Ziel nach Standardkonformität wäre maximale Kompatibilität. gcc z.B. könnte wohl mit Strict Aliasing und einem einfachen reinterpret_cast Probleme machen. :-/

[dot]

gcc supported afaik offiziell den union Hack...

EDIT: Der portabelste Weg wäre vermutlich memcpy() über einen char Buffer, zumindest was Aliasing angeht...

[CodingCat]

Jap, gcc ist da C-konform. Ich habe es jetzt doch auf einen polymorphen "Basistyp" fester Größe reduzieren können, der einfach ein char-Array enthält. Damit dürfte ich über die Aggretationsregeln auch mit reinterpret_cast C++-standardkonform sein.

Und ja, memcpy geht wohl immer, aber in diesem Fall will ich gerade besonders performant bleiben, sonst würde ich einfach mit polymorphen Heap-Objekten arbeiten.

[dot]

Vielleicht hilft dir das was: Der neue C++ Standard garantiert dir, wenn du eine union aus POD structs hast, deren ersten x Member identisch sind, dass du immer auf diese Member zugreifen darfst.

[CodingCat]

Nein, ich habe ja gerade den klassischen union-Fall, d.h. ich will eigentlich gar nicht casten, sondern immer nur genau einen Objekttypen verwenden. Das Problem ist, dass dieser Typ dort, wo das Objekt auf den Stack gelegt werden soll, noch nicht bekannt ist, und ich deshalb ein Objekt eines Placebotyps anlegen muss, der dann erst mit Aufruf der zugehörgigen polymorphen Methode mit dem echten Objekttyp überschrieben wird. Auch nachfolgend aufgerufene polymorphe Methoden nutzen immer genau diesen Objekttypen, es ist nur eben nicht der offizielle Typ des Objekts, das auf dem Stack liegt. ;)

[dot]

Wie wäre es mit einem entsprechend großen char buffer und placement new?

[CodingCat]

Ja, genau das habe ich jetzt, nur dass der char-Buffer noch typisiert ist mit struct AbstractBlablaState { char Data[...]; };. Man muss ja das Maximum aus dem Typsystem rausholen, auch wenn man es gerade komplett hintergeht. :-P
Und ich kann natürlich nur bei der Initialisierung Placement New aufrufen, danach muss es reinterpret_cast tun. Das ist aber soweit ich weiß wohldefiniert, sobald sich in Data auch das richtige Objekt befindet.

[dot]

Du könntest das placement new in eine Funktion packen die an einen anderem Ort definiert ist, wo der Typ bekannt ist und einfach einen Zeiger auf den inkompletten Typ zurückgeben. Unter Umständen kann der Compiler dir das dann sogar komplett inlinen ;)

[CodingCat]

Hehe, ja das würde ich machen, wenn sich der Typ nicht tatsächlich zur Laufzeit ändern würde, d.h. es gibt nicht mal einen inkompletten Typen.

[dot]

Na dann einfach ein struct mit einem void* drin?

[CodingCat]

Nein, die Daten sollen ja schon auf dem Stack liegen. Besser als struct mit char-Array geht wohl nicht.

[dot]

Der char Buffer kann doch auf dem Stack liegen, der ist ja völlig unabhängig von dem Typ den du dann rumreichst um das Objekt zu referenzieren, oder?

[CodingCat]

Ja, aber wieso sollte ich noch einen zusätzlichen Typen einführen? Ein struct mit einem void-Zeiger drin enthält ja noch weniger Typinformation als ein struct mit einem char-Array. ;)

[dot]

Wieso, so wie ich das verstanden hab, soll das char Array ja nur das Objekt enthalten und keine Typinformation liefern? "Typinfo" hast du dann über das struct mit dem void* drin, dann kannst du zumindest danach Überladen etc.

Ehrlich gesagt klingt mir das alles aber überaus suspekt :P

[CodingCat]

Hier ein Schnipsel zur Illustration:

Code: Alles auswählen

struct AbstractBinderState { char Data[...]; };

AbstractBinderState binderState;

// Intern: new (binderState.Data) ActualBinderState();
effectBinder.Apply(binderState, ...);

// Intern: reinterpret_cast<ActualBinderState*>(binderState.Data);
while (effectBinder.ApplyPass(binderState, ...))
   ...;

// effectBinder ist polymorph

[dot]

Naja und wenn dein Apply jetzt in irgendeiner Form einen void* zurückliefert, kannst du den dann in ApplyPass per static_cast zurück in den richtigen Typ casten. Sollte aber mit dem reinterpret_cast auch problemlos funktionieren. Trotzdem find ich das System irgendwie merkwürdig...

[eXile]

Ein struct mit einem void-Zeiger drin enthält ja noch weniger Typinformation als ein struct mit einem char-Array. ;)

Ich bin zwar kein Held der C++-Programmierung, aber hierbei muss ich dot zustimmen; wenn du im zweiten Fall die Daten aus dem struct nie als char behandelst, sondern sofort aufgrund externer Informationen immer zu einem anderen Typen castest, haben beide Alternative exakt den gleichen Informationsgehalt über den Typ: Nämlich Null.

[CodingCat]

Wieso sollte Apply ein void* liefern? Erstens habe ich das State-Objekt doch bereits auf dem Stack, und zweitens enthält der Typ void weniger Information als der Typ AbstractBinderState?!