Moin! Ich programmiere an einem größeren Projekt in C++ mit MS Visual Studio. Leider gibt es gelegendlich Speicherzugriffsfehler. Das dumme an der Sache: Der Debugger steigt irgendwo an einem Punkt aus, nachdem schon alles zerschossen ist. Der Stack scheint total im Eimer zu sein, denn es lässt sich nichtmal ein vernünftiger Callstack anzeigen, um zu sehen, welche Funktion gerade ausgeführt wurde. Wie kann man dem nun auf die Spur kommen? Gibt es Tools die zur Laufzeit überwachen, dass nur in allozierten Speicher geschrieben wird und ähnliche Fehler?
_CrtCheckMemory() [1] kann helfen, bremst (abhängig von den Einstellungen) allerdings ∗massiv∗. Augen zu und durch. Wenn man Glück hat dann kommt man mit Binärsuche am ehesten zum Ziel. Das muss aber nicht immer (insbesondere bei Nebenläufigkeiten) korrekt funktionieren. HTH und Viel Glück! [1] http://msdn.microsoft.com/en-us/library/e73x0s4b%28v=vs.100%29.aspx
Geht es denn um MS-Müll oder ließe sich das auch mit einem gcc übersetzen? Dann nämlich könntest du mächtigere Werkzeuge benutzen, etwa valgrind oder gdb mit Rückwärts-Debuggen.
Sven P. schrieb: > Geht es denn um MS-Müll oder ließe sich das auch mit einem gcc > übersetzen? sehr schlechte Idee, denn schon das ändern des compiler kann den fehler teilweise komplett verschwinden lassen oder andere auftrauchen lassen. Kein tool kann erkennen wenn du innerhalb deines Speichers andere Daten überschreibst. Sie können maximal erkennen wenn du über ein array hinausschreibst und sie dort eine Guardpage angelegt haben. Ich würde den quellcode einfach noch mal genauer anschauen, es dürfte bei C++ doch nicht so viele stellen geben wo man mit pointern arbeitet. Sind denn auch Thread beteiligt, ist das verhalten nachvollziehbar? Passiert also bei den gleichen startbedingungen immer das gleiche?
Hallo, beachte doch die Tipps zum Debugging von Martin Richter in seinem Blog (blog.m-ri.de). Zur Not musst du den ApplicationVerifery einsetzen. Viel Erfolg, Hase
Peter II schrieb: > Sven P. schrieb: >> Geht es denn um MS-Müll oder ließe sich das auch mit einem gcc >> übersetzen? > sehr schlechte Idee, denn schon das ändern des compiler kann den fehler > teilweise komplett verschwinden lassen oder andere auftrauchen lassen. Nein, sehr gute Idee. Wenn möglich, Quelltext genau aus diesem Grund von verschiedenen Compilern übersetzen lassen. > Kein tool kann erkennen wenn du innerhalb deines Speichers andere Daten > überschreibst. Sie können maximal erkennen wenn du über ein array > hinausschreibst und sie dort eine Guardpage angelegt haben. Es gibt aber Werkzeuge, die kaputte Stapelrahmen erkennen. Und genau dann wäre es schön, das Programm von dort an rückwärts durchlaufen zu können. > Ich würde den quellcode einfach noch mal genauer anschauen, es dürfte > bei C++ doch nicht so viele stellen geben wo man mit pointern arbeitet. Guter Witz :-} Und du glaubst, mit den Templates kann man sowas nicht produzieren...? Es reicht schlimmstenfalls schon ein vergessenes 'virtual' aus.
Sven P. schrieb: > Guter Witz :-} > Und du glaubst, mit den Templates kann man sowas nicht produzieren...? > Es reicht schlimmstenfalls schon ein vergessenes 'virtual' aus. damit überschreibt man meines wissens aber nicht andere Daten, kann es nur passieren das man aus einen ungültigen speicherbereich daten lesen will. Und das zeigt der Debugger gleich an der stelle an.
Peter II schrieb: > Sven P. schrieb: >> Guter Witz :-} >> Und du glaubst, mit den Templates kann man sowas nicht produzieren...? >> Es reicht schlimmstenfalls schon ein vergessenes 'virtual' aus. > damit überschreibt man meines wissens aber nicht andere Daten, kann es > nur passieren das man aus einen ungültigen speicherbereich daten lesen > will. Und das zeigt der Debugger gleich an der stelle an. Denkst du. Du wirst erstaunt sein, was z.B. ein falscher Destruktor oder ein ungültiger Iterator so alles anrichten können.
Vor allem durch erase invalidierte Iteratoren katapultieren dich direkt in die Hölle, wenn du in ner For-Loop weiteriterierst.
Sven P. schrieb: > Geht es denn um MS-Müll oder ließe sich das auch mit einem gcc > übersetzen? Dann nämlich könntest du mächtigere Werkzeuge benutzen, etwa > valgrind oder gdb mit Rückwärts-Debuggen. Es geht nicht zwingend um MS-Müll, aber damit arbeite ich halt zur Zeit. Den MS-Müll halte ich, im Gegensatz zu dir, für die beste IDE und den besten Debugger, den es gibt ;-) Naja, aber alles kann der halt auch nicht. Aber der Code ist portabel und auch per GCC übersetzbar. Valdrind war auch der erste Name, der mir als Tool in den Sinn gekommen ist. Leider scheint es das nicht für Windows zu geben. g457 schrieb: > _CrtCheckMemory() Schon mal ein Anfang. Wobei das ja nur nach Heap-Fehlern sucht. Hase schrieb: > ApplicationVerifery Den Application Verifier aus dem Visual Studio hab ich auch ausprobiert. Leider läuft das Programm damit nicht richtig. Da kommen Funktionen aus einer DLL, die Speicher anfordern sollten, mit NULL zurück. Hab ich noch nicht genauer untersuchen können, warum das so ist. Sven P. schrieb: > Es gibt aber Werkzeuge, die kaputte Stapelrahmen erkennen. Habend die Werkzeuge auch Namen und laufen auf Windows? ;-)
Peter II schrieb: > Sven P. schrieb: >> Geht es denn um MS-Müll oder ließe sich das auch mit einem gcc >> übersetzen? > sehr schlechte Idee, denn schon das ändern des compiler kann den fehler > teilweise komplett verschwinden lassen oder andere auftrauchen lassen. Ja, wenn man Visual Studio streicht kann der Fehler ziemlich schnell weg sein;-) Visual Studio kann durchaus mal eine Debug Version aus versehen mit der Release Version Linken, dann wird jeder std::string verhauen, oft auch der Stack... Wenn die Applikation aus mehreren Teilen besteht mal die Übergänge Debuggen, und wenn sich plötzlich die Werte ändern: Dann hast du den Fehler;-) Welche Version vom VS? > Kein tool kann erkennen wenn du innerhalb deines Speichers andere Daten > überschreibst. Sie können maximal erkennen wenn du über ein array > hinausschreibst und sie dort eine Guardpage angelegt haben. Natürlich gibt es Tools die das können, es werden einfach Metinformationen zu den Daten hinzugefügt. Ich glaube Valgrind kann das auch, natürlich geht sowas aber mit MS Visual Studio nicht. > Ich würde den quellcode einfach noch mal genauer anschauen, es dürfte > bei C++ doch nicht so viele stellen geben wo man mit pointern arbeitet. @Peter II Es gibt Leute die schreiben auch etwas grössere Applikationen als du, wenn du mehr als 3 Klassen verwenden, dann kann es durchaus viele Stellen geben bei denen ein Fehler möglich wäre. > Sind denn auch Thread beteiligt, ist das verhalten nachvollziehbar? > Passiert also bei den gleichen startbedingungen immer das gleiche? Wenn Ja: Kannst du mit diesen Informationen Debuggen, dann findest du heraus wo das es abschmiert. Wenn nicht: Dir bleibt wohl nichts anderes übrig als entweder ein entsprechendes Analysetool zu verwenden, oder du baust massenweise Logzeilen ein. mfg Andreas
Peter II schrieb: > Sven P. schrieb: >> Guter Witz :-} >> Und du glaubst, mit den Templates kann man sowas nicht produzieren...? >> Es reicht schlimmstenfalls schon ein vergessenes 'virtual' aus. > damit überschreibt man meines wissens aber nicht andere Daten, kann es > nur passieren das man aus einen ungültigen speicherbereich daten lesen > will. Und das zeigt der Debugger gleich an der stelle an. Kommt darauf an. Der Debugger springt erst an wenn der Fehler schon längst passiert ist, und wenn da der Stack weg ist kann er dir auch nichts mehr anzeigen. Der Debugger weiss dann nämlich NICHT wo die Applikation zuletzt war. Woher auch? Kann bei C++ durchaus mal vorkommen... mfg Andreas
Nur mal so am Rande gefragt: Die verschiedenen Runtime-Checks, die die CRT bieten kann, sind auch alle aktiviert? Die finden sich z.B. unter den "Code Generation"-Optionen und WIMRE auch irgendwo bei den Linkeroptionen. Gerade auf diesem Gebiet sind die neueren VC-Versionen erheblich besser geworden als das steinalte VC6. Welche Version wird hier verwendet?
... oder ist das einfach nur ne nicht gefangene Exception? Durch Stack Unwinding ist da für den Debugger tatsächlich nichts mehr zu holen. Abhilfe: Testweise mal einen Breakpoint auf alle Exceptions setzen. Wie das im Visual Studio genau geht, weiß ich aber nicht.
Klaus schrieb: > Sven P. schrieb: >> Geht es denn um MS-Müll oder ließe sich das auch mit einem gcc >> übersetzen? Dann nämlich könntest du mächtigere Werkzeuge benutzen, etwa >> valgrind oder gdb mit Rückwärts-Debuggen. > > Es geht nicht zwingend um MS-Müll, aber damit arbeite ich halt zur Zeit. Siehe unten. Ich meinte damit nicht die IDE, sondern das API, MFC und was es da sonst noch an Scheußlichkeiten gibt :-) > Den MS-Müll halte ich, im Gegensatz zu dir, für die beste IDE und den > besten Debugger, den es gibt ;-) Naja, aber alles kann der halt auch > nicht. Oha.. Du solltest dich echt mal umschauen :-} Andreas hat das Problem ja beschrieben: Prinzipiell überbügelst du einen Zeiger und es kracht erst später, wenn der Zeiger gebraucht wird. Als Beispiel. In solchen Fällen (schrieb ich oben auch schon) ist der gdb wirklich gut, denn er kann das Programm vom Crash an rückwärts ausführen. Das könnte eventuell auch zu einer Lösung führen. > Aber der Code ist portabel und auch per GCC übersetzbar. Valdrind war > auch der erste Name, der mir als Tool in den Sinn gekommen ist. Leider > scheint es das nicht für Windows zu geben. Schau mal dort nach: http://stackoverflow.com/questions/413477/is-there-a-good-valgrind-substitute-for-windows > Sven P. schrieb: >> Es gibt aber Werkzeuge, die kaputte Stapelrahmen erkennen. > > Habend die Werkzeuge auch Namen und laufen auf Windows? ;-) Naja, gdb zum Beispiel wird dann ziemlich böse. In der Regel reicht aber die Debug-Option von gcc schon, damit es scheppert.
Sven P. schrieb: > Geht es denn um MS-Müll Man sieht, daß du ein professioneller Entwickler bist, der stets nur objektive Kriterien in seine Überlegungen einfließen läßt.
Peter II schrieb: > es dürfte > bei C++ doch nicht so viele stellen geben wo man mit pointern arbeitet Nein, natürlich nicht. Klar, nur über Zeiger kann man Polymorphie nutzen, aber das macht man in C++ ja auch nie...
Andreas B. schrieb: > Visual Studio kann durchaus mal eine Debug Version aus versehen mit der > Release Version Linken, dann wird jeder std::string verhauen, oft auch > der Stack... Nein, das macht VS nicht, das macht der Benutzer, der etwas falsch einstellt. Geht mit deinem geliebten gcc aber mindestens ebenso leicht. Können die ganzen Kindergartenkinder sich jetzt mal bitte verziehen?
Vielleich ganz altmodisch : Programmteile deaktivieren (auskommentieren) und prüfen, wie sich das auswirkt.
Klaus schrieb: > Ich programmiere an einem größeren Projekt in C++ mit MS Visual Studio. > > Leider gibt es gelegendlich Speicherzugriffsfehler. Das dumme an der > Sache: Der Debugger steigt irgendwo an einem Punkt aus, nachdem schon > alles zerschossen ist. Der Stack scheint total im Eimer zu sein, denn es > lässt sich nichtmal ein vernünftiger Callstack anzeigen, um zu sehen, > welche Funktion gerade ausgeführt wurde. Auch wenn ein Tool zur statischen Codeanalyse den Fehler in Deinem speziellen Fall vielleicht nicht finden kann: Verwendest Du ein solches Tool? Wenn nein, würde ich dies tun, und die vom Tool gemeldeten Fehler und Warnungen einfach mal nicht ignorieren :-)
Im VS:
Debug -> Exceptions -> Win32 Exceptions -> Access Violation
einschalten. Bei einer Access Violation hält er dann da, wo sie
auftritt, und nicht erst da, wo es crashed.
Anmerkung:
> Geht es denn um MS-Müll
Ich arbeite täglich mit dem MS VC2010, und möchte es nicht missen. Schon
gar nicht mit irgendwelchen zusammengestückelten gnu Sachen, bei denen
erst mal "alles zum Laufen bringen muss".
Speicherfehler und Memory Leaks muss man von Anfang an mitbeobachten und gleich korrigieren. Diesen Prozess rauszuzögern bringt nichts, es macht alles nur noch komplexer. Unittests sind hilfreich. Bei VC++ gehört ans Anfang in jedes File gleich mal #ifdef _DEBUG #undef THIS_FILE static char THIS_FILE[]=__FILE__; #define new DEBUG_NEW #endif rein, damit dir die Runtime selbst hilft, derartige Problemstellen zu detektieren und zu finden. Wobei man in C++ durch die konsequente Nutzung des RAII Idioms gute Chancen hat, diesem Problemkreis relativ leicht zu entkommen. RAII bedeutet Resource Aquisition Is Initialization In einer Kurzfassung auf die wesentlichste Auswirkung reduziert: Eine Klasse soll 1 Resource und nur 1 Resource dynamisch verwalten. Benötigt eine Klasse mehrere dynamische Dinge, dann wird für jedes davon eine eigene Klasse fällig, die sich nur um die Verwaltung dieses 1 dynamischen Teils kümmert. Copy Konstruktoren, operator= und Destruktoren der zusammenfassenden Klasse werden dann sehr einfach bzw. können überhaupt vom Compiler generiert werden. Auch immer bewusste machen: Welche Pointer sind 'owning-Pointer', welche sind 'non-owning'. Ein owning Pointer ist einer, der für die Verwaltung zuständig ist. Sein Job ist es, die Resource am Ende ihrer Lebensdauer zu zerstören. Non-owning Pointer haben dieses Recht nicht. Daraus folgt sofort eine mehr oder weniger Grundregel: die Klasse die eine Resource allokiert, ist auch dafür zuständig, sie zu zerstören. Ein anderes Objekt kann vielleicht einen Pointer darauf halten, aber sie hat nicht das Recht an der Allokierung selbst rumzupfuschen. Die "Rule of Three" beachten: Benötigt eine Klasse eine eigene Version der Funktionen * Destruktor * Copy Konstruktur * Operator = dann ist es sehr wahrscheinlich, dass sie alle 3 benötigt. Will man Copy Constructor bzw. Operator= nicht implementieren, dann muss man sie wenigstens für den Compiler/Linker unbrauchbar machen um sich als Programmierer selbst vor eine unbeabsichtigten Verwendung zu schützen. (private deklarieren und nicht implementieren) const-korrektes Arbeiten ist auch etwas, das einem manchmal fehlerhafte Verwendungen aufzeigt. Auch hier gilt: von Anfang an durchziehen. const im Nachhinein einziehen zieht oft Rattenschwänze an Codeänderungen nach sich. Die sind zwar meistens unkomplizierte Editiersession aber Zeit kosten sie trotzdem. ASSERT reingeben. Assertions können manchmal Probleme aufzeigen, die sich noch nicht zum Desaster ausgewirkt haben. Ziel: Das Programm selber soll anzeigen, dass da etwas nicht stimmt. Und zwar unabhängig davon, ob der Aufrufer Fehlercodes auswertet oder nicht. Ein Out of Bounds Zugriff in ein Array ist ein Fehler! Selbst wenn eine Funktion den übergebenen Index prüft und im Fehlerfall die Operation mit einem Fehlercode abbricht, soll ein ASSERT diesen Fehler im Debugger unmissverständlich melden, denn er weist oft auf ein grundlegenderes Problem beim Aufrufer hin. Und ganz wichtig: Nimm das Prinzip der Datenkapselung ernst! Eine Klasse, die Pointer auf ihre Daten rausgibt, kann schon der erste Sargnagel sein. Solange die generelle Programmstruktur nicht zu verkorkst ist, kann man viele Dinge auch im Nachhinein noch mit einem entsprechenden Aufwand nachrüsten. Meistens lohnt sich das sogar, da die Analyse von Stack-Traces auch einiges an Aufwand bedeutet und man mit der Kentniss, wo welche Operation schief gelaufen ist, ja noch nicht unbedingt eine Abhilfe dagegen hat.
Rufus Τ. Firefly schrieb: > Die verschiedenen Runtime-Checks, die die > CRT bieten kann, sind auch alle aktiviert? Präzisiert: /RTCc (smaller type check) /RTC1 bzw. /RTsu (stack frames, uninitialized variables) /GS (buffer security check)
XTerminator schrieb: > Sven P. schrieb: >> Geht es denn um MS-Müll > > Man sieht, daß du ein professioneller Entwickler bist, der stets nur > objektive Kriterien in seine Überlegungen einfließen läßt. Ich bin zumindest so erfahren, dass ich mir MSVC++ nicht mehr antue und Windows als Entwicklungsplattform abgeschrieben habe. Ist ja echt kaum mehr zumutbar als primäre Plattform. Ohne tonnenweise nachinstallierte Tools schon garnicht. Ich kann Karl-heinz einfach nur beipflichten. Insbesondere was den ersten Absatz angeht. Wenn bei uns im Team ein 'Speicherfehler' auffällt, ist augenblicklich Entwicklungsstopp, bis die Ursache gefunden und einwandfrei behoben ist. Entweder läuft ein Programm stabil oder garnicht und es geht nicht an den Kunden -- ein 'in seltenen Fällen kann..' ist nicht akzeptabel. Das führt einzig zu Frust beim Kunden. Die tragische Erfahrung aus der Praxis zeigt dann aber, dass es leider allzuoft einen Zusammenhang zwischen Speicherfehlern und Progarmmierer(n) gibt. Das merkt man insbesondere, wenn man ein Projekt übernimmt oder einem Projekt neu beitritt. Zumindest bei kleineren Projekten muss man spätestens nach dem zweiten oder dritten Fehler schon ganz scharf nachdenken, ob ein Rewrite nicht günstiger ist. Denn dann ist die Qualität oft schon abgesoffen und die Gefahr viel zu groß, beim Nachbessern was zu vergessen. Das hat dann ungefähr den Charakter wie 1/x: Mit unverhältnismäßigem Entwicklungs- und Debugaufwand konvergiert immer langsamer gegen Fertigstellung, wird aber effektiv doch nie auf eine befriedigende Weise fertig. Ein klassisches 'Leiche-im-Keller'-Syndrom :-} Da helfen dann wieder Kapselung und Einheitentests weiter. Wenn man die richtig anpackt, funktionieren die sogar, ohne esoterisch zu eskalieren.
Sven P. schrieb: > Ich bin zumindest so erfahren, dass ich mir MSVC++ nicht mehr antue und > Windows als Entwicklungsplattform abgeschrieben habe. Wenn die Entwickler fehlerhaften Code schreiben, ist dann der Compiler / die Entwicklungsumgebung / das Betriebssystem dran schuld? Sooooooo schlecht, wie manche sie gerne hätten, sind Compiler und IDE von Microsoft jetzt auch wieder nicht.
Mark Brandis schrieb: > Wenn die Entwickler fehlerhaften Code schreiben, ist dann der Compiler / > die Entwicklungsumgebung / das Betriebssystem dran schuld? Selbstverständlich. Wer denn sonst? > Sooooooo schlecht, wie manche sie gerne hätten, sind Compiler und IDE > von Microsoft jetzt auch wieder nicht. Man könnte sogar sagen, daß das eines der wenigen tatsächlich brauchbaren Produkte ist, auch wenn MS sich redlich Mühe gibt, das zu ändern. Das Fenster- und vor allem Maushandling in VS2010 ist eine mittlere Katastrophe, der native Compiler und der Debugger hingegen sind vorzüglich, auch wenn man auf das unnötige .Net-Geraffel verzichtet. Schön wäre es, wenn es eine von diesem Geblubber befreite reine C- und C++-Variante des VS2010 gäbe. Ärgerlich und peinlich ist die nach wie vor fehlende C99-Unterstützung.
Eventuell kann VLD "Visual Leak Detector" (ist glaube ich noch nicht genannt worden, homepage http://vld.codeplex.com/) auch noch ein paar gute Hinweise geben. Ist Freeware und hat mir schon sehr geholfen!
Rufus Τ. Firefly schrieb: > ändern. Das Fenster- und vor allem Maushandling in VS2010 ist eine > mittlere Katastrophe, der native Compiler und der Debugger hingegen sind > vorzüglich, Jep. Seit sich Herb Sutter des C++ Compilers angenommen hat, hat der einen steilen Qualitätssprung hingelegt. Man kann MS viel vorwerfen, aber ihr C++ Compiler gehört sicherlich mit zu den Besten, die es gibt. (und das .Net Geraffel nehm ich bei C++ sowieso nicht ernst. Ich träum ja immer noch davon, dass es irgendwann eine funktional gleichwertige Lib in nativ C++ gibt. Denn eines muss man schon sagen: Die .Net Lib ist sauber aufgebaut und ordentlich durchdesigned. Nicht so wie die MFC, zu deren Ehrenrettung man nur sagen kann: Anfang der 90-er Jahre war der C++ Compiler halt noch lange nicht soweit um ein eleganteres Design zu erlauben)
Rufus Τ. Firefly schrieb: > Das Fenster- und vor allem Maushandling in VS2010 ist eine > mittlere Katastrophe Was stört dich denn? ich finde es ganz gut. Das einzige, was mich nervt, ist dass man im Gegensatz zu früher, die Watchfenster nicht größer machen kann, als den Ausschnitt, den man gerade sieht. im VS2005 gabs dann halt einen Scrollbalken, so dass man zur Not auch den längsten, verschachteltsten Template-Typ lesen konnte. Jetzt muss man erst das Fenster ausdocken. Rufus Τ. Firefly schrieb: > Ärgerlich und peinlich ist die nach wie vor fehlende C99-Unterstützung. warum, der Standard ist doch noch nicht mal 12 Jahre alt ;)
Vlad Tepesch schrieb: > Rufus Τ. Firefly schrieb: >> Das Fenster- und vor allem Maushandling in VS2010 ist eine >> mittlere Katastrophe > > Was stört dich denn? Mich stört zb das 'Property' Fenster. Ganz besonders im Resource-Editor. Ich fand die alten Dialoge übersichtlicher und besser in der Bedienung, vor allen Dingen wenn es darum ging, Handler an Controls zu binden. Und wie ich in der MFC an einen Dialog mit dem Wizzard eine OnInitDialog anhängen kann hab ich auch noch nicht rausgefunden :-)
Karl Heinz Buchegger schrieb: > Seit sich Herb Sutter des C++ Compilers angenommen hat, hat der einen > steilen Qualitätssprung hingelegt. Wann war das ungefähr? > Man kann MS viel vorwerfen, aber ihr C++ Compiler gehört sicherlich > mit zu den Besten, die es gibt. Ist das so? Ich habe das eher so in Erinnerung: Früher nahm man den GCC, wenn man kein Geld hatte und den MSC, wenn man schnellen Code erzeugen wollte. Der GCC holte aber mit den Oprimierungen stark auf, so dass man mit dem MSC keine Geschwindigkeitsvorteile (eher Nachtteile) hatte. MSC wurde fortan hauptsächlich deswegen verwendet, weil man Visual Studio wollte und der MSC eben hübsch integriert mitgeliefert wurde. Der GCC hatte zusätzlich den Vorteil, dass er sich immer stark am je- weils gültigen Standard orientierte, was aber natürlich für Windows- Only-Programmierer kein so starkes Argument ist. Trotzdem hat hier der MSC inzwischen aufgeholt. Dann kam der Intel-Compiler und hat sowohl GCC als auch MSC weggefegt, was die optimierte Codegenerierung betrifft. Da er aber ordentlich kostet, wird praktisch nur im professionellen Bereich und dort haupt- sächlich im Heigh-Performance-Computing eingesetzt. Den Intel-Compiler würde ich als den aktuell mit Abstand stärksten Compiler für PCs ansehen, MSC und GCC folgen mit Abstand auf etwa gleichem Niveau. Ich verwende den MSC seit ein paar Jahren kaum noch, mag sein, dass er in dieser Zeit wieder kräftig zugelegt hat, deswegen meine Frage von oben bzgl. Herb Sutter.
Yalu X. schrieb: > Den Intel-Compiler würde ich als den aktuell mit Abstand stärksten > Compiler für PCs ansehen, MSC und GCC folgen mit Abstand auf etwa > gleichem Niveau. Nur für Intel-CPUs, für andere CPUs optimiert er nicht nur nicht richtig, sondern erzeugt sogar absichtlich pessimierte Codepfade.
Vlad Tepesch schrieb: > Rufus Τ. Firefly schrieb: > >> Ärgerlich und peinlich ist die nach wie vor fehlende C99-Unterstützung. > > warum, der Standard ist doch noch nicht mal 12 Jahre alt ;) Das ist nicht die aktuelle Version, sondern die bereits veraltete, seit Ende letzten Jahres nicht mehr gültige. Und schon die ist noch nicht mal auch nur annähernd umgesetzt.
Rolf Magnus schrieb: > Und schon die ist noch nicht mal > auch nur annähernd umgesetzt. das doch mal bitte was ihr von dem Standard so dringend braucht, ich hatte zumindest noch nichts vermisst. Oder geht es euch nur um die datentypen uint8_t usw. das kann man ja zum glück selber lösen.
Yalu X. schrieb: > Karl Heinz Buchegger schrieb: >> Seit sich Herb Sutter des C++ Compilers angenommen hat, hat der einen >> steilen Qualitätssprung hingelegt. > > Wann war das ungefähr? Das muss so ungefähr um 2004, 2005 rum gewesen sein. Nagle mich da jetzt aber nicht auf 2 oder 3 Jahre auf/ab fest. > >> Man kann MS viel vorwerfen, aber ihr C++ Compiler gehört sicherlich >> mit zu den Besten, die es gibt. > > Ist das so? Ich habe das eher so in Erinnerung: Es ist so. MS hat enorme Anstrengungen in den Compiler gesteckt um ihn standardkonform zu machen.
Rufus Τ. Firefly schrieb: > Ärgerlich und peinlich ist die nach wie vor fehlende C99-Unterstützung. Das wird sich auch nicht ändern, MS hat schließlich erklärt, daß sie gar nicht mit C99 planen und C++ als Sprache der Wahl ansehen.
Vlad Tepesch schrieb: >> Das Fenster- und vor allem Maushandling in VS2010 ist eine >> mittlere Katastrophe > > Was stört dich denn? Versuch mal was mit dem Scrollrad anzufangen. Das lässt sich nur mit Aufwand reparieren, denn MS hat teilweise erheblichen Aufwand getrieben, um das Scrollrad nutzlos werden zu lassen (Beispiel: Debugfunktion "Attach to remote process", Auswahl des Prozesses in der Listbox. Die scrollt überhaupt nicht). Glücklicherweise gibt es Tools, die das komplett kaputte Scrollradhandling beheben, hier insbesondere XMBC http://www.highrez.co.uk/downloads/XMouseButtonControl.htm Desweiteren ist das Verhalten der diversen Popupfensterchen extrem lästig, die sich vor den Quelltext schieben und da nur mit Gewalt wegzubekommen sind. Auch beeindruckend ist die hartnäckige Unfähigkeit, mit "goto definition" an eine Codestelle zu springen und die dann auch im jeweiligen Fenster anzuzeigen. Das jedenfalls tut VS2010 nicht, wenn man sich die Freiheit nimmt, mehrere Sourcecodefenster gleichzeitig sehen zu wollen (und nicht die komplett retardierte standardmäßige "Workbook"-Variante nutzt). Letztlich nutze ich zum Arbeiten mit VS2010 drei Monitore, den in der Mitte für das eigentliche Arbeiten und die beiden rechts und links davon für die zig Zusatzfensterchen, die mir sonst den Blick auf den Quelltext versperren wollen.
Rufus Τ. Firefly schrieb: > Versuch mal was mit dem Scrollrad anzufangen. es ging um den c99 standard - nicht um das VS also das scollrad unter VS2003 geht ohne Problem in dem remote-dgp fenster - im 2010 muss ich nachher mal testen - viel mir noch nie auf das das nicht geht.
Karl Heinz Buchegger schrieb: >>> Man kann MS viel vorwerfen, aber ihr C++ Compiler gehört sicherlich >>> mit zu den Besten, die es gibt. >> >> Ist das so? Ich habe das eher so in Erinnerung: > > Es ist so. > MS hat enorme Anstrengungen in den Compiler gesteckt um ihn > standardkonform zu machen. Dass der MS-Compiler inzwischen weitgehend standardkonform ist, habe ich noch mitbekommen und oben auch geschrieben. Aber hat er in den letzten Jahren auch bei der Optimierung/Codegenerierung zugelegt? Mein letzter Stand ist der, dass er dabei mit dem GCC etwa gleichauf war. XTerminator schrieb: >> Den Intel-Compiler würde ich als den aktuell mit Abstand stärksten >> Compiler für PCs ansehen, MSC und GCC folgen mit Abstand auf etwa >> gleichem Niveau. > > Nur für Intel-CPUs, für andere CPUs optimiert er nicht nur nicht > richtig, sondern erzeugt sogar absichtlich pessimierte Codepfade. Das ist natürlich zu befürchten. Vielleicht bringt ja AMD mal einen Compiler auf den Markt :) Rufus Τ. Firefly schrieb: > Ärgerlich und peinlich ist die nach wie vor fehlende C99-Unterstützung. Mal ganz ehrlich: Wer programmiert unter Windows noch in C? Das sind doch höchstens solche, die Software für ein Fremdsystem (bspw. einen µC) entwickeln und komplexe Module vorab auf dem PC testen wollen. Aber das sind sicher nicht die Kunden, die MS mit dem Visual Studio ansprechen will.
Yalu X. schrieb: > Mal ganz ehrlich: Wer programmiert unter Windows noch in C? Das sind > doch höchstens solche, die Software für ein Fremdsystem (bspw. einen µC) > entwickeln und komplexe Module vorab auf dem PC testen wollen. Aber das > sind sicher nicht die Kunden, die MS mit dem Visual Studio ansprechen > will. Klar. Das ist bzw. war (zumindest für mich) halt richtig interessant für portable Projekte. Mittlerweile nehme ich überall nur noch den GCC, weil der deutlich komfortabler zu bedienen ist, als VC. Was mich an Windows als Entwicklungsplattform viel mehr stört, ist der ganz banale alltägliche Umgang damit. Frisch installiert ist das einfach nicht mehr zumutbar: . Nerviges Startmenü, . unübersichtlicher Explorer (Hierarchie-Linien!), . keine gescheite Konsole, . Skripte auch nicht (und nein, DOS-Batch ist lachhaft...), . keine Archivprogramme (Zip, Tar, ...), . nix um Dateien zu vergleichen/vereinigen,. kein brauchbarer Editor für mal grade in einen Quelltext zu gucken, ohne MSVC anzuschmeißen, . ... Bis das alles mal in der Reihe ist, habe ich unzählige Programme nachinstalliert. Meistens hau ich gleich MinGW mit VIM drauf und hab Ruhe. Nun, zurück zum Thema?
Rufus Τ. Firefly schrieb: > Versuch mal was mit dem Scrollrad anzufangen. Das lässt sich nur mit > Aufwand reparieren, denn MS hat teilweise erheblichen Aufwand getrieben, > um das Scrollrad nutzlos werden zu lassen (Beispiel: Debugfunktion > "Attach to remote process", Auswahl des Prozesses in der Listbox. Die > scrollt überhaupt nicht). so ich habe es mal getestet, sie scollt. Hätte mich auch gewunder wenn nicht. Sven P. schrieb: > Was mich an Windows als Entwicklungsplattform viel mehr stört, ist der > ganz banale alltägliche Umgang damit. Frisch installiert ist das einfach > nicht mehr zumutbar: > . Nerviges Startmenü, was ist daran nervig? > . unübersichtlicher Explorer (Hierarchie-Linien!), ich komm mit dem linux zeug auch nicht klar, explorer ist ok > . keine gescheite Konsole, was kann an einer konsole falsch sein, oder meinst du eine shell? > . Skripte auch nicht (und nein, DOS-Batch ist lachhaft...), wenn man will gibt es die powershell > . keine Archivprogramme (Zip, Tar, ...), zip ist standardmäßig dabei > . nix um Dateien zu vergleichen/vereinigen,. comp zum vergleich - aber gehört das etwas zu einem Betriebssystem? Es Es gibt ausreichend programme dafür. > kein brauchbarer Editor für mal grade in einen Quelltext zu gucken, notepad kann so ziemlich jeden quelltext anzeigen die ich je hatte. Wenn es dir nicht reicht Kann du jeden anderen editor installieren - wie bei linux auch. > ohne MSVC anzuschmeißen, also jetzt auch noch zu faul ein programm zu starten.
Yalu X. schrieb: > Mal ganz ehrlich: Wer programmiert unter Windows noch in C? Ich mach das, weil ich einige wirklich sehr alte Projekte weiterpflege. Da das keine GUI-Anwendungen sind, sondern Dienste bzw. andere Hintergrundprozesse, ist das auch nicht sonderlich schlimm. Diese Projekte habe ich vor knapp 20 Jahren für die damals erscheinende erste ernstgemeinte Windows-Version angefangen zu entwickeln. Und die war, bereits in den ersten Beta-Versionen, ein ganz erheblicher Fortschritt gegenüber dem 16-Bit-DOS-Gefrickel, auch wenn die Oberfläche, äh, grässlich war. Interaktive Anwendungen würde ich ums Verrecken nicht in C schreiben wollen -- es ist allerdings sehr lehrreich, es mal getan zu haben, weil erst dann man verstehen kann, warum auch so etwas wie die MFC ein Fortschritt sein kann. Ich würde auch heutzutage die oben erwähnten Programme nicht mehr in C schreiben wollen, aber ich konnte damals schlichtweg kein C++, und die mir zur Verfügung stehenden C++-Compiler waren damals auch eher sehr lausig. Da ich Windows als Entwicklungsplattform in absehbarer Zeit nicht verlassen können werde, werde ich damit leben müssen, mit Windows zu arbeiten. Und ich gehöre zu den Menschen, die IDEs bevorzugen, auch wenn die auf jedem System wieder anders sein mögen. Peter II schrieb: > also das scollrad unter VS2003 geht ohne Problem Tja, VS2003 ist auch was ganz anderes als VS2010, da waren immerhin zwei Versionen dazwischen. Daher sind Vergleiche sinnarm.
Rufus Τ. Firefly schrieb: > Tja, VS2003 ist auch was ganz anderes als VS2010, da waren immerhin > zwei Versionen dazwischen. Daher sind Vergleiche sinnarm. ich habe es gerade mit VS2010 getestet - es geht dort.
Peter II schrieb: > ich habe es gerade mit VS2010 getestet - es geht dort. Und Du hast auch exakt verstanden, welches Fenster und welche Liste darin ich meine?
Peter II schrieb: > Rufus Τ. Firefly schrieb: >> Versuch mal was mit dem Scrollrad anzufangen. > es ging um den c99 standard - nicht um das VS Nö, hier existieren, wie in fast jedem Thread, mehrere Diskussionen parallel vor sich hin. Peter II schrieb: >> . unübersichtlicher Explorer (Hierarchie-Linien!), > ich komm mit dem linux zeug auch nicht klar, explorer ist ok Das erklärt deine Beißreflexe, wenn es einer wagt etwas gegen MS zu sagen. ;-)
Angehängte Dateien:
-
screen.png
57 KB
Rufus Τ. Firefly schrieb: > Und Du hast auch exakt verstanden, welches Fenster und welche Liste > darin ich meine? denke schon
Peter II schrieb: > denke schon Sieht so aus. Genau das funktioniert auf meinem System (W7x64) nicht, bzw. nur mit zusätzlichen Hilfsmitteln wie o.g. XMouse Button Control. Selbst nach einem direkt in die Liste klicken scrollt das Mausrad diese Liste nicht. Die einzige Möglichkeit ist das "Anfassen" des Scrollbalkens bzw. das daraufherumklicken. Allerdings verwende ich auch den Standardmaustreiber und nicht das obszön aufgeblähte Maustreiberbubufunzpaket des Mausherstellers (hier: Logitech). Das Verhalten hat übrigens auch der Hersteller o.g. Maustools bestätigt und sein Werkzeug eigens auf diese Eigenheit angepasst. Dieses Maustool ist sowieso erforderlich, weil das Standardverhalten von Windows im Umgang mit dem Scrollrad sowieso äußerst beknackt ist (Scrollnachrichten landen im Fenster, das den Mausfocus hat, und nicht in dem Fenster, über dem sich der Mauszeiger befindet).
Rufus Τ. Firefly schrieb: > Sieht so aus. Genau das funktioniert auf meinem System (W7x64) nicht, hier 32bit - aber SP1 vom Studio installiert > Allerdings verwende ich auch den Standardmaustreiber und nicht das > obszön aufgeblähte Maustreiberbubufunzpaket des Mausherstellers (hier: > Logitech). ich auch nicht, maus wird angsteckt und gut ist. > Dieses Maustool ist sowieso erforderlich, weil das Standardverhalten von > Windows im Umgang mit dem Scrollrad sowieso äußerst beknackt ist > (Scrollnachrichten landen im Fenster, das den Mausfocus hat, und nicht > in dem Fenster, über dem sich der Mauszeiger befindet). das ist geschmacksache, kann es zwar nachvollziehen, aber gestört hatte es mich noch nie.
Peter II schrieb: > hier 32bit - aber SP1 vom Studio installiert Vielleicht haben sie's da repariert. Zwar nutze ich das SP1 jetzt auch, aber auf das reparierte Scrollen will ich nicht verzichten.
Peter II schrieb: > das doch mal bitte was ihr von dem Standard so dringend braucht, ich > hatte zumindest noch nichts vermisst. was ich immer extrem vermisse sind benamte Initializer für struct-member keine Ahnung wie das offiziell heißt, aber ich mein das:
1 | struct A |
2 | {
|
3 | int i; |
4 | int j; |
5 | };
|
6 | |
7 | |
8 | |
9 | A a = { .i=1, |
10 | .j=2 |
11 | };
|
Diese Initialiserungen sind unter C90 eine beachtliche Fehlerquelle.
lanai schrieb: > Peter II schrieb: >> Rufus Τ. Firefly schrieb: >>> Versuch mal was mit dem Scrollrad anzufangen. >> es ging um den c99 standard - nicht um das VS > Nö, hier existieren, wie in fast jedem Thread, mehrere Diskussionen > parallel vor sich hin. Wie lanai schon andeutete: Der TO stieg nach zwei Posts aus. Warum macht ihr für solche wiederkehrenden Themen nicht einen separaten Thread auf? Der könnte sogar fixiert werden. Bedarf ist scheinbar vorhanden, wenn die Moderation hier schon hijacked.
Jean G. schrieb: > Wie lanai schon andeutete: Der TO stieg nach zwei Posts aus. > Warum macht ihr für solche wiederkehrenden Themen nicht einen separaten > Thread auf? Der könnte sogar fixiert werden. Bedarf ist scheinbar > vorhanden, wenn die Moderation hier schon hijacked. Oder man könnte die Diskussion in einen eigenen Thread abspalten. Ich weiß aber nicht wie gut oder ob überhaupt die Foren-Software das unterstützt. Falls man mühsam von Hand jeden einzelnen Post verschieben müsste, dann könnte ich gut verstehen dass das keiner freiwillig machen will, würde mir genau so gehen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.