hier gibt es ja diese tolle Tabelle für den Compiler Support der einzelnen C++11-Sprachfeatures. Kennt ihr etwas Ähnliches für den Compiler Support der Standardbibliotheksneuerungen?

Bzw. ganz allgemein: Wie geht ihr im Moment vor, um portablen Code zu schreiben (mich interessieren hierbei hauptsächlich MS VC++ und GCC)? Nehmt ihr z. B. array , thread , async u.ä. aus dem namespace std oder tr1 oder vielleicht doch lieber die Boost-Variante, um auf der sicheren Seite zu sein? Woher weiß ich, welche Elemente der Standard Lib zu welchem Grad von den einzelnen Compilern bereits unterstützt werden?

Bzw. ganz allgemein: Wie geht ihr im Moment vor, um portablen Code zu schreiben

Ich frage mich als erstes, was portabel für mich heißt. (-> Welche Compiler / Versionen ich unterstützen will.)
VC11 hat bereits (fast?) die gesamte Standardbibliothek implementiert, und da die immer schön die Messlatte für die untere Schmerzgrenze festlegen, nutze ich alles was die können.

Für den GCC kann der Status der Standardbibliothek hier nachgelesen werden:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x
Eine Tabelle, die die verschiedenen Implementationen vergleicht ist mir jetzt nicht bekannt.

Beruflich: Wir haben mit dem IBM XLC 12.0 für AIX noch eine prä-C++11 Standardbibliothek im Gepäck. Das knackt ab und zu, da unter VS10 entwickelt wird. Ich bin am überlegen, eigene Header zu implementieren, die je nach Plattform den shared_ptr aus std::tr1 oder std in einen neutralen Namensraum importieren. Aktuell nutzen wir z.B. std::tr1::shared_ptr, müssen dafür aber unter Linux <tr1/memory> an Stelle von <memory> einbinden. Ist alles noch nicht so optimal...

[...] Ich bin am überlegen, eigene Header zu implementieren, die je nach Plattform den shared_ptr aus std::tr1 oder std in einen neutralen Namensraum importieren. Aktuell nutzen wir z.B. std::tr1::shared_ptr, müssen dafür aber unter Linux <tr1/memory> an Stelle von <memory> einbinden. Ist alles noch nicht so optimal...

Das haben die bei Boost.TR1 ja schon so gemacht. Sofern vorhanden, wird das "native" TR1 verwendet, sofern irgendwie vorhanden. Dann schreibst du also

#include <boost/tr1/memory.hpp>

und std::tr1::shared_ptr steht zur Verfügung. Vielleicht kannst du dir das auch von denen abgucken. Die machen das mit Makros:

#include "config.hpp" // definiert ein paar Makros
#include <memory>
#include TR1_HEADER(memory)

(oder so ähnlich)

cooky451 schrieb:

Ich frage mich als erstes, was portabel für mich heißt. (-> Welche Compiler / Versionen ich unterstützen will.)
VC11 hat bereits (fast?) die gesamte Standardbibliothek implementiert, und da die immer schön die Messlatte für die untere Schmerzgrenze festlegen, nutze ich alles was die können.

Mich interessieren konkret (zur Zeit zumindest noch) VC10 und GCC 4.6.3.

DrakoXP schrieb:

Für den GCC kann der Status der Standardbibliothek hier nachgelesen werden:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x

Danke! Das ist doch schon einmal ein guter Anfang.

DrakoXP schrieb:

Eine Tabelle, die die verschiedenen Implementationen vergleicht ist mir jetzt nicht bekannt.

Hat nicht jemand von euch ein Wiki oder Blog, wo er einmal so eine Tabelle starten möchte?

krümelkacker schrieb:

Das haben die bei Boost.TR1 ja schon so gemacht. Sofern vorhanden, wird das "native" TR1 verwendet, sofern irgendwie vorhanden.

Hm, also mir scheint es fast so, als sei es im Moment die beste Strategie, wo es geht, einfach Boost zu benutzen. Oder hat das irgendwelche Nachteile (außer, dass man sich Boost ans Bein bindet)?

Privat: Ich setze ein, was der (aktuell einzige) Zielcompiler meines Projektes zur Verfügung stellt. Da das VS10 ist, der Teile noch nicht umgesetzt hat (z.B. sinnvolles Emplacement in Containern, *gna*) habe ich wenig Bedenken, dass GCC das nicht kann, sollte ich in nem halben Jahr oder so mal die Portierung wagen.

Beruflich: Wir haben mit dem IBM XLC 12.0 für AIX noch eine prä-C++11 Standardbibliothek im Gepäck. Das knackt ab und zu, da unter VS10 entwickelt wird. Ich bin am überlegen, eigene Header zu implementieren, die je nach Plattform den shared_ptr aus std::tr1 oder std in einen neutralen Namensraum importieren. Aktuell nutzen wir z.B. std::tr1::shared_ptr, müssen dafür aber unter Linux <tr1/memory> an Stelle von <memory> einbinden. Ist alles noch nicht so optimal...

Ich glaube es ja nicht, da ist doch tatsächlich noch einer, der IBM XLC unter AIX einsetzt . Wir haben allerdings nocht XLC 9.0. Ist die iostream-library bei der 12.0 immer noch so grottenlangsam?

Zum Thema: XLC 9.0 hat noch gar nichts von C++11 und so verwenden wir gar nichts von den neuen Features. Und das wird wahrscheinlich noch lange so bleiben.

Ist die iostream-library bei der 12.0 immer noch so grottenlangsam?

Ehrlich gesagt keine Ahnung. Unsere C++-Komponenten sind im Server, da hängt oben ne CORBA-Schnittstelle drüber und unten die Datenbank. Logs gehen iirc über log4cplus oder was in der Art, aber mit der Performance auf den AIXen hab ich mich noch nicht beschäftigen dürfen.