Visualizzazione dei risultati da 1 a 10 su 10
  1. #1

    [C++]A proposito delle classi

    Sto studiando un capitolo intitolato: dettagli sintattici e implementativi sulle classi...e non ho capito una cosa..:

    C'è scritto:
    "Allo scopo di inibire all'utente l'uso dello scambio per valore e dell'enunciato di assegnazione, occorre ricorrere all'artificio di definire il costruttore di copia e l'operatore di assegnazione come privati e associare a essi un corpo vuoto(in questo caso, infatti, le operazioni di default non vengono applicate perchè ridefinite dal progettista e quelle ridefinite non sono accessibili all'utente perchè private:il compilatore in questa circostanza da un'indicazione di errore)."
    quindi scriverò:

    Codice PHP:
    class C{
    ...........
    private: 
    C(const C& ) {} //definisce operatore di copia privato
    Coperator=(const C& ) {} //operatore di assegnazione privato 

    Non ho capito perchè c'è bisgno di inibire l'uso dello scambio per valore, e cosa fa la seconda istruzione...cioè come funziona l'operator?
    L'impossibile richiede solo più tempo...

  2. #2

    Re: [C++]A proposito delle classi

    Originariamente inviato da minidiable
    Non ho capito perchè c'è bisgno di inibire l'uso dello scambio per valore,
    Perché lo dice l'esercizio, e perché in alcune occasioni può essere utile.
    e cosa fa la seconda istruzione...cioè come funziona l'operator?
    Il secondo metodo (operator=) dichiara il nuovo operatore di assegnamento (appunto, l'operatore =); poiché però esso è dichiarato come privato, il codice che si trova all'esterno della classe non lo potrà utilizzare, e di conseguenza non potrà assegnare un'istanza di C ad un'altra.
    Amaro C++, il gusto pieno dell'undefined behavior.

  3. #3
    Ma quello di cui ti sto parlando non è un esercizio e poi il problema è che questo fatto di inibire lo scambio per valore lo dice spesso, come se fosse una cosa che solitamente si fa...io non ho capito perchè....tu mi hai scritto che a volte è utile...ma perchè???

    Grazie!!!
    L'impossibile richiede solo più tempo...

  4. #4
    Utente di HTML.it L'avatar di shodan
    Registrato dal
    Jun 2001
    Messaggi
    2,381
    Per evitare qualcosa del genere:
    codice:
    class Test {
       public:
          Test() : ptr(new char[16]) {}
          ~Test() { delete [] ptr; }
       private:
          char* ptr;
    
    };
    
    int main (void) {
    
       /* riduce lo scope */ {
          Test t;
          Test t1 = t;
          Test t2;
          t2 = t;
       }
       // errore di accesso.
    }
    Il puntatore è cancellato tre volte di cui solo la prima è valida.
    Ci sono altri motivi per inibire la copia e/o l'assegnazione, ma questo è il principale.
    This code and information is provided "as is" without warranty of any kind, either expressed
    or implied, including but not limited to the implied warranties of merchantability and/or
    fitness for a particular purpose.

  5. #5
    Scusami...ma non ho capito molto del codice che hai scritto...se lo commentassi te ne sarei davvero grato....
    Grazie per la pazienza che avete....e scusami per il disturbo!!!
    L'impossibile richiede solo più tempo...

  6. #6
    Supponi che la tua classe allochi della memoria assegnandola ad un puntatore (suo membro privato) e la deallochi nel distruttore; ora, l'operatore di assegnamento e il costruttore di copia di default copiano bit-a-bit il valore dei campi della classe, per cui, nell'esempio, t, t1 e t2 avranno il membro ptr che punterà alla stessa memoria. Quando poi i tre oggetti verranno distrutti, tutti e tre tenteranno di deallocare la stessa memoria, per cui (dalla seconda distruzione in poi) verranno generati degli errori.
    L'alternativa a questo approccio è scrivere un costruttore di copia che si occupi di allocare nuova memoria per la nuova copia della classe e copiarci dentro il contenuto della memoria posseduta dall'istanza da cui si sta copiando, e agire in maniera simile per l'operatore di assegnamento. Tuttavia più spesso si sceglie il primo approccio, perché si presume che le istanze della classe non verranno mai copiate o perché per qualunque altro motivo (che può essere di prestazioni) si vuole imporre che la classe non possa essere copiata o assegnata; in questo modo qualora il programmatore tentasse di copiare o assegnare un'istanza della classe il compilatore glielo impedirebbe.
    Amaro C++, il gusto pieno dell'undefined behavior.

  7. #7
    Originariamente inviato da MItaly
    Tuttavia più spesso si sceglie il primo approccio...
    Come primo approccio intendi quello di inibire l'uso dello scambio per valore e dell'operatore di assegnazione???
    L'impossibile richiede solo più tempo...

  8. #8
    Sì.
    Amaro C++, il gusto pieno dell'undefined behavior.

  9. #9
    Ti ringrazio ho capito tutto!!!
    L'impossibile richiede solo più tempo...

  10. #10
    Amaro C++, il gusto pieno dell'undefined behavior.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.