Ich portiere gerade ein Projekt von Linux auf Windows. Während GCC in der
aktuellen Version sowohl #include <tr1/memory> als auch #include <memory>
unterstützt, geht bei VS2010 nur #include <memory>. Nun muß mein Projekt
aber auch noch VS2008 unterstützen. VS2008 kann ich hier mangels Setup nicht
testen, aber ich nehme an, daß es dort #include <tr1/memory> heißt, ist das
richtig? Falls nötig, mit welchen #ifdef's läßt sich zwischen 2008 und 2010
unterscheiden?

Danke

mit welchen #ifdef's läßt sich zwischen 2008 und 2010
unterscheiden?

http://sourceforge.net/apps/mediawiki/predef/index.php?title=Compilers#Microsoft_Visual_C.2B.2B

MfG f.-th.

http://www.boost.org/doc/libs/1_48_0/doc/html/boost_tr1.html

Die TR1-Erweiterungen sind bei Microsoft relativ spät dazugekommen, so um 2010 rum, glaub'ich. Und die haben sie in den "normalen" Header, also beispielsweise <memory> eingebaut. Das heißt, dass Du es sowieso nicht unter dem VS 2008 zum laufen bekommen wirst (denke ich mal). Du kannst es Dir natürlich einfach machen, in dem Du Dich nicht auf Herstellerspezifische TR1-Erweiterungen verlässt, sondern boost::tr1 als Bindeglied verwendest, #include <boost/tr1/memory.hpp>. Dieses #ifdef Zeugs haben sie Dir da nämlich schon abgenommen und wenn Dein Compiler/StdLib kein TR1 bietet, fällst Du damit auf die Boost-Implementierung zurück.

http://www.boost.org/doc/libs/1_48_0/doc/html/boost_tr1.html

Doch, die gehen mit einem Erweiterungs-Package auch unter VS2008. Allerdings
weiß ich eben nicht, ob sie dort <tr1/memory> heißen oder nur <memory>, weil
ich kein VS2008 installiert habe. Boost wäre am einfachsten, das ist richtig.
Bloß will der Kunde im Build-System Boost vermeiden, um nicht noch eine
Bibliothek warten zu müssen.

Ich helfe mir mit folgender Konstruktion:

#ifdef __GNUC__
#  define TR1_HEADER(header) <tr1/header>
#else
#  define TR1_HEADER(header) <header>
#endif

#include TR1_HEADER(memory)

Doch, die gehen mit einem Erweiterungs-Package auch unter VS2008. Allerdings weiß ich eben nicht, ob sie dort <tr1/memory> heißen oder nur <memory>, weil ich kein VS2008 installiert habe. [...]
Bloß will der Kunde im Build-System Boost vermeiden, um nicht noch eine
Bibliothek warten zu müssen.

Also ich fasse das mal so zusammen: Du schreibst Software, die der Kunde bauen soll. Unter VS2008. Und hast selbst keinen VS2008 installiert. Wenn der 2008er was von deinem Code nicht frisst, weißt du das also erst, wenn du den Kunden an der Strippe hast? Mutig

Also ich fasse das mal so zusammen: Du schreibst Software, die der Kunde bauen soll. Unter VS2008. Und hast selbst keinen VS2008 installiert. Wenn der 2008er was von deinem Code nicht frisst, weißt du das also erst, wenn du den Kunden an der Strippe hast? Mutig

Das Setup benötigt Boost, CGAL, GMP, ZLib, compiliert jeweils als Debug- und
Releaseversion. Die Sachen korrekt zu konfigurieren und CMake entsprechend
einzurichten, ist sehr aufwändig. Und nun das ganze für VS2008 wiederholen,
noch dazu mit dem Risiko, daß sich die Setups in die Quere kommen? Besser
nicht.

Wenn VS2008 tatsächlich etwas vom Code nicht nimmt, der unter Linux und
VS2010 compiliert, gibts Telefon. Ist glaub ich auch eine Frage der Effizienz,
daß man einem Kunden sagt "Meine Herren, Euer Compiler ist vier Jahre alt,
schauen wir mal, ob es dort geht, sonst reden wir nochmal."

Umgekehrt: du bist da über eine gcc-Besonderheit gestolpert. Der TR1-Spezifikation nach gehört der gesamte TR1-Kram in die normalen Standardheader.

Gehört das so? Ich hatte da nämlich mal vor einer Weile nachgeguckt und diese Information nicht gefunden. Habe ich sie übersehen oder bildest du dir das ein? Eine genaue Quellenangabe wär toll. Ich danke im voraus.

Edit: Ich zitiere 1.3/4 des TR1 Entwurfs

It is recommended either that additional declarations in standard headers be protected with a macro that is not defined by default, or else that all extended headers, including both new headers and parallel versions of standard headers with nonstandard declarations, be placed in a separate directory that is not part of the default search path.

Hab jetzt nicht gesucht. Aber da sollte es eine Lösung geben?

2.1.1 Additions to header <functional> synopsis
2.2.1 Additions to header <memory> synopsis

etc.

1.2 liest sich wie folgt:

This technical report describes four general categories of library extensions:

(...)

3. New library components declared as additions to existing standard heders, such as the mathematical special functions added to the headers <cmath> and <math.h> in clauses 5.2.1 and 5.2.2

und die neuen Header sind auch ohne irgendwelche Präfixe genannt.

1.3 (4) empfiehlt, so wie ich das lese, lediglich, dass die Bibliothek die Möglichkeit bieten sollte, reines C++03 ohne TR1 zu benutzen - entweder per Makroschalter, oder indem der Compiler durch Schalter dazu bewegt werden kann, seine Header aus dem einen oder anderen Verzeichnis zu beziehen. Im Fall der Verzeichnisvariante müssten die TR1-fähigen Header dann auch das bereitstellen, was in ihrem C++03-Pendant steht.

So oder so sollte der Verzeichnisname im benutzenden Code nicht auftauchen müssen.

[...]

Ich würde die Betonung anders setzen:

3. New library components declared as additions to existing standard heders

Umgekehrt: du bist da über eine gcc-Besonderheit gestolpert. Der TR1-Spezifikation nach gehört der gesamte TR1-Kram in die normalen Standardheader.

Ich helfe mir mit folgender Konstruktion:

#ifdef __GNUC__
#  define TR1_HEADER(header) <tr1/header>
#else
#  define TR1_HEADER(header) <header>
#endif

#include TR1_HEADER(memory)

Das ist hilfreich, danke!

Aber man muss es wahrscheinlich im Zweifel testen, ob der Compiler älteren tr1 Quelltext mit den aktuellen Headern ohne Code-Änderung richtig ausführt.

Würde sagen, teste das ohne tr1 unter einem neuen gnu, eventuell mit c++11, bzw. c++0x Schalter.
Wenn der Quelltext doch auf älteren Compilern laufen soll, kannst du ja immer noch die tr1 - Variante einbauen.

MfG f.-th.