Perché inseriamo le funzioni dei membri privati ​​nelle intestazioni?

La risposta al motivo per cui inseriamo le variabili dei membri privati ​​nelle intestazioni C ++ è che la dimensione della classe deve essere nota nei punti in cui vengono dichiarate le istanze in modo che il compilatore possa generare codice che si sposta in modo appropriato nello stack.

Perché dobbiamo inserire i membri privati ​​nelle intestazioni?

Ma c'è qualche motivo per dichiarare funzioni private nella definizione della classe?

L'alternativa sarebbe essenzialmente l'idioma del brufolo, ma senza il superfluo indiretto.

Questa funzionalità linguistica è più di un errore storico?

Le funzioni dei membri privati ​​possono essere virtuale nelle implementazioni comuni di C ++ (che usano una vtable) è necessario che l'ordine e il numero specifici delle funzioni virtuali siano conosciuti da tutti i client della classe. Questo vale anche se una o più funzioni dei membri virtuali lo sono private.

Potrebbe sembrare che sia come "mettere il carrello davanti al cavallo", perché le scelte di implementazione del compilatore non dovrebbero influenzare le specifiche del linguaggio. Tuttavia, in realtà il linguaggio C ++ stesso è stato sviluppato contemporaneamente a un'implementazione funzionante ( Cfront ), che utilizzava vtables.

Se hai consentito l'aggiunta di metodi a una classe al di fuori della sua definizione, potrebbero essere aggiunti ovunque , in qualsiasi file, da chiunque.

Ciò darebbe immediatamente a tutto il codice client un accesso banale ai membri di dati privati ​​e protetti.

Una volta terminata la definizione della classe, non c'è modo di contrassegnare alcuni file come appositamente benedetti dall'autore per estenderla: ci sono solo unità di traduzione piatte. Quindi, l'unico modo ragionevole per dire al compilatore che un determinato insieme di metodi è ufficiale, o benedetto dall'autore della classe, è dichiararli all'interno della classe.

Nota che abbiamo accesso diretto alla memoria in C ++, il che significa che in genere è banale creare un tipo di ombra con lo stesso layout di memoria della tua classe, aggiungere i miei metodi (o semplicemente rendere pubblici tutti i dati) e reinterpret_cast. Oppure posso trovare il codice della tua funzione privata o smontarlo. Oppure cerca l'indirizzo della funzione nella tabella dei simboli e chiama o direttamente.

Questi identificatori di accesso non tentano di prevenire questi attacchi, perché ciò non è possibile. Indicano solo come dovrebbe essere usata una classe.

La risposta accettata spiega questo per le funzioni private virtuali , ma risponde solo a un aspetto specifico della domanda, che è considerevolmente più limitato di quello che l'OP ha chiesto. Quindi, dobbiamo riformulare: perché siamo tenuti a dichiarare le funzioni private non virtuali nelle intestazioni?

Un'altra risposta invoca il fatto che le classi devono essere dichiarate in un blocco, dopo di che sono sigillate e non possono essere aggiunte. Questo è quello che faresti omettendo di dichiarare un metodo privato nell'intestazione e cercando di definirlo altrove. Bel punto. Perché alcuni utenti della classe dovrebbero essere in grado di aumentarlo in modo che altri utenti non possano osservare? I metodi privati ​​ne fanno parte e non ne sono esclusi. Ma poi chiedi perché sono inclusi e sembra un po 'tautologico. Perché gli utenti della classe devono saperlo? Se non fossero visibili, gli utenti non potrebbero aggiungerne nessuno, e hey presto.

Quindi, volevo fornire una risposta che, anziché includere semplicemente i metodi privati ​​per impostazione predefinita, fornisca punti specifici a favore della loro visibilità agli utenti. Un motivo meccanicistico per funzioni private non virtuali che richiedono una dichiarazione pubblica è riportato nel GotW # 100 di Herb Sutter sull'idioma di Pimpl come parte della sua logica. Non parlerò di Pimpl qui, poiché sono sicuro che lo sappiamo tutti. Ma ecco il bit rilevante:

