Jammer-Thread

[Krishty]

Jetzt darf ich meine Datenträger nie wieder an ein Windows-XP-System anschließen. Ist ja wie eine Infektion.

So true. Seit Jahren gehört es zu meinem ersten Schritt vorm Anlegen einer Sicherheitskopie, die Ordnerstruktur zu durchsuchen und alle thumbs.db sowie die meisten desktop.ini zu löschen.

[kaiserludi]

Mir ist gerade aufgefallen, dass es den Compiler in keinster Weise stört, wenn ich eine const Instanz verändere, indem ich eine const-Methode darauf aufrufe, welche intern eine globale Funktion aufruft, die schreibend auf die Instanz zugreift. Weder VS noch Clang schmeißen auch nur ein Warning.
Argh.
Das heißt also, ich mache die Methoden const, wenn die von ihnen aufgerufenen Funktionen in der aktuellen Implementation die Objektinstanzen nicht verändern und wenn sich deren Implementation irgendwann mal ändert, bin ich gearscht, weil ich dann plötzlich ohne es zu wollen, das const umgehe, und zwar weit subtiler, als wenn man da wenigstens einen const-cast hätte :?

Code: Alles auswählen

void gFoo(int* pFoo)
{
	*pFoo = 7;
}

class Test
{
public:
	Test(void);
	~Test(void);
	void foo(void) const;
private:
	int* mFoo;
};

Test::Test(void)
{
	mFoo = new int;
}

Test::~Test(void)
{
	delete mFoo;
}

void Test::foo(void) const
{
	gFoo(mFoo);
}

int main(void)
{
	const Test test;
	test.foo();
	return 0;
}

[Biolunar]

@kaiserludi: Das ist völlig korrekt so. Das Objekt selbst wird nicht verändert, nur der Wert auf den der Zeiger zeigt (was nicht mehr in den Aufgabenbereich der Klasse fällt).

[kaiserludi]

@kaiserludi: Das ist völlig korrekt so. Das Objekt selbst wird nicht verändert, nur der Wert auf den der Zeiger zeigt (was nicht mehr in den Aufgabenbereich der Klasse fällt).

Tatsache, wenn ich aus dem int* ein int mache und dessen Adresse an gFoo weiterreichen will, gibts doch tatsächlich eine Fehlermeldung, dass ich explizit das const wegcasten muss :)

Code: Alles auswählen

void gFoo(int* pFoo)
{
	*pFoo = 7;
}

class Test
{
public:
	Test(void);
	void foo(void) const;
private:
	int mFoo;
};

Test::Test(void)
{
	mFoo = 0;
}

void Test::foo(void) const
{
	gFoo(&mFoo);
}

Das heißt aber doch leider auch, dass in dem Fall, dass der Member ein Zeiger ist, quasi niemand dafür zuständig ist, zu prüfen, ob nun auf dem Wert, auf den er zeigt, rumgeschrieben werden darf oder nicht?

[Krishty]

Zeiger implizieren keine Besitzrechte; Referenzen und direkte Instanzierung hingegen schon. Der Grund ist, dass du im Falle eines Zeigers nur den Zeiger verwaltest und nicht das Objekt dahinter. Referenzen sind hingegen völlig transparent und direkte Instanzen sowieso – dort kannst du nichts anderes verwalten als das Objekt.

[CodingCat]

Wie nahezu alles lässt sich auch ein Zeiger mit Besitzsemantik einfach in ein Template verpacken. (Muss ja irgendeinen Nutzen haben, dass ich diesen ganzen Quelltext online habe. :P)

[Schrompf]

Erkenntnis: TGA ist eigentlich ganz simpel, wenn man bemerkt hat, dass die Wikipedia-Artikel zu dessen Header einen anlügen. Das letzte Header-Byte enthält angeblich die Anzahl Bits des Alphakanals, plus ein paar Flags. Wenn man da aber korrekt "8" reinschreibt, interpretieren alle Zeichenprogramme, die ich hier dahabe, das Bild als "ohne Alpha" mit 24bit pro Pixel. Testweise also mal "7" reingeschrieben und plötzlich sehe ich meinen Alphakanal in allen Programmen.

[Lynxeye]

Einheitliche Grafiktreiber schreiben nervt manchmal ganz schön. Zwei Wochen lang ein neues Feature ausgearbeitet, lange auf meiner GeForce 7 getestet, danach noch ein bisschen Refactoring betrieben und nach dem Veröffentlichen festgestellt, dass ich damit auf der GeForce FX einiges eingerissen habe.

