Unsere SW könnte boost vertragen oder auch xLC 10, aber dazu müsste die Administration sich bemühen, dieses in das "Image" einzubauen, mit dem alle unsere Entwicklungsserver bespielt werden... *seufz* da löse ich lieber den gordischen Knoten.

Ich weiß auch von meinen Kollegen, welche ein Datenbankprodukt entwickeln, daß sie weder tr1 noch boost benutzen: Aus dem Grund, daß der Code für verschiedenste OS und Plattformen entwickelt wird und da der kleinste gemeinsame Nenner genommen wird.

Wobei ich dazu sagen muss, das die Verwendung von der C++ Standardbibliothek, dem TR1 und boost erst mit mir in das Projekt kam. Was konkret bedeutet das es noch relativ wenig im Einsatz ist, da das Projekt schon seit vielen Jahren gepflegt wird, ich aber erst seit etwa 1,5 Jahren in der Firma bin.

Mir kam hierbei zugute, das es zu meinen Einstieg nur zwei andere Entwickler gab, und ich zudem der einzige Vollzeitentwickler war. Zudem konnte ich den Chef (der auch zu den Entwicklern zählt) bereits im Vorstellungsgespräch überzeugen - was mir einige Freiheiten im Projekt verschafft hat. Im wesentlichen kann man es auf folgenden Punkt bringen: Wenn es etwas gibt, das dem Projekt nützen kann, wird es auch erlaubt. Seien es nun Programmbibliotheken, Programmiertechniken, Refactoringmaßnahmen oder sinnvolle Fremdkomponenten.

Und inzwischen bin ich ohnehin für 90% der Entwicklung verantwortlich, so das mein Programmierstil ohnehin nach und nach mehr Anteil am Projekt bekommt.

#include <unordered_map>

und beim G++ Compiler es so angeben muss:

#include <tr1/unordered_map>

Wenn man in der TR1-Spec nachguckt, steht da auch nicht klipp und klar drin, wie die Header einzubinden sind. Zumindest blick ich da nicht durch, wie die sich das gedacht haben. Wenn man sich zB den tr1/memory header anguckt, sieht das nicht so aus, als könnte man das tr1-Verzeichnis einfach als Include-Suchpfad hinzufügen:

...

/**
 * @file tr1/memory
 * This is a TR1 C++ Library header. 
 */

...

#include <memory>  // <-- hier soll wohl die
                   // nicht-TR1 Version inkludiert werden

...

Da meine Programme (hauptsächlich "number chrunching") aber sowohl unter windows als auch unter Linux laufen müssen und ich mir Boost erlauben kann, verzichte ich auf das TR1-Zeugs.

Habe gerade mal auf stackoverflow nachgeguckt:
http://stackoverflow.com/questions/1228402/how-does-one-include-tr1
Das ist IMHO alles wenig überzeugend.

// tr1.hpp
#pragma once
#ifndef TR1_HPP
#define TR1_HPP
#ifdef __GNUG__
#include <tr1/functional>
#include <tr1/memory>
#else
#include <functional>
#include <memory>
#endif
#endif	// TR1_HPP

Und inkludiere diesen Header anstatt direkt die Tr1-Header. Und falls ein anderer Compiler das doch noch anders macht, kann man die zentrale tr1.hpp einfach ändern.

Aber eigentlich ne Sauerei vom C++-Komitee da nicht einfach klipp und klar zu sagen, wie wo der Header liegen soll. Die überlegen sich jeden anderen Mist, den wenig Leute brauchen, aber beim Tagesgeschäft (inkludieren) scheitert es.

// _MSC_VER == 1500 heißt VC 2008
#if defined(__GNUC__) || (defined(_MSC_VER) && _MSC_VER >= 1500)

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

#include TR1_HEADER(memory)
#include TR1_HEADER(functional)

#undef TR1_HEADER

namespace util {
  using ::std::tr1::shared_ptr;
  using ::std::tr1::function;
}

#else

#include <boost/shared_ptr.hpp>
#include <boost/function.hpp>

namespace util {
  using ::boost::shared_ptr;
  using ::boost::function;
}

#endif

Der Boost-Fallback ist da, um das ganze mit alten VC-Versionen noch kompilieren zu können.

