3. Benutzt ihr schon fleißig die TR1-Features?

Benutzt ihr schon fleißig die TR1-Features?

  • F

    Wir brauchen es einfach nicht. Die Software ist über 16 Jahre alt...

    0
  • A

    Ja, ich benutze sie, wo ich sie auch gebrauchen kann. Ich versuche generell alles zu benutzen, was mir der Std. und TR1 anbieten.

    0
  • C

    Wir benutzen weder tr1 noch boost. Wir compilieren mit xLC 7.0 (wohoo - es gibt schon 10.0 und ab 9.0 wird tr1 unterstützt).

    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.

    0
  • A

    Ja, wir nutzen TR1 (und boost)

    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.

    0
  • S

    Ich benutze ein bisschen was von Boost (Bind, Function, Thread). Was mich an TR1 annervt ist, dass ich für den Microsoft Compiler schreiben muss

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

    0
  • A

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

    // 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. 😡

    0
  • ?

    Ich mach das etwa so:

    // _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.

    0
  • R

    Bei neueren GCCs (oder eher libstdc++s) ist #include <unordered_map> der Header für C++0x und #include <tr1/unordered_map> der für TR1.

    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 :).

    0
  • N

    Kundus schrieb:

    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.

    0
  • S

    Carstig schrieb:

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

    0
  • A

    Nexus schrieb:

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

    0
  • F

    Simon2 schrieb:

    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.

    0
  • Administrator

    Simon2 schrieb:

    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

    0
  • F

    Vista ist hier im Konzern auch offiziell verboten. Genauso wie Windows7.

    0
  • A

    Wir steigen im Oktober auf Windows 7 um (aktuell Windows XP Pro, davor NT4). Und das sind nicht gerade wenig Rechner... mehrere zehntausend Rechner. OK, es werden nicht alle auf einmal umgestellt... aber jeder PC der älter als 4 Jahre ist, darf durch einen neuen mit Win7 ersetzt werden. Es zeichnet sich sogar ab, das es die 64 Bit Version wird (da ist noch nicht das letzte Wort gesprochen).

    0
Anmelden zum Antworten