ZFX + Developia

Verfasst: **11.04.2012, 14:11**

if( a || b && c) führt unter GCC zu einem Warning, ich solle doch && klammern, damit keiner die korrekte Operatorreihenfolge wissen muss, um den Code zu verstehen :roll:
Mann kann es auch echt übertreiben, genauso wie der Blödsinn, if(a = b) mit einem Warning für ein potentiell vergessenes zweites = zu bestrafen.

Verfasst: **11.04.2012, 14:23**

kaiserludi hat geschrieben:if( a || b && c) führt unter GCC zu einem Warning, ich solle doch && klammern, damit keiner die korrekte Operatorreihenfolge wissen muss, um den Code zu verstehen :roll:
Mann kann es auch echt übertreiben, genauso wie der Blödsinn, if(a = b) mit einem Warning für ein potentiell vergessenes zweites = zu bestrafen.

Ganz ehrlich, die Klammern sind die ersparte Debug-Mühe wert (nein, "ich mach das mit Absicht weil ich das Verhalten genaustens kenne" ist keine Ausrede, man programmiert ja nicht immer in Top-Form und ist häufig auch nicht der einzige Code-Mitleser ;) )

Nachtrag: Selbst die "signed-unsigned comparison" Warnings finde ich mittlerweile gut ...

Nachtrag 2: nicht überzeugt? nimm -w

Verfasst: **11.04.2012, 14:47**

Diese Warnings führen eben dazu, dass man dann 2 Dutzend Klammern am Stück hat und erst mal zählen muss, um zu sehen, was der Code macht.
Da bin ich klar für "nicht mehr Klammern als nötig".

Als nächstes bekomme ich ein Warning für while(i --> 0), dass ich doch bitte while((i --) > 0) schreiben soll, damit niemand wissen muss, dass das kein goes to Operator ist...

-w ist auch keine Lösung, weil man die Warnings teils nur Gruppenweise ein- und ausschalten kann.

Verfasst: **11.04.2012, 15:18**

Nein kann man nicht :). Ich habe mehr als einmal nach Fehlern gesucht, die von solchen Konstrukten ausgelöst wurden und freue mich immer sehr über eine solche Warnung.

Gruß Kimmi

Verfasst: **11.04.2012, 21:22**

Ich hasse die Situationen, wenn man nur die Wahl zwischen WIP Commits (sprich, irgendwas mit known Bugs, Builderrors, etc. einchecken) und einem riesigen "Änderungen aus 160 Arbeitsstunden"-Commit hat. Habe heute 6 Stunden nur mit Tippen der Commit-Messsage und dem Review, was ich alles geändert habe und somit in die Commit Message sollte, verbracht.

Verfasst: **14.04.2012, 13:19**

Forward Declarations ... nicht nur, dass ich sie in C++ stets selbst schreiben muss, und die redundanten Signaturen in den Headers damit permanent veralten. Nein, es existiert nicht mal eine prüfbare Verbindung zwischen Vereinbarung und Definition. Das heißt, ich merke nicht mal, dass sie veralten. Erst wenn mir völlig überraschend die Linkerfehler nur so um die Ohren fliegen, dann darf ich mich endlich auf die Suche begeben.

Verfasst: **14.04.2012, 14:42**

Ja, wieso eigentlich? Gibt es dafür einen Grund? Ich meine, durch explizite forward-declarations findet der Compiler Fehler, wenn man sich beim Typnamen vertippt. Aber ob das den ganzen Ärger damit wert ist, weiß ich nicht. Zusätzliche Infos bekommt der Compiler ja nicht, von daher müssten die doch eigentlich unnötig sein...

Verfasst: **14.04.2012, 15:28**

Vermutlich, weil die C- und noch vielmehr die daraus abgeleitete C++-Syntax und -Grammatik dermaßen mehrdeutig sind, dass eine notwendigerweise aufwändige inkrementelle Übersetzung dieses unzertrennlichen Breis aus Typ-, Variablen- und Funktionsbezeichnern ganz Microsoft die nächsten 30 Jahre beschäftigen könnte.

Verfasst: **17.04.2012, 11:21**

Will auch mal jammern:
Habe gestern in meiner Klasse, geerbt von QDialog, etwas mit Sonderzeichen rumgespielt.
Funktionsnamen bestanden dann aus hübsch anzusehenden Sonderzeichen und ich konnte meiner kreativität im Umgang mit dem Syntax freien lauf lassen... war zwar von fast keinem Menschen mehr zu verstehen, da fast alles nur noch aus Symbolen bestand aber ich fands toll :P .

