MSVC++ 7.1 vs. 6.0
-
Geht's euch auch so? Ich bin vor ca. zwei Wochen endlich auf's 2003er Visual Studio umgestiegen, und habe vorher lange Jahre 6.0 verwendet.
Irgendwie bin ich ziemlich enttäuscht. Es ist vieles "anders", aber nichts davon ist besser. Im Gegenteil, der Großteil ist schlechter geworden, wie ich meine.
Zuerst die Pluspunkte:
+ Der Compiler unterstützt aktuelles C++ viel besser (leider ein sehr wichtiger Pluspunkt).
+ Der Compiler kann für P4 optimieren.
+ Das integrierte Platform SDK ist am aktuellen Stand.
Negativ:
- Was ist bitte mit der Browse Info passiert? Das war das geilste Feature von VC6. Klick auf "Go To Definition". Peng, ich bin dort. Dieses Goto-Kontextmenü wurde anscheinend von der BSC abgekoppelt und ist jetzt genauso langsam und unzuverlässig wie bei Borland. Die Browse Info gibt's zwar immer noch über diesen komischen Object Browser, aber ich habe heute zu meinem Entsetzen feststellen müssen, dass darin keine Makros verzeichnet waren, die nachweislich in einem inkludierten Headerfile deklariert waren. Also wieder raten, welche von den 5 Makrodefinitionen in 4 #ifdef-Schachtelungstiefen nun verwendet wird...
- Es ist kein Profiler mehr dabei.
- Die IDE braucht viel mehr RAM (ok, ich könnte auch welches kaufen, kostet ja nicht mehr die Welt...) und ist generell langsamer (zum Glück nicht sehr arg).
Leider kann ich wegen des ersten Pluspunktes nicht mehr gut zu Version 6 zurück, sonst würde ich das sofort tun.
-
Warum bist Du den auf VC7.1 umgestiegen, wenn VC8 gerade rausgekommen ist? Das hat sich ja nun wirklich nicht gelohnt...
Aber zu den Fakten: Ja, mit VC7.1 ist ein sehr geübter Programmierer der VC6 verwendet hat enttäuscht.
Bzgl. Profiler: Den gibt es ja kostenlos von Compuware (wenn Du VC7.1 in einer Box gekauft hast, war da sogar eine Postkarte dabei wo Du ihn bestellen kannst).
Kannst Ihn aber auch direkt runterladen:
http://www.compuware.com/media.asp?cid=3019X36Und wegen den Pluspunkten: VC8 ist noch viel mehr Standard-Konformer und man kann mit einer IDE auch für x64/IA64 und für Windows-Mobile entwickeln... also ich würde nach VC8 umstellen und jetzt nicht nach VC7.1.
-
-> Go To Definition/Go To Declaration gibts immer noch im Kontextmenü (Funktioniert ohne Probleme)
-> Profiler hast du eventl. nur bei deiner Version nicht (Standard statt Prof, etc.?)BTW: Benützt du gerne alte Compiler? Vor 2 Wochen hättest du genauso gut auf 2005 umsteigen können.
MfG SideWinder
-
SideWinder schrieb:
-> Go To Definition/Go To Declaration gibts immer noch im Kontextmenü (Funktioniert ohne Probleme)
Ich weiß, dass es das gibt. Es funktioniert aber nicht so wie im VC6. Geh mal zur Definition eines Makros. Da dauert's eine Weile, und dann springt er zu irgendeiner Definition dieses Makros, aber sicher nicht zur richtigen. Wenn überhaupt. Meistens sagt er bei mir, dass es nicht gefunden wurde.
Das mit der 2003er Version war einfach eine Husch-Husch-Aktion in der Firma. Wir sind gleichzeitig auf QT4 und VS 2003 umgestiegen und haben jetzt zwei Monate keine Zeit, uns noch zusätzlich mit diesbezüglichen Inkompatibilitäten mit der 2005er auseinanderzusetzen. Danach kommt eh 2005.
-
OT: Oh wai oh wai... QT4 auf Windows... macht das noch jemand ausser Euch?
-
Hehe. Die Qualität von dem Ding ist aber eigentlich recht überzeugend. Ich hab mich jetzt doch schon ziemlich tief reingewühlt und QT gebührend gequält, und es tut eigentlich wie es soll.
Die Grafikoperationen sind nicht gerade pfeilschnell, aber dafür können sie auch einiges. Und mit der angepriesenen Flickerfreiheit ist es auch nicht weit her, aber damit müssen wir vorerst leben. In der MFC hab ich noch immer alles flickerfrei gekriegt, auch wenn's teilweise krankhaft mühsam war. Hmpf.
-
Ich sehe das Problem mit QT eigentlich daran, dass es im Windows-Umfeld kaum verwendet wird und auch eine Platformunabhänhigkeit eigentlich nur Theorie ist, da die meisten Programmierer dann doch oft direkt die Win32-API verwenden, da mit QT nicht alles 100% Lösbar ist...
-
Das mit der Browse Info ist ja noch schlimmer als ich gedacht habe. Selbst wenn man sich die Sachen mühsam aus diesem Object Browser raussucht, zeigt er immer noch die falsche Definition an.
Z.B. such ich bei einem gerade ganz standardmäßig mit dem Wizard erzeugten MFC-Projekt BEGIN_MESSAGE_MAP im Object Browser. Wenn ich darauf doppelklicke, springt er mir zu der Definition ohne _AFXDLL, obwohl mit _AFXDLL compiliert wurde, wie man im Buildlog ersehen kann. Witzigerweise kennt der Object Browser auch eine GetThisMessageMap()-Methode, die aber in der angezeigten Variante des Makros gar nicht vorhanden ist.
Fazit: Browse Info ist total kaputtgemacht und unbrauchbar. Es gibt also keinen Grund, überhaupt noch mit Browse Info zu builden, denn raten kann ich selber auch. Und meistens besser. Schade, das war wirklich ein Feature, das ich am VC6 geliebt habe.