Letztendlich lag es daran, dass die GeForce FX einen Hardwarebug hat und deshalb nach dem Verändern des Rasterizer States der Viewport neu validiert werden muss.

[kaiserludi]

Ah, Syntaxdetails sind doch was tolles :D
JString tmp = rand(); // initialisiere einen leeren String und reserviere einen Buffer für rand() Buchstaben
JString tmp; tmp = rand() // initialisiere einen leeren String mit der default-Buffersize und speichere dann die string-representation von rand() darin

Wer hat sich ausgedacht, dass bei MyClass foo = 1 der Konstruktor MyClass(int param) aufgerufen wird, statt dem Zuweisungsoperator und warum?

[condor]

Wer hat sich ausgedacht, dass bei MyClass foo = 1 der Konstruktor MyClass(int param) aufgerufen wird, statt dem Zuweisungsoperator und warum?

Kannst den Konstruktor als explicit markieren, dann geht es nicht mehr.

[kaiserludi]

Wer hat sich ausgedacht, dass bei MyClass foo = 1 der Konstruktor MyClass(int param) aufgerufen wird, statt dem Zuweisungsoperator und warum?

Kannst den Konstruktor als explicit markieren, dann geht es nicht mehr.

Ah, sehr schön. Das liebe ich an C++: Es gibt für praktisch jedes Problem eine elegante Lösung und nicht wie bei anderen Sprachen: "Gibts nicht" :)

[dot]

Dann brauchst du aber auch einen eigenen Zuweisungsoperator für int oder einen Cast ;)

[kaiserludi]

Dann brauchst du aber auch einen eigenen Zuweisungsoperator für int oder einen Cast ;)

Den eigenen Zuweisungsoperator dafür hatte ich seit eh und je und den wollte ein Kollege aufrufen und hat stattdessen den Konstruktor aufgerufen, welcher leider etwas völlig anderes bewirkt.
War zwar schnell und leicht gefunden beim Debuggen, aber wenn der Compiler gleich meckert, wie nun dank explicit, dann ist das doch um einiges angenehmer.

[Schrompf]

Ich Will Endlich ForEach-Unterstützung In Visual Studio, verdammichnocheeinsundkruzisauerlabbenstorch! Ich habe die Nase voll von Hundert "for( auto it = bla.cbegin(); it != bla.cend(); ++it )" jeden Tag.

Was ist denn bitte das Problem dabei? Vermutlich sowas wie beim D3D Shader Compiler und diversen anderen Microsoft-Projekten... it got down-prioritized.

[simbad]

Bau dir doch ein macro :)

[Schrompf]

Bau dir doch ein macro :)

Weiche, Geist! Der Schwefelgeruch verrät Deine Absichten! Du wirst mich nicht verlocken!

Boost hat ja ein nettes ForEach, dass auch nicht ganz ohne Makro auskommt. Leider produziert jede Verwendung eine Warnung, die ich ganz ehrlich nichtmal verstehe. Und ich seh das auch gar nicht ein, wenn doch der C++11-Standard sowas doch schon vorsieht! Nur muss das halt auch vom Compilerbauer gewünscht sein. Und das wird wahrscheinlich A Single Lonesome Soul sein, während alle Entwickler zum aktuellen Visual Data Flow Construction Kit Secret Funky Project abgezogen wurden, oder wie auch immer die aktuelle Sau heißt, die vom Management mal wieder durchs Dorf getrieben wird.

[dot]

Verwend doch std::for_each() ;)

[Matthias Gubisch]

Wo wir grad beim Thema sind.

Anstatt sinnvolle Features zu entwickeln Produzieren sie Müll den kein Mensch braucht...

http://www.golem.de/1201/89181.html

[Andre]

Hab ich auch schon gesehen... Das ist so ziemlich das dümmste was ich dieses Jahr gelesen habe.

[dot]

Also ich finds lustig :D

[CodingCat]

Und wer braucht schon Variadic Templates? :P

Code: Alles auswählen

array.shift_back( new(array.allocate_back()) MyElementType(...) );

(Das ist sogar exception-safe!)

(Wow, jetzt kann ich endlich fast alle std::vector mit einer leichtgewichtigeren Klasse ersetzen.)

[eXile]

Code: Alles auswählen

array.shift_back( new(array.allocate_back()) MyElementType(...) );

Könntest du deine göttliche Eingebung noch etwas erläutern? ;)

[CodingCat]