Jedenfalls, der Metaobject-Compiler (moc.exe) von Qt kam damit aber nicht so richtig klar... er hatte mir immer eine leere "moc_" Datei generiert.
Also: Aufpassen Leute!!

Ich ärgere mich aber!! Ja... ich finde es sehr sehr schade!
Ich würde gerne meine Klassen und/oder Funktionen zB so benennen "whosMyCurrent★(★Base* ☼)" oder was weiß ich wie. Halt schön symbolisch ^^

Je länger ich programmiere desto mehr werde ich enttäuscht :(

Verfasst: **17.04.2012, 12:11**

Ich glaube, der Qt-Moccer erwartet UTF8. Das musst Du bei Visual Studio erst unter "Erweiterte Speicheroptionen" für jede Datei einzeln auswählen. Oder ein Massen-Konvertierungstool benutzen - ich hab moderat gute Erfahrungen mit UTFCast gemacht. Leider hat die Pfeiffe nicht erkennt, dass manche Files schon UTF8 ohne Header waren und mir daher UTF8-Characters doppelt konvertiert. Und ich wunder mich, warum der Fontrenderer des Frameworks keine Umlaute mehr ausspuckt.

Verfasst: **18.04.2012, 11:49**

An manchen Tagen schlägt C++ mit Wucht.
Code: Alles auswählen
struct entry;

typedef std::map<const resource*, entry> resource_map;
typedef std::map<utf8_string, resource_map::iterator> string_map;

struct entry
{
   string_map::iterator itByName;
   string_map::iterator itByFile;

   [...]
};
Vielleicht (hoffentlich) bin ich auch einfach nur übermüdet, aber ich sehe keine Möglichkeit, den Quelltext in eine gültige Reihenfolge zu bringen.

Anmerkung: Ausgelagert in [C++] Spaß mit zyklischen Abhängigkeiten.

Und gleich hinterher: Wahnsinn, ist der Moderationsbereich ein Krampf. ;)

Verfasst: **19.04.2012, 16:45**

GCC 4.7 hat geschrieben:interner Compiler-Fehler: Segmentation fault
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es
dienlich ist.
Fehler in der deutschen Übersetzung sind an translation-team-de@lists.sourceforge.net zu melden.

Gehen Sie gemäß den Hinweisen in <http://gcc.gnu.org/bugs.html> vor.

Verfasst: **19.04.2012, 17:06**

Code: Alles auswählen

int main(void)
{
	static JString gameName(L"Hello World");
}

führt zu einem Memory Leak in Marmalade.

Code: Alles auswählen

int main(void)
{
	JString gameName(L"Hello World");
}

hingegen verursacht keines.

-> static locals, deren Konsturktoren Speicher auf dem Heap allokieren, führen zu false positives im Marmalade Memoy Managment, weil ihre Destruktoren erst aufgerufen werden, nachdem der Memory Manager das Programm als beendet ansieht und jeglichen noch allokierten Speicher als Leak.

Verfasst: **19.04.2012, 18:43**

kaiserludi hat geschrieben:weil ihre Konstruktoren erst aufgerufen werden, nachdem der Memory Manager das Programm als beendet ansieht

Destruktoren, oder?

Seit ich weiß, dass in C++ die statische Initialisierungsreihenfolge zumindest für einzelne Übersetzungseinheiten definiert ist, bin ich immer mehr versucht, eine static.cpp zu machen, in der alle globalen Symbole, die in allen anderen Einheiten als extern landen, in sinnvoller Reihenfolge definiert werden. Aber noch hatte ich dazu nicht den Mumm.

Verfasst: **19.04.2012, 19:02**

Krishty hat geschrieben:
kaiserludi hat geschrieben:weil ihre Konstruktoren erst aufgerufen werden, nachdem der Memory Manager das Programm als beendet ansieht
Destruktoren, oder?

Seit ich weiß, dass in C++ die statische Initialisierungsreihenfolge zumindest für einzelne Übersetzungseinheiten definiert ist, bin ich immer mehr versucht, eine static.cpp zu machen, in der alle globalen Symbole, die in allen anderen Einheiten als extern landen, in sinnvoller Reihenfolge definiert werden. Aber noch hatte ich dazu nicht den Mumm.

Oh, sorry, Destruktoren meine ich natürlich in der Tat.

