2012-06-02 29 views
5

Sto lavorando su una libreria con due utenti finali diversi, uno dei quali utilizza gcc 4.5.3 e l'altro appena spostato in gcc 4.6.3. La libreria utilizza i nuovi puntatori intelligenti C++ 11 (in particolare unique_ptr) e compila bene su gcc 4.5.3. Tuttavia, tra queste due versioni gcc ha iniziato a supportare nullptr, quindi l'API di unique_ptr è stata modificata per corrispondere più strettamente allo standard. In tal modo la società il seguente codice è andato da fine a ambiguounique_ptr, nullptr e supporto gcc 4.5.xe 4.6.x

unique_ptr up(new int(30)); 
... 
if(up == 0) // ambiguous call now to unique_ptr(int) for 0 

C'è un ambiente pulito (vale a dire., Frase successiva) modo per cambiare il caso dichiarazione di cui sopra in modo che funzioni con e senza nullptr? Mi piacerebbe per evitare un controllo di configurazione e quindi una macro come il seguente (che credo funzionerà), se possibile

#if defined NULLPOINTER_AVAILABLE 
    #define NULLPTR (nullptr) 
#else 
    #define NULLPTR (0) 
#endif 

o è questo l'unico modo per ottenere il comportamento sto cercando?

risposta

3

Quali errori hai colpito?

#include <iostream> 
#include <memory> 
int main() { 
using namespace std; 
unique_ptr<int> up(new int(30)); 
if (up == 0) 
    cout << "nullptr!\n"; 
else cout << "bam!\n"; 
} 

compila bene con con g++ -std=c++0x -Wall nullptr.cpp -o nullptr (gcc 4.6.2).

Inoltre, passare attraverso N2431 carta da Stroustrup e Sutter su nullptr dove un uso simile (confronto con 0) è esplicitamente elencato in uno degli esempi.

+0

Hai ragione che il tuo esempio funziona (e il mio nella dichiarazione del problema per quella questione) quindi deve avere qualcosa a che fare con i tipi che sto effettivamente usando (non sto usando "int" ma una classe basata su modelli). Vedrò se riesco a trovare un esempio migliore che causa quello che sto vedendo e se non lo segnerò correttamente. – bpw1621

+0

@ bpw1621: sono sicuro che questo è qualcosa a che fare con il tipo effettivo. Sono * MoveConstructible * e * MoveAssignable *? Puoi verificarlo con i membri appropriati di 'type_traits' come' is_move_constructible'. – dirkgently

+0

Se sono tipi che causano l'ambiguità? Ho visto il costruttore del movimento nel set di sovraccarico, credo. – bpw1621