3. #include <tr1/memory>

#include <tr1/memory>

  • K

    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

    0
  • G

    krümelkacker schrieb:

    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.

    0
  • ?

    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)
    0
  • P

    geom schrieb:

    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 😉

    0
  • G

    pumuckl schrieb:

    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."

    0
  • K

    seldon schrieb:

    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.

    0
  • ?

    Im Header tr1/memory des gcc 4.6.1 steht drin, das man den Header nicht mehr unter c0x verwenden soll.

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

    0
  • ?

    Das zieht sich durch ISO/IEC DTR 19768 von vorne bis hinten durch. Die Tabellen, die beschreiben, wo was gefunden wird, nennen alle <memory>, <functional>, <cmath> etc., nicht etwa <tr1/memory>, <tr1/functional> und <tr1/cmath>. In den Überschriften heißt es

    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.

    0
  • P

    seldon schrieb:

    [...]

    Ich würde die Betonung anders setzen:

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

    0
  • G

    seldon schrieb:

    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! 👍

    0
  • ?

    Besser wäre es, beim GNU-C die exakte Version abzufragen, da das unter C++11 auch ohne dies tr technical-report bei den neuen Versionen funktionieren sollte.

    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.

    0
Anmelden zum Antworten