[C++] Fragen zum Umstieg von MS Visual Studio 2003 auf --> 2005

  • Ersteller Ersteller Green Mamba
  • Erstellt am Erstellt am
G

Green Mamba

Gast
Hallo zusammen,

ich bin gerade dabei mich mit Microsofts letzter IDE auseinander zu setzen. Nun bin ich ja schon länger auf Du und Du mit der 2003er Version, habe aber noch ein paar kleine Unklarheiten mit der neuen. :D

1. Wenn ich auf F5 drücke, wird einfach eine Debug-Session gestartet ohne vorher geänderte Klassen neu zu kompilieren. Gibts eine Möglichkeit, mit einem Tastendruck Änderungen neu zu kompilieren und danach eine neue Debug-Session zu starten?

2. Wenn ein Fehler beim kompilieren auftritt, sollte automatisch vom Fenster "Output" zum Fenster mit der Error-List gewechselt werden. Im alten Studio habe ich das vielleicht mal selbst irgendwo eingestellt, finde beim neuen Studio aber keine Möglichkeit dazu!?

3. Mein Programm wird spürbar langsamer im Debug-Mode ausgeführt als zu 2003er Zeiten. Schätzungsweise dauern aufwändige Programmteile 2-4 mal so lange wie mit der alten Version. Woran liegt das? Passiert da mittlerweile mehr beim Debuggen? Kann man dieses "mehr" auch deaktivieren?

So, das wären zunächst die wichtigsten Dinge. Ich hoffe mir kann da jemand Tipps geben? :)

Viele Grüße,
Mamba

PS: Ach ja, ich benutze jeweils die professional ultimate enterprise ... ach was weiß ich, einfach die teuerste umfangreichste Version der jeweiligen IDE, falls das wichtig ist. ;)
 
Zuletzt bearbeitet:
Hallo Green Mamba

1. Wenn man F6 drück wird das gesamte Projekt neu Kompiliert. Müsstest also F6 und dann F5 drücken.
2.Das wird bei mir automatisch angezeigt. Habe diese "Pinnadel" die oben rechts im Output Fenster Quer stehen.
3.Kann ich nichts zu sagen. Habe nur die 2005er Version benutzt.

Grüße

tewes
 
Danke schonmal für die Hinweise! :)

1. Naja, ich bin ziemlich faul, vor allem kompiliert meine Solution teils recht lange. Ich freu mich dann schon, wenn das Programmfenster aufgeht als Zeichen dass er durch ist!? Es muss doch eine Möglichkeit geben diesen Ablauf mit einem Tastendruck hinzubekommen, so wie es auch beim 2003er war!? Ich finde es übrigens auch schon recht hart von MS einfach mal die Semantik eines der wichtigsten Bedienelementes zu ändern.

2. Bei mir liegt das Output zusammen mit der Error-List auf dem 2. Monitor. Habe also keine Pinnadel... :D

3. Bin dann mal auf die Erfahrungen der anderen User gespannt. :)
 
Zu 3. : Der Debugcode ist ziemlich intensiv, dafür leider aber auch spürbar langsamer. Dafür ist die so gefundene Menge an Fehlern aber auch bedeutend höher. Lohnt sich imho. Und im Release-Mode ist es richtig fix :) Eventuell mal mit NDEBUG definiert und _DEBUG undefiniert eine Debug-Version kompilieren, das habe ich aber noch nicht probiert. Ob man das stellenweise ausstellen kann, weiß ich leider nicht :/
 
Naja, ich bin ziemlich faul, vor allem kompiliert meine Solution teils recht lange.
[spam]
Das ist der große Vorteil aller Visual Studio Versionen nach 6.0.
Mit einem MS Produkt arbeitet man nicht mehr an Projekten, sondern an Lösungen.
Das denke ich mir schon seit 5 Jahren. Aber jetzt musste ich es mal sagen :).
[/spam]

Auch zu 3.:
Da Compiler und Linker eh inkrementell arbeiten könnte man doch zuerst alle im Release-Mode erstellen. Dann nur in der Datei, in der man debuggen muss kurz was ändern (Leerzeichen rein, wieder löschen und speichern). Dann im Debug-Mode übersetzen.
So sollte doch nur die geänderte Datei übersetzt werden und nur zu der Datei die Debuginfo in der exe landen.

Aber vielleicht ist das auch Quatsch. Ich habe seit ein paar Jahren kein VS mehr in den Händen gehabt.
 
@Boron
Eine Solution ist einfach eine Sammlung beliebig vieler Projekte. Könnte wetten dass es Solutions bereits bei der Version 6 gab. ;)

Zu 3:
Glaube kaum dass das funktioniert, da debug und release dateien in unterschiedlichen Verzeichnissen landen. :)

@7H3 N4C3R
Eventuell mal mit NDEBUG definiert und _DEBUG undefiniert eine Debug-Version kompilieren...
Kenne mich nicht so wirklich mit diesen Variablen aus. Was würde das bewirken?
 
Na dann werden wir nie wissen, ob man durch meinen Vorschlag von oben die Geschwindigkeit der exe beim Debuggen etwas verbessern kann.

Dass das als dauerhafte Lösung nix taugt ist mir klar.
 
Zurück
Oben