Naja, da ist nix wildes dahinter: allocate_back() gibt einen void*-Zeiger auf das erste noch nicht konstruierte Element zurück (quasi &array[array.size()]), verändert jedoch nichts am array. Placement new konstruiert an der gegebenen Adresse ganz normal das Objekt. Fliegt keine Ausnahme, so geht der Zeiger auf das erfolgreich konstruierte Objekt zurück in shift_back(), wo er von einem assert() mit &array[array.size()] verglichen wird, bevor dort array.size() um 1 inkrementiert wird. Fliegt eine Ausnahme, so wird das Objekt dank Placement new entsprechend den Standardregeln automatisch zerstört, shift_back() wird nicht aufgerufen und array wurde rein logisch überhaupt nicht verändert.

[CodingCat]

Wahnsinn, ich habe den ganzen Tag damit verbracht, D3DX Effects 11 zu fixen. Irgendwann muss ich doch was eigenes schreiben. Heute morgen habe ich kurz darüber nachgedacht, CgFX zu integrieren, aber die sind noch nicht mal bei Compute Shaders angekommen.

[Krishty]

Fällt sonst noch wem auf, dass Visual C++' Optimizer 64-Bit Left Shifts nicht vorhersagen kann?

Finde ich schade, weil ich jetzt 18 KiB Maschinentext in meiner Exe habe, die einen Hash vorberechnen sollten aber nichts anderes tun als
000000013F22D8F3 movzx ecx,byte ptr [13F24C6E7h]
000000013F22D8FA shl rcx,8
000000013F22D8FE add rcx,rax
000000013F22D901 movzx eax,byte ptr [13F24C6E5h]
000000013F22D908 shl rcx,8
000000013F22D90C add rcx,rax
000000013F22D90F movzx eax,byte ptr [13F24C6E4h]
000000013F22D916 shl rcx,8
000000013F22D91A add rcx,rax
000000013F22D91D movzx eax,byte ptr [13F24C6E3h]
000000013F22D924 shl rcx,8
000000013F22D928 add rcx,rax
000000013F22D92B movzx eax,byte ptr [13F24C6E2h]
000000013F22D932 shl rcx,8
000000013F22D936 add rcx,rax
000000013F22D939 movzx eax,byte ptr [13F24C6E1h]
000000013F22D940 shl rcx,8
000000013F22D944 add rcx,rax

[Krishty]

1> Generating code
1>XXX.cpp(113): error C2268: '_CxxThrowException' is a compiler predefined library helper. Library helpers are not supported with /GL; compile object file 'XXX.obj' without /GL.
1>LINK : fatal error LNK1257: code generation failed

[antisteo]

1> Generating code
1>XXX.cpp(113): error C2268: '_CxxThrowException' is a compiler predefined library helper. Library helpers are not supported with /GL; compile object file 'XXX.obj' without /GL.
1>LINK : fatal error LNK1257: code generation failed

Heißt das im Klartext, man kann mit dem MSVC-Compiler nicht gleichzeitig Code mit Exceptions schreiben und externe Bibliotheken einbinden?

[eXile]

This method is included in a compiler-only file that the compiler uses to process exceptions. Do not call the method directly from your code.

Was spricht gegen eine separate Kompilierungseinheit?

[Krishty]

Heißt das im Klartext, man kann mit dem MSVC-Compiler nicht gleichzeitig Code mit Exceptions schreiben und externe Bibliotheken einbinden?

Dochdoch. Man kann sich nur nicht seine eigene Ausnahmebehandlung schreiben und sie dann interprozedural optimieren lassen.

@eXile: Du hast recht; da spricht fast garnichts gegen – ich hatte irrtümlicherweise gemutmaßt, dass ich mich wieder mit der abartigen MSIL .netmodule or module compiled with /GL found-Warnung rumschlagen müsste, die ich von Mixturen mit und ohne LTCG kenne. Es funktioniert mit einem eigenen Modul; wenn auch leider ohne Inlining.

Ein Grund zum Stänkern bleibt aber: Dieser Fehler sieht mir zu synthetisch aus. Nachdem er auftritt, läuft die Optimierung nichtsdestotrotz genau so weiter wie immer und bricht erst zu dem Zeitpunkt ab, wo sonst die Exe ausgeschrieben wird. Ich vermute, dass das einfach aus politischen statt aus technischen Gründen reingezimmert wurde.

[Artificial Mind]

rekonstruierte Tiefenwerte einer 16-Bit pro Kanal Positions-Textur vom Deferred Shading.