Gleich der nächste Grund zum Jammern:
Ich habe Lib A, B, C und D und die App.
B und C hängen beide von A ab und D hängt von B und von C ab, die App widerum hängt von D ab. Das Auto-Update der Projektfiles von VS2008 auf VS 2010 hat daraus nun folgendes gemacht: App hängt von A, B, C und D ab und die Libs hängen nicht mehr untereinander voneinander ab, was zur Buildorder B, A, D, C, App führte.
Aufgefallen ist das aber nicht direkt nach dem Update, sondern erst Wochen später, unmittelbar vor einem Release, bei einem SVN "Clean all unversioned files". Danach konnte D nicht mehr gebaut werden, weil C noch nicht exisitierte. Bei den anderen Apps hat zufällig die Buildorder gestimmt, wodurch deren Rebuilds durch liefen und bei der betroffenen Apps gab scheinbar immer nur Builds in den letzten Wcohen, nie Rebuilds.

Verfasst: **20.04.2012, 11:57**

http://connect.microsoft.com/VisualStud ... ution-file
https://connect.microsoft.com/VisualStu ... d-projects
https://connect.microsoft.com/VisualStu ... figuration

Wollt ihr mich eigentlich verarschen?
Batchbuilds mit Projektabhängigkeiten funktionieren in VS10 einfach mal gar nicht und die Lösung ist, entweder bei VS9 zu bleiben (geht nicht, weil ein 3rd-Party Tool, welches wir benutzen, uns vor einer Weile zum Update gezwungen hat) oder auf VS11 zu warten?
WTF, MS, WTF?

Verfasst: **20.04.2012, 20:34**

Deswegen (und weil Batch Build nicht multi-threaded ist) übersetze ich eigentlich nur noch mit F5. Ich benutze auch keine statischen Bibliotheken mehr; ich schmeiße alle Quelldateien einfach so ins Projekt. Ist zwar aufwändig, wenn man etwa einem Framework, das von zwei Projekten genutzt wird, ein neues Übersetzungsmodul hinzufügt – aber irgendwie doch noch entspannter als die ständigen Probleme mit statischen Bibliotheken.

Verfasst: **20.04.2012, 22:14**

Dummerweise gibts diese Probleme nicht nur mit Batch-Builds, sondern auch mit Kommandozeilen-Builds, welche unter VS2008 noch problemlos gefunzt haben.

ich habe heute erst mal unser Buildfile für die Windows-SDKs, welches, auch wenn im Grunde längst jede Zeile verändert wurde, im Grundgerüst noch aus vor meienr Zeit stammte (und das, obwohl ich seit 5 Jahren für den Bereich zuständig bin), komplett auf den Kopf gestellt. Nebeneffekt des komaptibel machens mit VS2010 ist: Jetzt hat es nur 20% der zeilenzahl, die es gestern noch besaß und der Build dauert nur noch 2min statt 10min. Manchmal haben total verbuggte "Won't Fix" Features auch ihre Vorteile :)

In VS selbst nutze ich auch seit jeher nur F5, F6 (Build Current Selection) und F7 (Build Solution), von Rebuils mal abgesehen.

So eifnach wie du kann ichs mir leider nicht machen, da wir Middelware entwickeln, sprich, usner Hauptprodukt sind die Libs, Apps gibts nur in Form von Tests und Demos. Unsere C++ Clients VS-Dev-Solution hat derzeit 5 Libs + 5 Demos + 1 mal Tests. Die entsprechende Solution in Xcode übertrifft das aber deutlich mit 6 Libs, 13 Demos und 1 mal Tests. Da die Libs auch nur zum Teil Open Source sind, kommt einfach Sourcen in die Projekte rüber kopieren nicht in Frage. Davon ab, dass ich es auch den Kunden nicht zumuten will, mit jedem Release Source-Dateien in den Projekten rüber kopieren zu müssen. Einmal Lib- und Inlcude Pfade aufsetzen und gut ist, danach muss nur noch das alte Package im Filemanger durch das eue ersetzt werden ein Rebuild und alles läuft, von eventuellen APi-Changes abgesehen natürlich, aber wir krempfel ja auch nicht mit jedem Release die halbe APi um.

Verfasst: **20.04.2012, 23:08**

Schön, wenn man nach einer halben Stunde merkt, mit was man sich da bei der Diablo III Beta anmelden wollte.

EMail-Adresse: "Name@Host,com" <- Findet den Fehler.

Verfasst: **23.04.2012, 16:01**

Schön zu wissen, dass anscheinend die Programmierer der d3dx9math.inl nie /RTCc angeschaltet hatten. Zumindest fliegt mir der D3DXCOLOR-Konstruktor immer um die Ohren. Kein Wunder:

Code: Alles auswählen

