Visual C++, welche STL?
-
Hallo,
ich möchte in meiner MFC-Anwendung ein paar Klassen mit hilfe der STL programmieren, um sie später leicheter nach linux portieren zu können.
Allerdings erhalte ich beim kompilieren mit Warning Level 4 extrem viele Warnungen. Hab ein wenig gesucht, aber nur gefunden, dass man sich damit abfinden muss... (außer halt die warnungen mit pragma abstellen). Benuutzt man überhaupt die mitgelieferte STL, oder gibt es da Alternativen? Hab da mal was von STLPort gelesen. Da muss man sicher auch einiges wieder beachten. Wichtig ist mir, das die libs standardkonform sind und der code halt auch (weitestgehend) unter linux läuft.
Was sollte ich eurer Meinung nach verwenden?
-
Wenn du wirklich platformübergreifend programmieren willst, solltest du dich an den ISO-C++ Standard halten. In dem Fall auch die Standardlibrary von C++ benutzen. Die Warnings im VC6 wirst du nicht wegbekommen (außer mit pragma), weil der VC6 seeeehr alt ist. Es gab mittlerweile 3 neue Versionen, und der VC6 wird nächstes Jahr 10 Jahre alt. ZEHN Jahre!!! Nix mit ISO-C++ konformer Compiler. Wundert dich jetzt noch was?
Also, steig auf einen aktuellen VC++ um, mind. 2003er Version (v7.1) und du hast keine Probleme mehr, da ab dieser Version der VC erst ISO-konform ist.
-
Naja, weiss nicht ob ich Lust habe jetzt umzusteigen. Kann ich mein VC++ 6.0 Projekt wirklich problemlos mit VC7 konvertieren?
-
Also, wenn du weiterhin mit einer veralteten IDE programmiern willst, dann bleib beim VC6.
Ach ich vergaß den alten Compiler.Wenn du einen tollen Compiler und IDE arbeiten willst, dann nimm dir das neue Studio. Gibt's ja als Express Version sogar gratis, wenn mich nicht alles täuscht.
Mein Freund hat das neuen 2005er Studio und ist restlos begeistert, da der Debugger sogar in STL-Container reinguckt.
Also das ist wirklich komfortabel.Und das sage ich als Linuxer!
-
@hehejo
Das ist nicht ganz die Antwort auf meine Frage. Mir ist schon klar, dass das neue Studio "toller" ist. Habe auch schon damit gearbeitet. Ist aber schon länger her. Ich würde halt gerne den Aufwand wissen, wenn man von VS6 auf VS7 umsteigt.Am meisten habe ich Angst davor, dass der code zwar kompliert, aber irgendwann später probleme auftreten.
-
Am meisten habe ich Angst davor, dass der code zwar kompliert, aber irgendwann später probleme auftreten.
Probleme in welcher Form?
-
Wenn Du von VC6 auf VC8 umsteigst, wirst Du i.d.R. Hand anlegen müssen, da der aktuelle Compiler viel besser Standard-Conform ist und VC6 viel mehr unfug durchgehen lies. Aber das lässt sich alles lösen.
Nimm die kostenlose VC2005 Express Edition. Die ist für eine Platformunabhängige Programmierung bestens geeignet.
-
Das sind doch die vielen Probleme um die man "herumgearbeitet" hat. Und die
Bugs in Bibliotheken wie MFC und ATL für die man Bugfixes gefunden oder selbst
gemacht hat.
Und dann stellt sich die Frage läuft dieser "gefixte" Code dann auch noch mit
dem neuen besseren Compiler und den aktuellen Bibliotheken oder hab ich dann
plötzlich erstmal neue Fehler die ich bisher nicht gekannt hab oder für die
ich in VC6 schon mal Lösungen gefunden hab.
Un damit meine ich in erster Linie nicht den Compiler selbst.
-
Redhead schrieb:
Das sind doch die vielen Probleme um die man "herumgearbeitet" hat. Und die
Bugs in Bibliotheken wie MFC und ATL für die man Bugfixes gefunden oder selbst
gemacht hat.
Und dann stellt sich die Frage läuft dieser "gefixte" Code dann auch noch mit
dem neuen besseren Compiler und den aktuellen Bibliotheken oder hab ich dann
plötzlich erstmal neue Fehler die ich bisher nicht gekannt hab oder für die
ich in VC6 schon mal Lösungen gefunden hab.Genau so ist es. Aber da hier ja weder MFC noch ATL verwendet werden soll (da ja nach Linux portiert wird) spielt es ja keine Rolle.
-
Der Fragesteller hat aber eine MFC-Anwendung! Er bräuchte mind. die Standard-Version von einem aktuellen VC++, die Express Edition würde ihm nicht weit bringen.
-
Ich habe eine MFC Anwendung, aber ich will einen Teil als DLL auslagern. Dieser Teil soll später(mit Anpassungen) auch unter Linux laufen. Da ich das ganze für Windows eh als DLL realisiere, könnte ich das natürlich auch mit dem gcc unter windows programmieren. Dann könnte ich den Code leicht in eine Linux Anwendung integrieren. Mir wäre es aber im Moment lieber, wenn ich das ganze Projekt in einer Entwicklungsumgebung hätte. Vor allem könnte ich so nach und nach von MFC auf STL umstellen.
P.S. Eine DLL mit dem MinGW zu erstellen sollte kein Problem sein, oder?
-
Noch ne Frage. Was ist denn vom Preis/Leitungsverhältnis gesehen die beste Updatemöglichkeit für Visual Studio 6.0?
Es gibt ein Updata auf Microsoft MS Visual Studio Standard 2005 für knapp über 200 EUR. Traugt die Standardversion was? Finde das relativ günstig (im Verglich zu den Preisen der anderen Produkte. Ist da ein Haken?
-
Ich bin nicht sicher ob ein Upgrade möglich ist. Wie kann ich dennoch STL unter VC 6 verwenden? Hat jemand STLPort schonmal probiert?
-
Die VS2005 Std. ist in den meisten Fällen vollkommen ausreichend. Siehe:
http://msdn.microsoft.com/vstudio/products/compare/default.aspxIch würde auf keinen Fall VC6 für (echtes) C++ verwenden, da der Compiler schon über 8 Jahre alt ist und von "Standards" noch nie was gehört hat.
-
Naja, es gibt ja immerhin 6 Service-Packs. Die haben daran gar nichts geändert?
-
edm schrieb:
Naja, es gibt ja immerhin 6 Service-Packs. Die haben daran gar nichts geändert?
Nein, die haben nur gravierende Fehler behoben, nicht aber den Compiler Standard-Conform gemacht...
-
Naja, der STL teil soll ja eigentlich eh in eine DLL. Diese könnte ich dann genausogut mit dem MinGW erstellen. So kann ich halt nicht nach und nach den code von MFC portieren.
Kann ich das ganze eigentlich dann noch vernünfig debuggen? In MFC-DLLs kann ich ja breakpoints setzen...
-
Wie "STL in DLL"... wie soll denn das gehen? STL sind templates, die kann man nicht in eine DLL packen...
-
Du kannst das DLL-Projekt debuggen, ja. Zumindest im VS und in anderen Umgebungen sicher auch