Utilizzo MS VC 2008 e per alcuni progetti compilatore Intel C++ 11.0. Vale la pena utilizzare le funzionalità di tr1 in produzione? Rimarranno in un nuovo standard?Vale la pena usare std :: tr1 in produzione?
Ad esempio, ora utilizzo stdext::hash_map. TR1 definisce std::tr1::unordered_map. Ma nell'implementazione degli Stati Uniti unordered_map è solo il loro stdext::hash_map, templatizzato in un altro modo.
Il mio consiglio sarebbe quello di utilizzare un alias per lo spazio dei nomi contenente gli elementi TR1 che si utilizzano. In questo modo, sarai in grado di "spostare" dall'uso della versione TR1 alla versione standard quando il tuo compilatore lo supporta.
namespace cpp0x = std::tr1;
cpp0x::unordered_map<std::string, int> mymap;
per un compilatore C++ 0x, la prima riga diventa:
namespace cpp0x = std;
e si può lasciare il resto da solo.
Sì, tutto ciò che è in tr1 sarà rimanere lì. Alcune cose saranno accettate in std ::, ma rimarranno anche in tr1. Quindi nessuno del tuo codice si interromperà una volta che il nuovo standard è terminato.
Perdonami: no, non lo faranno. Come descritto here:
due note sono state aggiunte alla proposta di far capire agli utenti che nel passaggio dal TR a norme future, i componenti TR non rimarrà nel namespace std :: TR1 e la configurazione i macro spariranno.
Ma vale la pena notare che i produttori di compilatori disposti a supportare tr1 ora, molto probabilmente non strapperanno la terra da sotto i piedi e forniranno una sorta di metodo di transizione.
Per il tr1::unordered_map essere consapevoli del fatto che ci sono molte diverse implementazioni di Hash Maps possibili e che l'implementazione eletta dallo standard è abbastanza classica ... ma potrebbe non essere la più performante per il vostro compito particolare.
Sfortunatamente lo standard non richiedeva l'implementazione di più strategie (anche se suppongo che avrebbe richiesto un bel po 'di lavoro).
unordered_map sarà nel nuovo standard, hash_map non sarà. Si noti che lo spazio dei nomi tr1 non è standard neanche.
Non sapevo che std :: tr1 non fosse standard. Non ho lo standard tr1 finale, ma la bozza che sto guardando (link PDF) dice: "Poiché le estensioni descritte in questo rapporto tecnico non fanno parte della libreria standard C++, non dovrebbero essere dichiarate direttamente nello spazio dei nomi std. Se non specificato diversamente, tutti i componenti descritti in questo rapporto tecnico sono dichiarati nello spazio dei nomi std :: tr1. ". http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf – Ben
@Ben TR1 non è normativo per C++. –
La stragrande maggioranza del codice di libreria che verrà aggiunto in C++ 0x è in circolazione da un po 'di tempo nello Boost C++ Libraries. Raccomanderei fortemente l'uso di Boost (ovvero boost::unordered_map), poiché funziona su un numero molto elevato di compilatori ISO C++ 1998 e continuerà a funzionare (probabilmente utilizzando l'implementazione incorporata del compilatore) su compilatori C++ 0x. Inoltre, non dovrai cambiare lo spazio dei nomi - mentre gli elementi di std :: tr1 che sono approvati verranno spostati in std - poiché sarà sempre disponibile in boost ::, e non dovrai preoccuparti su quali elementi di tr1 sono entrati nello standard. In breve, Boost è la strada da percorrere.
Non sarei totalmente d'accordo. Si ha il vantaggio della portabilità se si utilizza l'implementazione boost, ma si perdono ottimizzazioni specifiche della piattaforma e cose come il supporto IDE (ad esempio, l'eccellente supporto per shared_ptr <> nel debugger di Visual Studio). –
@the_mandrill, sono abbastanza sicuro che Boost utilizzerà l'implementazione standard sottostante se è disponibile ... hai qualche benchmark che indica che la versione boost è più lenta dove è disponibile la versione standard? Se sì, su quale piattaforma e con quale versione di Boost? –
Non conosco alcun benchmark, ma mi ricordo di aver confrontato la versione boost di shared_ptr con quella di VS.Net e quella di boost è apparsa molto più pesante, dato che richiama molti più file e deve risolvere i problemi in un numero di compilatori. Nel frattempo VS.Net è libero di essere ottimizzato per il compilatore locale. Non ho mai visto le implementazioni boost utilizzare le versioni locali. –
Non sono chiaro su cosa intendi per implementazione implementata dallo Standard. Lo standard prescrive il comportamento O(), non le implementazioni.Esiste un diverso insieme di comportamenti O() nei contenitori associativi? –
'O()' non è sempre significativo. Ad esempio, in termini di rehashing. Tutte le hashmap hanno l'inserimento costante ammortizzato, ma se non si ha il rehashing dinamico, alcuni inserimenti saranno molto lenti (come quando si attiva un realloc su un 'std :: vector :: push_back'). 'O (1)' offre un certo margine di manovra qui e se è necessario eseguire inserimenti frequenti in un processo critico, non è sufficiente. –