D3DXINLINE
D3DXCOLOR::D3DXCOLOR( DWORD dw )
{
    CONST FLOAT f = 1.0f / 255.0f;
    r = f * (FLOAT) (unsigned char) (dw >> 16);
    g = f * (FLOAT) (unsigned char) (dw >>  8);
    b = f * (FLOAT) (unsigned char) (dw >>  0);
    a = f * (FLOAT) (unsigned char) (dw >> 24);
}

Für eine anständige Maskierung hat es in diesen ökonomisch schwierigen Zeiten leider nicht mehr gereicht.

Klasse, jetzt bin ich mit einem gepatchten Direct3D-SDK unterwegs. Erinnert mich bitte in einem Jahr daran, dass das eine Scheißidee ist, und lacht mich dann aus.

Verfasst: **23.04.2012, 16:10**

Keine Sorge, keiner lacht. Ich hab auch schon kleine Änderungen im DX-SDK und in isolierten Boost-Teilen - gut, dass ich eh dazu übergegangen bin, alle Dependencies mit einzuchecken und in der Solution nur noch relativ zu adressieren.

Verfasst: **23.04.2012, 16:20**

Wer verwendet denn schon D3DX, besonders heutzutage? :P

Verfasst: **23.04.2012, 17:30**

dot hat geschrieben:Wer verwendet denn schon D3DX, besonders heutzutage? :P

Nunja, da wären:

Fast alle Samples aus dem Direct3D-SDK
Viele Demos from teh Interwebs
Alles was die DXUT verwendet, welche noch immer als Referenz-Implementierung für korrektes Window- und Device-Handling gilt

Wenn man also schnell was anpassen und debuggen will, und gerade einen solchen Typfehler (wie er eben durch /RTCc erkannt wird) vermutet, fällt so auf die Nase.

Nächste Jammerei: /MP ist voll fürn Arsch, weil unter Debug man den Minimal Rebuild ausmachen müsste, und unter Release das keine Auswirkungen auf die LTCG hat (welches die meiste Zeit bei mir frisst).

Verfasst: **23.04.2012, 19:01**

eXile hat geschrieben:Erinnert mich bitte in einem Jahr daran, dass das eine Scheißidee ist, und lacht mich dann aus.

Es gibt immer jemand Dümmeres. Ich habe eigene D3D9-Header und eine eigene Mathebibliothek und werde nie wieder auch nur einen einzigen offiziellen Header #includen. Und Farben via DWORD rumreichen ist da eh nicht.

Verfasst: **25.04.2012, 12:34**

Xcode find and replace unterstützt keine Multiline Regular Expressions

Verfasst: **25.04.2012, 12:36**

Visual Studio auch nicht sinnvoll, wie ich kuerzlich feststellen musste.

Verfasst: **25.04.2012, 12:54**

Drei geschachtelte Schleifen im Compute Shader, und schon scheint D3DCompile() nicht mehr zu terminieren.

Korrektur: Mein Fehler, ein versehentliches while statt if lies die Schleifen tatsächlich nicht terminieren. Ich muss mich wohl daran gewöhnen, dass in diesem Fall der Compiler ggf. ebenfalls nicht terminiert. :|

Verfasst: **25.04.2012, 13:22**

Notepad++ unterstützt eben so wenig Multiline Regular Expressions ...

Verfasst: **25.04.2012, 13:28**

Ja, soweit kam ich auch. Nimm ein Python oder ein Perl-Skript, geht am schnellsten auch wenn es sich anfuehlt wie Zahnarzt morgens um 5.

Ich muss mich wohl daran gewöhnen, dass in diesem Fall der Compiler ggf. ebenfalls nicht terminiert.

Wofuer du dich bei Kurt Goedel bedanken darfst :-) Und es bestaetigt einige unangenehme Vermutungen ueber das Innenleben des HLSL-Compilers :-)

Verfasst: **25.04.2012, 13:49**

Aramis hat geschrieben:Wofuer du dich bei Kurt Goedel bedanken darfst :-) Und es bestaetigt einige unangenehme Vermutungen ueber das Innenleben des HLSL-Compilers :-)

Tatsächlich tritt das Problem nur bei eingeschalteter Optimierung auf. Aber es kommt noch besser, bei abgeschalteter Optimierung meldet der Compiler sofort, dass das gar nicht terminieren kann. Was die Vermutung bestätigt, dass im Herz des FXC nichts als ein riesiger Kessel voller Magie steht, zusammengepanscht mit maximaler Sorglosigkeit.

ZFX + Developia

Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread