[VC10] Mein Compiler ignoriert mich...

[Schrompf]

Also... ich glaube, ich muss es mal offen ansprechen, auch wenn das ja eigentlich ein Thema ist, das man in der Familie hinter verschlossenen Türen bespricht. Mein Compiler... ne, so kann ich nicht anfangen. Schon seit langem... ne, so auch nicht. Ach verdammt, ich sprech es jetzt einfach offen aus: mein Compiler ignoriert mich. So, nun ist es raus.

Es fing mal harmlos an: ich konvertierte ein paar Projekte von VC9 zu VC10. Mein Zwillingsbruder hatte früher mal in großen Engagement das Warnlevel für die Splitterwelten auf Anschlag gezogen - inklusive Dependencies sind wir da ja immerhin bei >2 Millionen Zeilen Code. Und wir ertranken in Warnungen. Manches davon war in der Tat ein guter Hinweis, anderes haben wir dann selektiv per "Disable Warning" mundtot gemacht. Gut. Nur leider ändern sich manche Warnungsnummern mit dem Versionswechsel.

Ich habe inzwischen das Warnungslevel wieder zurückgedreht. Bei allen beteiligten Projekten. Ich habe ein Property Sheet, dass für alle Projekte die Pfade aufsetzt. Darin stehen jetzt auch ein paar deaktivierte Warnungen für besonders hartnäckige Kandidaten und ein paar Defs wie _SECURE_SCL=0, die ich für nötig hielt. Aber der Compiler ignoriert diese Vorschriften. Das Property Sheet ist in jedem Projekt aufgenommen, sonst würde mangels Include-Pfaden ja nix mehr kompilieren. Aber sowohl die Disable Warnings-Direktive wird ignoriert als auch meine Defines. Ich finde mich im Debugger, wenn ich in was Langem mal testweise unterbreche, immer wieder in irgendwelchen Iterator-Checks wieder.

In der resultierenden Befehlszeile des Compilers stehen sowohl die DisableWarnings als auch die Präprozessor-Defines mit drin. Nur wirken tun sie nix. Hat jemand eine Idee, wie ich dem beikommen könnte? Volltextsuche, ob irgendwer per #pragma die Warnungen wieder aktiviert, hat auch nix erbracht. Selbst eine Suche nach Dateiinhalt nach "4350" durch das ganze Verzeichnis erbrachte nur ein paar False Positives in Binärdateien und natürlich die Deaktivierung selbst.

Die Warnung "4350" ist z.B. ein prima Kandidat: sie warnt, dass das Verhalten des Compilers in früheren Versionen an der Stelle falsch war und der Compiler jetzt das Richtige tut. Ich kann meiner Dankbarkeit ob dieser Tatsache leider nicht den nötigen Ausdruck verleihen, weil mir boost::signal die Ausgabe mit diesen Warnungen wortwörtlich flutet! Und ich krieg diese Warnungen nicht tot.

[eXile]

Hilft es dir schon mal auf die schnelle weiter, wenn du mal _ITERATOR_DEBUG_LEVEL = 0 (seit Visual C++ 2010) setzt? _SECURE_SCL und _HAS_ITERATOR_DEBUGGING sind deprecated.

[Schrompf]

Danke! Engagiertes Googeln, nachdem ich per Zufalls-Breakpoint mal wieder in einem Iterator-Check gelandet bin, hat das auch erbracht. Hier ist es mit Abwärts-Wirkung zusammengefasst: http://msdn.microsoft.com/de-de/library ... .110).aspx

Manchmal hilft jammern, um sich des Problems klarzuwerden. Die Warnungen finde ich auch noch, hoffe ich...

[Schrompf]

Mäh! Mit _ITERATOR_DEBUG_LEVEL=0 kann ich nicht mehr gegen die Fertig-Libs von boost linken. Ich will ehrlich gesagt Boost nicht From Scratch neubauen müssen.... urg. Das ist mein Leben...

[Jonathan]

Es gibt fertig Libs von boost? :D
Also ich fand immer, dass boost die mit Abstand am einfachsten zu kompilierende Bibliothek von allen ist :) Ein klick und n halbes Stündchen warten und die Sache hat sich erledigt.