Teilweise habe ich für eigene Kleinigkeiten sogar schon angefangen C++0x-Sachen zu verwenden. z.B. unique_ptr ist einfach zu toll um den nicht benutzen zu wollen :).

Benutzt ihr sie [die TR1-Features]?

Ja. Besonders bind und function brauche ich ab und zu. Selten shared_ptr oder array . Ich finds übrigens blöd, dass es keinen std::tr1::scoped_ptr gibt. Muss man wohl const std::auto_ptr oder im neuen Standard std::unique_ptr verwenden.

Artchi schrieb:

Ich habe in meinem Projekt folgendes in einen tr1.hpp Header reingeschrieben: [...]

Und inkludiere diesen Header anstatt direkt die Tr1-Header. Und falls ein anderer Compiler das doch noch anders macht, kann man die zentrale tr1.hpp einfach ändern.

Das ist zwar praktisch, aber erhöht leider die Kompilierzeiten, besonders wenn man mit vielen Headern in vielen Modulen arbeitet.

seldon schrieb:

Ich mach das etwa so:

Sieht interessant aus, könnte ich mir auch überlegen. Momentan habe ich noch drei separate Header für die meistgebrauchten Dinge.

...Aus dem Grund, daß der Code für verschiedenste OS und Plattformen entwickelt wird und da der kleinste gemeinsame Nenner genommen wird.

Japp - diese Abhängigkeiten sind die größte Hürde beim Einführen neuer Features.
So muss ich in einem bestimmten System-Umfeld immer noch mit einem C89-Compiler arbeiten oder in einem anderen führt schon das Erwähnen, dass Java 1.3 bereits Nachfolger hat zur fristlosen Kündigung.

Betriebssystemversionen sind da deutlich leichter zu wechseln.

Gruß,

Simon2.

Artchi schrieb:

Ich habe in meinem Projekt folgendes in einen tr1.hpp Header reingeschrieben: [...]

Und inkludiere diesen Header anstatt direkt die Tr1-Header. Und falls ein anderer Compiler das doch noch anders macht, kann man die zentrale tr1.hpp einfach ändern.

Das ist zwar praktisch, aber erhöht leider die Kompilierzeiten, besonders wenn man mit vielen Headern in vielen Modulen arbeitet.

Ich habe PCH eingeschaltet. Da fällt das nicht so auf. Und wenn es doch irgendwann überhand nimmt, muß ich halt das Ganze aufbrechen.

Aber zum Glück steht ja bald C++0x an. Dann hau ich TR1 raus.

Betriebssystemversionen sind da deutlich leichter zu wechseln.

HA! Schön wäre es... Mittlerweile ist das teuerste Ersatzeile für die alten Rechner zu finden die baugleich sind, weil ja alles maßgeschneidert ist, als es wohl wäre den ganzen Scheiss neu zu machen auf modernen Kisten. Aber erklär das dem Management. Denen doch egal.
Neue OS-Version? Vergiß es. Neuer Window Manager? Vergiß es. 64-bit? Vergiß es. Boost? Vergiß es. Java? Vergiß es.

Alles was neu ist, ist erst einmal böse und unnötig. Testweise mal alles auf mehreren Quad-Core Notebooks installiert und nichts ging mehr. Da treten auf einmal Nebenläufigkeitsprobleme auf, die auf Single-Core-Maschinen gar nicht existierten. Lösung? Alte Maschinen benutzen. Billiger als das zu fixen. Tolle Wurst.

Betriebssystemversionen sind da deutlich leichter zu wechseln.

Hmmm, dass haben unsere Beamte wohl irgendwie nicht mitbekommen:
Bundesbeamte rebellieren gegen Windows Vista

TR1 direkt ist bei mir noch nicht im Einsatz. Ich verwende Boost und habe darin alle Features von TR1 (oder zumindest habe ich noch nie eines vermisst). So kann ich auch diesem uneinheitlichem include Wirrwarr vorbeugen. Ich werde dann erst im neuen Standard die Boost Bibliotheken durch die entsprechenden Standardbibliotheken ersetzen. Und wahrscheinlich auch nur dort wo nötig oder einfach bei neuen Projekten.

Grüssli