In C ++, quando cambia qualcosa nella definizione della classe di un file di intestazione, tutti gli utenti di quella classe devono essere ricompilati, anche se l'unica modifica è stata ai membri della classe privata a cui gli utenti della classe non possono nemmeno accedere. Questo perché il modello di build di C ++ si basa sull'inclusione testuale e perché C ++ presuppone che i chiamanti conoscano due cose principali su una classe che possono essere influenzate dai membri privati:

• Dimensioni e layout : [dei membri e funzioni virtuali - autoesplicativo e ottimo per le prestazioni, ma non per questo che siamo qui]
• Funzioni : il codice chiamante deve essere in grado di risolvere le chiamate alle funzioni membro della classe, comprese le funzioni private inaccessibili che si sovraccaricano di funzioni non private - se la funzione privata è una corrispondenza migliore, il codice chiamante non verrà compilato. (Il C ++ ha preso la deliberata decisione di progettazione per eseguire la risoluzione del sovraccarico prima del controllo dell'accessibilità per motivi di sicurezza. Ad esempio, si è ritenuto che cambiare l'accessibilità di una funzione da privato a pubblico non dovrebbe cambiare il significato del codice di chiamata legale.)

Sutter è, ovviamente, una fonte estremamente affidabile come membro del Comitato, quindi conosce "una decisione progettuale deliberata" quando ne vede una. E l'idea di richiedere una dichiarazione pubblica dei metodi privati ​​come un modo per evitare la semantica alterata o l'accessibilità accidentale rotta in seguito è probabilmente la logica più convincente. Per fortuna, dato che il tutto sembrava piuttosto inutile prima d'ora!

Ci sono due ragioni per farlo.

Innanzitutto, rendersi conto che l'identificatore di accesso è per il compilatore e non è rilevante in fase di esecuzione. L'accesso a un membro privato al di fuori dell'ambito è un errore di compilazione .

conciseness

Considera una funzione che è breve, una o due righe. Esiste per ridurre la replica del codice altrove, il che ha anche il vantaggio di poter cambiare il modo in cui un algoritmo o qualsiasi altra cosa funzioni in un posto anziché in molti (ad esempio cambiando un algoritmo di ordinamento).

Preferiresti avere una o due righe veloci nell'intestazione o avere il prototipo della funzione lì più un'implementazione da qualche parte? È più facile da trovare nell'intestazione e, per funzioni brevi, è molto più dettagliato avere un'implementazione separata.

C'è un altro grande vantaggio, che è ...

Funzioni integrate

Una funzione privata può essere inline e ciò richiede necessariamente che sia nell'intestazione. Considera questo:

class A {
  private:
    inline void myPrivateFunction() {
      ...
    }

  public:
    inline void somePublicFunction() {
      myPrivateFunction();
      ...
    }
};

È possibile che la funzione privata possa essere incorporata insieme alla funzione pubblica. Ciò viene fatto a discrezione del compilatore, poiché la inlineparola chiave è tecnicamente un suggerimento , non un requisito.

Un altro motivo per avere metodi privati ​​nel file di intestazione: ci sono casi in cui un metodo inline pubblico non fa molto di più che chiamare uno o più metodi privati. Avere i metodi privati ​​nell'intestazione significa che una chiamata al metodo pubblico può essere completamente incorporata nel codice effettivo dei metodi privati ​​e l'allineamento non si interrompe con una chiamata al metodo privato. Anche da una diversa unità di compilazione (e i metodi pubblici vengono normalmente chiamati da diverse unità di compilazione).

Naturalmente c'è anche la ragione per cui il compilatore non può rilevare problemi con la risoluzione del sovraccarico se non conosce tutti i metodi, inclusi quelli privati.

Consentire a tali funzioni di accedere ai membri privati. Altrimenti avresti comunque bisogno di friendloro nell'intestazione.

Se una qualsiasi funzione potesse accedere ai membri privati ​​della classe, allora privato sarebbe inutile.