Perché le librerie e i framework C ++ non usano mai i puntatori intelligenti?

Ho letto in alcuni articoli che i puntatori grezzi non dovrebbero quasi mai essere usati. Invece dovrebbero sempre essere racchiusi all'interno di puntatori intelligenti, che siano puntatori con ambito o condivisi.

Tuttavia, ho notato che framework come Qt, wxWidgets e librerie come Boost non ritornano mai né si aspettano puntatori intelligenti, come se non li usassero affatto. Al contrario, restituiscono o si aspettano puntatori non elaborati. C'è qualche motivo per quello? Devo stare lontano dai suggerimenti intelligenti quando scrivo un'API pubblica e perché?

Mi chiedo solo perché i consigli intelligenti sono raccomandati quando molti grandi progetti sembrano evitarli.

A parte il fatto che molte librerie sono state scritte prima dell'avvento dei puntatori intelligenti standard, la ragione principale è probabilmente la mancanza di un'interfaccia binaria standard (ABI) per applicazioni C ++.

Se stai scrivendo una libreria solo intestazione, puoi passare puntatori intelligenti e contenitori standard al contenuto del tuo cuore. La loro fonte è disponibile per la tua libreria al momento della compilazione, quindi fai affidamento sulla stabilità delle loro interfacce da sola, non delle loro implementazioni.

Ma a causa della mancanza di ABI standard, generalmente non è possibile passare questi oggetti in modo sicuro oltre i confini del modulo. Un GCC shared_ptrè probabilmente diverso da un MSVC shared_ptr, che può anche differire da un Intel shared_ptr. Anche con lo stesso compilatore, queste classi non sono garantite per essere binarie compatibili tra le versioni.

La linea di fondo è che se si desidera distribuire una versione predefinita della propria libreria, è necessario un ABI standard su cui fare affidamento. C non ne ha uno, ma i produttori di compilatori sono molto bravi sull'interoperabilità tra le librerie C per una determinata piattaforma: esistono di fatto standard.

La situazione non è buona per C ++. I singoli compilatori possono gestire l'interoperabilità tra i propri binari, quindi hai la possibilità di distribuire una versione per ogni compilatore supportato, spesso GCC e MSVC. Alla luce di ciò, la maggior parte delle librerie esporta semplicemente un'interfaccia C, e ciò significa puntatori non elaborati.

Il codice non di libreria dovrebbe, tuttavia, preferire generalmente puntatori intelligenti rispetto a raw.

Ci possono essere molte ragioni. Per elencarne alcuni:

1. Puntatori intelligenti sono diventati parte dello standard solo di recente. Fino ad allora facevano parte di altre biblioteche
2. Il loro uso principale è quello di evitare perdite di memoria; molte librerie non hanno una propria gestione della memoria; Generalmente forniscono utilità e API
3. Sono implementati come wrapper, poiché in realtà sono oggetti e non puntatori. Che ha costi aggiuntivi di tempo / spazio, rispetto ai puntatori non elaborati; Gli utenti delle librerie potrebbero non voler avere tali costi generali

Modifica : l'utilizzo dei puntatori intelligenti è una scelta completamente sviluppata dagli sviluppatori. Dipende da vari fattori.

1. Nei sistemi critici per le prestazioni, potresti non voler utilizzare i puntatori intelligenti che generano sovraccarico

2. Nel progetto che richiede la compatibilità con le versioni precedenti, potresti non voler utilizzare i puntatori intelligenti con caratteristiche specifiche di C ++ 11

Edit2 Esiste una serie di più downvotes nell'arco di 24 ore a causa del passaggio sottostante. Non riesco a capire perché la risposta sia stata sottoposta a downgrade anche se di seguito è solo un suggerimento aggiuntivo e non una risposta.
Tuttavia, C ++ ti aiuta sempre ad avere le opzioni aperte. :) per esempio

