"Backporting" nullptr a C++ - programmi pre-C++ 0x

Question

Più o meno ciò che suggerisce il titolo. Mentre sono not yet using C++0x mi piacerebbe essere preparato per quando succede, e vorrei anche ridurre la quantità di codice che devo riscrivere per utilizzare alcune delle sue funzionalità. In questo modo posso ottenere la compatibilità all'indietro e in avanti in una volta sola.

Uno dei più interessanti che ho trovato è nullptr, che ho usato più spesso di recente.

Dopo aver controllato la "Soluzione alternativa ufficiale" e Meyer's suggestion, ho deciso che mi piacerebbe utilizzarlo sia nel mio C++ che nei futuri programmi C++ 0x. La seconda parte è semplice: essendo una parola chiave, sarà semplicemente supportato il nullptr. Ma la prima parte mi sta causando un certo disagio.

La Meyers funzioni propositive come questo:

class nullptr_t { // ← this is my issue 
    // definition of nullptr_t 
} nullptr = { }; 

Il problema con tale proposta è che dichiara il tipo di essere dichiarato come std::nullptr_t come richiesto dal C++ 0x. Il che significa che la soluzione alternativa per "sentirsi nativi" deve essere eseguita riaprendo lo spazio dei nomi std:: per aggiungere un tipo. Ho la comprensione che è illegale fare in un programma C++ (a differenza dell'aggiunta delle specializzazioni che è apparentemente aggrottare-e-lasciar-andare-con-un-avvertimento).

Desidero utilizzare nullptr in un modo comodo E in un programma C++. Una possibilità avevo pensato stava dichiarando il tipo in un altro spazio dei nomi e poi portarlo nel usando using:

namespace mylibrary { 
class nullptr_t { 
    .... 
} nullptr = { }; 
// end namespace 
} 

// These would have to go in the header file. 
using mylibrary::nullptr; 
using mylibrary::nullptr_t; // apparently this is necessary as well? 

Questo sarebbe il modo corretto per farlo funzionare? Imporrebbe le direttive using, che impone anche un ordine specifico delle direttive #include. Avrei ragione ad aspettarmi che nessun codice pre-C++ 0x richiederebbe il tipo nullptr_t con namespace (come un tipo di argomento di funzione, ad esempio)? Funzionerebbe davvero "sentirsi nativo" se è fatto in questo modo?

---

Come un addendum, è una accolto o visto di buon occhio cosa da provare e un backport alcuni nifty C++ 0x cose a C++ per una migliore compatibilità e la codifica? Nel frattempo ho integrato questa soluzione e altre che sto lavorando su in a piece of software to be released.

Answer 1

Il motivo principale che non è permesso di aggiungere cose da namespace std è in modo da non complicare le cose che sono già lì. Questo potrebbe altrimenti essere facilmente fatto. Qualcosa che ho trovato in passato erano più definizioni per gli operatori di output per i contenitori istanziati con un tipo predefinito come std::vector<int>. Tuttavia, nullptr_t non è definito in questo spazio dei nomi e l'aggiunta di typedef dovrebbe essere abbastanza innocua. Cioè, definirei nullptr_t in uno spazio dei nomi diverso da namespace std e quindi aggiungere un typedef per nullptr_t a namespace std. La variabile nullptr deve essere dichiarata comunque nell'ambito globale poiché viene utilizzata non qualificata in C++ 2011.

Se il tipo std::nullptr_t è necessario dipende dal fatto che siate interessati ad aggiungere le firme utilizzando questo tipo. Ad esempio, std::shared_ptr<T> può essere confrontato con nullptr. Per questo, è necessario aggiungere sovraccarichi appropriati che menzionino il tipo std::nullptr_t (o utilizzare un altro nome per questo tipo).

Answer 2

A meno che non si può pensare a una ragione è necessario dichiarare un'altra oggetto di tipo nullptr_t (non posso), mi nascondevo il tipo di distanza e mettere nullptr nel namespace globale per simulare una parola chiave il più possibile :

namespace mylibrary 
{ 
    class nullptr_t 
    { 
     .... 
    }; 
} 

mylibrary::nullptr_t nullptr = { };