4. Migration Borland C++ nach Visual Studio 2010

Migration Borland C++ nach Visual Studio 2010


  • Hallo,

    ich habe vor kurzen angefangen, fast alle von mir noch gepflegten Borland C++ 5 Projekte nach Visual Studio 2010 zu migrieren.

    Dabei sind nun zwei Fragen aufgetaucht:

    1. Kann man Visual Studio auch ein Projekt erzeugen, daß a) in einem nicht leeren Ordner angelegt werden soll und b) nicht genauso heißt wie der Ordner?

    Bisher muß ich mich so behelfen, das Projekt so zu erzeugen, wie Visual Studio es sich einbildet, dann das Projekt dorthin zu verschieben, wo ich es haben will, und zu letzt das Projekt der bestehen Solution hinzufüge. Sehr umständlich.

    2. Viel schlimmer und ich habe noch keinen Workarround gefunden:

    Praktisch alle meine Projekte benutzen auch eine oder beide von mir erstellen Bibliotheken. Wie kann ich es schaffen, daß die Debugversionen meiner Anwendungen mit den Releaseversionen der Bibliotheken gebunden werden?

    Wenn ich es einfach so mache, erhalte ich die Fehlermeldung:
    error LNK2038: Konflikt ermittelt für "_ITERATOR_DEBUG_LEVEL":
    Der Wert "0" stimmt nicht mit dem Wert "2" in speed.obj überein.

    Wenn ich nun das Makro _ITERATOR_DEBUG_LEVEL=0 bei den Bibliotheken und und den Anwendungen setze, kommt:
    error LNK2005: __initp_misc_invarg ist bereits in LIBCMTD.lib(invarg.obj) definiert.
    und etliche andere

    Der Linker rät mir /NODEFAULT zusetzen. Wenn ich das mache, bestraft er mich mit:
    error LNK2001: Nicht aufgelöstes externes Symbol "_clock". und 299 andere

    Hat jemand eine Idee?

    mfg Martin

    0
  • A

    mgaeckler schrieb:

    2. Viel schlimmer und ich habe noch keinen Workarround gefunden:

    Praktisch alle meine Projekte benutzen auch eine oder beide von mir erstellen Bibliotheken. Wie kann ich es schaffen, daß die Debugversionen meiner Anwendungen mit den Releaseversionen der Bibliotheken gebunden werden?

    Ich stelle dann mal die offensichtliche Frage: Warum baust du nicht deine Bibliotheken auch in einer Debug-Version wie jeder andere auch?

    0

  • audacia schrieb:

    mgaeckler schrieb:

    2. Viel schlimmer und ich habe noch keinen Workarround gefunden:

    Praktisch alle meine Projekte benutzen auch eine oder beide von mir erstellen Bibliotheken. Wie kann ich es schaffen, daß die Debugversionen meiner Anwendungen mit den Releaseversionen der Bibliotheken gebunden werden?

    Ich stelle dann mal die offensichtliche Frage: Warum baust du nicht deine Bibliotheken auch in einer Debug-Version wie jeder andere auch?

    Sorry, ich vergaß dazu zu schreiben: Die Debugversionen der Bibliotheken sind eigentlich dazu gedacht, die Bibliotheken selber zu testen bzw. zu debuggen. Es wird u.a. relativ viel Debugoutput generiert, das die Anwendung extrem ausbremst.

    mfg Martin

    0
  • A

    mgaeckler schrieb:

    Sorry, ich vergaß dazu zu schreiben: Die Debugversionen der Bibliotheken sind eigentlich dazu gedacht, die Bibliotheken selber zu testen bzw. zu debuggen. Es wird u.a. relativ viel Debugoutput generiert, das die Anwendung extrem ausbremst.

    Okay, das sehe ich ein. Tatsächlich beobachte ich auch bei VC++ einen sehr großen Performanceunterschied zwischen Debug- und Release-Builder (zuweilen Faktor 10 oder größer).

    Nun unterstützt VC++ das Mischen von Debug- und Release-Code aber nicht (cf. [1]), d.h. du wirst dir viele Probleme einhandeln, wenn du es zu erzwingen versuchst. Deshalb würde ich beide Projekte im Debug-Modus belassen, dann aber folgendes ausprobieren:

    - Du erstellst eine neue Konfiguration in der Bibliothek (Kopie von "Debug"), aktivierst dort aber die Optimierungen des Compilers. Das dürfte die Performance verbessern.
    - Wenn das noch nicht effizient genug ist, erzwingst du sowohl in der Bibliothek als auch in deiner Anwendung _ITERATOR_DEBUG_LEVEL = 0 .
    - Wenn es noch schneller sein soll, schalte den (sehr langsamen) Debug-Heap aus (cf. [2]).
    - Außerdem gibt es noch Compiler-Switches, mit denen man das Range-Checking und so deaktivieren kann (cf. [3]).

    Das sollte das Debugging erträglicher machen.

    [1] https://stackoverflow.com/questions/11658915/mixing-debug-and-release-library-binary-bad-practice
    [2] https://stackoverflow.com/questions/3362895/visual-studio-app-running-extremly-slow-with-debug
    [3] http://randomascii.wordpress.com/2011/07/22/visual-c-debug-buildsfast-checks-cause-5x-slowdowns/

    0

  • audacia schrieb:

    [...]
    Das sollte das Debugging erträglicher machen.
    [...]

    Vielen Dank, ich habe befürchtet, daß es auf so eine Lösung hinausläuft. Nun gut, es gtibt schlimmeres

    mfg Martin

    0
Anmelden zum Antworten