template<typename T>
struct Pointer {
#ifdef <Cpp11>
  typedef std::unique_ptr<T> type;
#else
  typedef T* type;
#endif
};

E nel tuo codice usalo come:

Pointer<int>::type p;

Per coloro che affermano che un puntatore intelligente e un puntatore non elaborato sono diversi, sono d'accordo. Il codice sopra era solo un'idea in cui si può scrivere un codice che è intercambiabile solo con un #define, questa non è una coazione ;

Ad esempio, T*deve essere eliminato esplicitamente ma non un puntatore intelligente. Possiamo avere un modello Destroy()per gestirlo.

template<typename T>
void Destroy (T* p)
{
  delete p;
}
template<typename T>
void Destroy (std::unique_ptr<T> p)
{
  // do nothing
}

e usalo come:

Destroy(p);

Allo stesso modo, per un puntatore non elaborato possiamo copiarlo direttamente e per un puntatore intelligente possiamo utilizzare operazioni speciali.

Pointer<X>::type p = new X;
Pointer<X>::type p2(Assign(p));

Dov'è Assign()come:

template<typename T>
T* Assign (T *p)
{
  return p;
}
template<typename T>
... Assign (SmartPointer<T> &p)
{
  // use move sematics or whateve appropriate
}

Esistono due problemi con i puntatori intelligenti (pre C ++ 11):

• non standard, quindi ogni libreria tende a reinventare la propria (problemi di NIH syndrom e dipendenze)
• costo potenziale

Il puntatore intelligente predefinito , in quanto è gratuito, è unique_ptr. Sfortunatamente richiede la semantica di spostamento in C ++ 11, che è apparsa solo di recente. Tutti gli altri puntatori intelligenti hanno un costo ( shared_ptr, intrusive_ptr) o hanno una semantica meno che ideale ( auto_ptr).

Con C ++ 11 dietro l'angolo, portando un std::unique_ptr, si sarebbe tentati di pensare che finalmente è finita ... Non sono così ottimista.

Solo alcuni compilatori importanti implementano la maggior parte di C ++ 11 e solo nelle loro versioni recenti. Possiamo aspettarci che le principali biblioteche come QT e Boost siano disposte a mantenere la compatibilità con C ++ 03 per un po ', il che preclude in qualche modo l'ampia adozione dei nuovi e brillanti puntatori intelligenti.

Non dovresti stare lontano dai puntatori intelligenti, hanno il loro uso soprattutto nelle applicazioni in cui devi passare un oggetto.

Le librerie tendono a restituire un valore o a popolare un oggetto. Di solito non hanno oggetti che devono essere utilizzati in molti luoghi, quindi non è necessario che utilizzino i puntatori intelligenti (almeno non nella loro interfaccia, potrebbero usarli internamente).

Potrei prendere ad esempio una libreria su cui stiamo lavorando, dove dopo alcuni mesi di sviluppo ho capito che in alcune classi abbiamo usato solo puntatori e puntatori intelligenti (3-5% di tutte le classi).

Passare variabili per riferimento era abbastanza nella maggior parte dei luoghi, usavamo i puntatori intelligenti ogni volta che avevamo un oggetto che poteva essere nullo e i puntatori grezzi quando una libreria che usavamo ci costringeva.

Modifica (non posso commentare a causa della mia reputazione): passare variabili per riferimento è molto flessibile: se vuoi che l'oggetto sia di sola lettura puoi usare un riferimento const (puoi ancora fare alcuni lanci cattivi per poter scrivere l'oggetto ) ma ottieni il massimo della protezione possibile (è lo stesso con i puntatori intelligenti). Ma sono d'accordo sul fatto che è molto più bello restituire l'oggetto.

Qt ha reinventato inutilmente molte parti della libreria Standard nel tentativo di diventare Java. Credo che ora abbia effettivamente i suoi puntatori intelligenti, ma in generale, non è quasi un apice del design. wxWidgets, per quanto ne so, è stato progettato molto prima che venissero scritti i puntatori intelligenti utilizzabili.

Per quanto riguarda Boost, mi aspetto pienamente che utilizzino i puntatori intelligenti ovunque sia opportuno. Potrebbe essere necessario essere più specifici.

Inoltre, non dimenticare che esistono puntatori intelligenti per imporre la proprietà. Se l'API non ha una semantica di proprietà, perché usare un puntatore intelligente?

Buona domanda. Non conosco gli articoli specifici a cui ti riferisci, ma ho letto cose simili di volta in volta. Il mio sospetto è che gli autori di tali articoli tendano a nutrire un pregiudizio contro la programmazione in stile C ++. Se lo scrittore programma in C ++ solo quando deve, quindi ritorna a Java o simili appena può, non condivide davvero la mentalità C ++.

Si sospetta che alcuni o la maggior parte degli stessi scrittori preferiscano i gestori di memoria per la raccolta dei rifiuti. Non lo so, ma penso diversamente da loro.

I puntatori intelligenti sono fantastici, ma devono mantenere i conteggi dei riferimenti. Il mantenimento dei conteggi comporta costi - spesso costi modesti, ma comunque costi - in fase di esecuzione. Non c'è nulla di sbagliato nel salvare questi costi usando puntatori nudi, specialmente se i puntatori sono gestiti da distruttori.

Una delle cose eccellenti di C ++ è il suo supporto per la programmazione di sistemi embedded. L'uso di puntatori nudi è parte di questo.

Aggiornamento: un commentatore ha correttamente osservato che il nuovo C ++ unique_ptr(disponibile da TR1) non conta i riferimenti. Il commentatore ha anche una diversa definizione di "puntatore intelligente" rispetto a quello che ho in mente. Potrebbe avere ragione sulla definizione.

Ulteriore aggiornamento: il thread dei commenti qui sotto è illuminante. Si consiglia di leggere tutto.

Esistono anche altri tipi di puntatori intelligenti. Potresti desiderare un puntatore intelligente specializzato per qualcosa come la replica di rete (uno che rileva se è stato effettuato l'accesso e invia eventuali modifiche al server o qualcosa del genere), conserva una cronologia delle modifiche, segnala il fatto che è stato effettuato l'accesso in modo che possa essere esaminato quando si salvano i dati su disco e così via. Non sono sicuro che farlo nel puntatore sia la soluzione migliore, ma l'uso dei tipi di puntatore intelligente incorporato nelle librerie potrebbe comportare il blocco delle persone e la perdita della flessibilità.

Le persone possono avere tutti i tipi di diversi requisiti e soluzioni di gestione della memoria oltre ai puntatori intelligenti. Potrei voler gestire la memoria da solo, potrei allocare spazio per le cose in un pool di memoria, quindi è allocato in anticipo e non in fase di esecuzione (utile per i giochi). Potrei usare un'implementazione garbage collection di C ++ (C ++ 11 lo rende possibile anche se non ne esiste ancora). O forse non sto facendo nulla di abbastanza avanzato da preoccuparmi di disturbarli, posso sapere che non dimenticherò oggetti non inizializzati e così via. Forse sono solo sicuro della mia capacità di gestire la memoria senza la stampella del puntatore.

Anche l'integrazione con C è un altro problema.

Un altro problema è che i puntatori intelligenti fanno parte dell'STL. C ++ è progettato per essere utilizzabile senza STL.

Dipende anche dal dominio in cui lavori. Scrivo motori di gioco per vivere, evitiamo boost come la peste, nei giochi il sovraccarico di boost non è accettabile. Nel nostro motore principale abbiamo finito per scrivere la nostra versione di stl (molto simile a ea stl).

Se dovessi scrivere un'applicazione per moduli, potrei prendere in considerazione l'uso di puntatori intelligenti; ma una volta che la gestione della memoria è una seconda natura, non avere un controllo granulare della memoria diventa abbastanza fastidioso.