[C++] Da puntatore a reference.

[Opcode]

Giorno,
stò pianificando dei metodi per restituire una reference degli oggetti della classe, invece di restituirne i puntatori per maggiore sicurezza ed evitare che possano essere cancellati, ho quindi un metodo tipo questo:

Object &Classe::object()
{
    return *_object; // oggetto privato
}

Mi chiedevo, quello che restituisco è effettivamente una reference a _object oppure ne restituisco una copia?

_object ho dovuto dichiararlo come puntatore perchè la sua inizializzazione avviene in un metodo chiamato "init" e non nel costruttore di Classe.
Se volessi dichiarare in Classe:

Classe {
public:
// ...
Object object;
};

Come potrei fare per catturare eventualmente le eccezioni del costruttore di Object?
object in quest'ultimo caso dovrebbe essere inizializzato nel costruttore di Classe giusto?
Se cosi fosse mi basterebbe dichiarare un blocco try catch nel costruttore e gestire l'eventuale eccezione... ma come?

Aspetto vostre notizie
Grazie in anticipo.

[Wing_Zero]

Allora innanzitutto l'oggetto "object" devi dichiararlo come variabile di classe, all'interno dell'header della classe e non crearlo all'interno del costruttore.
Altrimenti avresti uno scope locale al costruttore e non puoi restituirlo.

Poi quando lo restituisci: return *object, (se hai creato un puntatore ad object e "object" è l'indirizzo), altrimenti return object (se object è l'oggetto stesso).

nel caso vuoi instanziare l'oggetto all'interno del metodo stesso, devi scrivere
Object &Classe::object()
{
Object* object = new object();
return object;
}

in questo caso passi il riferimento e non la copia dell'oggetto, ma avendolo creato tramile la "new", l'oggetto viene allocato nello heap e non muore mai. neanche se distruggi il parent. Ti dovrai quindi ricordare di distruggerlo (" delete(object)" ) in seguito.

Cmq datti una letta a qualche libro per iniziare il C++...non ti puo' fare che bene.

[Opcode]

Temo tu mi abbia frainteso.
Si object è un membro della classe, privato.
Nella dichiarazione della classe lo definisco come puntatore perchè la vera inizializzazione tramite new avviene non nel costruttore di Classe ma in un metodo chiamato "init".
Quello deve quindi essere il primo metodo, cosi crea l'oggetto nello heap e assegna al puntatore il suo indirizzo.
Ho però bisogno di restituire una reference, non una copia (non c'e n'è necessità) nè un puntatore, che potrebbe essere cancellato.

Il mio dubbio sorgeva dal fatto che sino ad oggi tutti gli esempi di funzioni che restituiscono una reference sono cosi strutturate:

Object &Class::Reference()
{
    Object &ref = *_object; // object è un membro della classe
    return ref;
}

Mentre io per semplificare il tutto, e non trovando una necessità di rifare tutto faccio più semplicemente:

Object &Class::Reference()
{
    return *_object;
}

Ovviamente il compilatore non mi dà ne warning, ne errori. Però il mio dubbio era che in realtà non facendo quel passaggio di creare io stesso un puntatore reference, fosse restituita una copia di _object, e il compilatore non segnala alcun errore pur non essendo una reale reference, tutto qui.
La seconda domanda invece era:
Se nella dichiarazione (non definizione) della classe anzichè mettere:

Object *_object;

Da inizializzare poi nel metodo "init" mettessi più semplicemente

Object _object;

In che modo posso catturare eventualmente una eccezione sollevata dal costruttore della classe Object?
IMHO è da fare nel costruttore della classe che dichiara l'oggetto _object, ma non essendo io a inizializzare l'oggetto ho qualche perplessità su come catturare quell'eccezione.

Se non sono stato chiaro, faccio un piccolo esempio.
Grazie per la risposta.

[cionci]

Originariamente inviato da Wing_Zero

Object &Classe::object()
{
Object* object = new object();
return object;
}

E chi lo dealloca object ???
Questo è un memory leak

Originariamente inviato da Opcode

Object &Class::Reference()
{
    Object &ref = *_object; // object è un membro della classe
    return ref;
}

Mentre io per semplificare il tutto, e non trovando una necessità di rifare tutto faccio più semplicemente:

Object &Class::Reference()
{
    return *_object;
}

Sono equivalenti

Originariamente inviato da Opcode

Come potrei fare per catturare eventualmente le eccezioni del costruttore di Object?
object in quest'ultimo caso dovrebbe essere inizializzato nel costruttore di Classe giusto?
Se cosi fosse mi basterebbe dichiarare un blocco try catch nel costruttore e gestire l'eventuale eccezione... ma come?

Spiega un po' meglio questo punto...

[Albi89]

Il codice che hai utilizzato va benissimo, e non ritorna una copia, non ti preoccupare

Per la seconda domanda, hai bisogno di un "function try block", cioè di associare il try non ad un blocco ma all'intera funzione:

MyClass::MyClass()
try : object() {
    //Corpo del costruttore
}
catch (myObjectException &e){
    //Gestione dell'eccezione
}

[Opcode]

Originariamente inviato da cionci

Sono equivalenti

Ooottimo Era quello che mi serviva sapere, ho cercato più volte ma, probabilmente a scopo didattico, il risultato era simile in tutti i casi.

Spiega un po' meglio questo punto...

Allora, supponiamo che io ho la seguente classe:

class Window {
public:
    Window() { throw 1; } // supponiamo una eccezione
};

class Handler {
public:
    Handler() {};
    Window window; // (1) -- alla costruzione lancerà un'eccezione
};

(1) Come catturo l'eccezione sollevata dal costruttore di Window?

Se avessi un puntatore, farei tipo:

// Window *window; // dichiarato precedentemente
Handler::Handler() {
    try {
        window = new Window;
    }
    catch (Exception &ex) {
        // gestisci
    }
}

Ma in quel caso l'oggetto viene creato automaticamente dal costruttore di Handler quindi come faccio a cattuare l'eccezione di Window::Window?

Originariamente inviato da Albi89

Il codice che hai utilizzato va benissimo, e non ritorna una copia, non ti preoccupare

ottimo.

Per la seconda domanda, hai bisogno di un "function try block", cioè di associare il try non ad un blocco ma all'intera funzione:

MyClass::MyClass()
try : object() {
    //Corpo del costruttore
}
catch (myObjectException &e){
    //Gestione dell'eccezione
}

Eccolo qui, benissimo, ero indeciso se questo metodo avrebbe funzionato o meno, e comunque preferisco sempre avere un feedback per non fare qualche cacchiata.

Se io non inizializzo esplicitamente object() ? Funzionerà ugualmente?
Grazie mille per la risposta

[Albi89]

Originariamente inviato da Opcode

Se io non inizializzo esplicitamente object() ? Funzionerà ugualmente?
Grazie mille per la risposta

Onestamente penso di sì ma non ci giurerei... meriterebbe una prova ma in questo momento confesso di aver bootato in Windows per giocare a Dragon Age e non ho nulla installato per provare

"A rigore" dovrebbe funzionare, nell'indecisione comunque aggiungere la chiamata al costruttore non costa molto e rende più chiaro "da chi" ti aspetti un'eccezione.

Un problema più interessante è che, quando si associa un "function try block" ad un costruttore, al termine del blocco catch, se questi non ha propagato l'eccezione ricevuta (o non ne ha lanciata una nuova), l'eccezione originaria è comunque propagata: in soldoni, quando fallisce il costruttore di una sottoparte, deve fallire il costruttore dell'intero oggetto -quindi ricordati di avere un blocco try associato alla costruzione di MyClass, e possibilmente lancia una eccezione "ad hoc" nel blocco catch!-.

Una questione simile dovrebbe valere anche per i distruttori, anche se ha implicazioni meno significative (una eccezione in un distruttore dovrebbe sempre terminare il programma, e in generale il codice di un distruttore è meno propenso a fallire).

[Wing_Zero]

Originariamente inviato da cionci

E chi lo dealloca object ???
Questo è un memory leak

Sono equivalenti

Spiega un po' meglio questo punto...

come chi lo dealloca?
passi il rifermimento all'oggetto,e poi delete(object)

[Opcode]

Confermo che funziona
Comunque si, per maggiore chiarezza lo inizializzerò esplicitamente.

Originariamente inviato da Albi89

Un problema più interessante è che, quando si associa un "function try block" ad un costruttore, al termine del blocco catch, se questi non ha propagato l'eccezione ricevuta (o non ne ha lanciata una nuova), l'eccezione originaria è comunque propagata: in soldoni, quando fallisce il costruttore di una sottoparte, deve fallire il costruttore dell'intero oggetto -quindi ricordati di avere un blocco try associato alla costruzione di MyClass, e possibilmente lancia una eccezione "ad hoc" nel blocco catch!-.

Hai fatto benissimo a dirmelo, non ne ero a conoscenza.
Sapevo invece che se c'è un problema nel costruttore e hai allocato qualche risorsa, l'eccezione non chiama il distruttore perchè l'oggetto non è stato creato, e quindi ci vuole attenzione.

Riguardo a questo problema, ti giro una nuova domanda:
e se MyClass fosse un singleton?

La classe viene inizializzata staticamente, come potrebbe gesitre il throw del proprio costruttore?

Una questione simile dovrebbe valere anche per i distruttori, anche se ha implicazioni meno significative (una eccezione in un distruttore dovrebbe sempre terminare il programma, e in generale il codice di un distruttore è meno propenso a fallire).

Uhm, farò qualche test anche sui distruttori, per vedere un po' che succede nei casi peggiori.

Grazie.

[tomminno]

Originariamente inviato da Wing_Zero

come chi lo dealloca?
passi il rifermimento all'oggetto,e poi delete(object)

Per me è da pazzi pensare di deallocare un riferimento (comunque eventualmente delete &object; ). Scusa la franchezza.
Anche perchè poi tutti gli eventuali riferimenti avrebbero un comportamento indefinito, il crash del programma è assicurato.
Infine chi ti dice che l'oggetto a cui punta il riferimento è stato allocato con una new?

[Albi89]

Originariamente inviato da Wing_Zero

come chi lo dealloca?
passi il rifermimento all'oggetto,e poi delete(object)

Allocazione è deallocazione vanno SEMPRE svolte allo stesso livello di "astrazione": allocare all'interno di una classe e lasciare la responsabilità della deallocazione all'utente è una pratica da evitare assolutamente; al massimo si può ritornare un oggetto gestore che deallochi il riferimento quando out of scope.

[fero86]

Originariamente inviato da tomminno

Infine chi ti dice che l'oggetto a cui punta il riferimento è stato allocato con una new?

chi ti dice che lo sia quello gestito tramite puntatore?

[Albi89]

Originariamente inviato da Opcode

Riguardo a questo problema, ti giro una nuova domanda:
e se MyClass fosse un singleton?

A livello tecnico non dovrebbe cambiare niente; posto Instance() il metodo mediante il quale richiedi l'istanza e _instance l'istanza membro, dovresti probabilmente fare qualcosa di simile:

MySingleton* MySingleton::Instance() {
    if (_instance == 0) {
        try {
            _instance = new MySingleton();
        }
        catch (mySingletonConstructionException) {
            //...
            throw;
        }
    }
    return _instance;
}

Cioè un approccio tradizionale (senza function try block), ma avendo cautela di far comportare la clausola catch come quella associata a un costruttore (cioè propagando l'eccezione: d'altra parte quella parte del metodo Instance() è deputata alla costruzione è in caso di fallimento non ha mai senso ritornare il puntatore all'istanza).

Ovviamente, il costruttore MySingleton::MySingleton() può avere o non avere un function try block associato: lo avrà se inizializza altri oggetti (cioè se eredita da altre classi o se inizializza membri con una sintassi constructor initializer, ossia i fatidici ":"), altrimenti conterrà semplicemente uno statement try.

[tomminno]

Originariamente inviato da fero86

chi ti dice che lo sia quello gestito tramite puntatore?

Infatti utilizzi il riferimento e non hai più dubbi su chi deve gestire la vita dell'oggetto.

[Wing_Zero]

Originariamente inviato da tomminno

Per me è da pazzi pensare di deallocare un riferimento (comunque eventualmente delete &object; ). Scusa la franchezza.
Anche perchè poi tutti gli eventuali riferimenti avrebbero un comportamento indefinito, il crash del programma è assicurato.
Infine chi ti dice che l'oggetto a cui punta il riferimento è stato allocato con una new?

Deallocando un riferenmento (Comunque delete object e non &object, in quanto avevo specificato che object era l'indirizzo e *object l'oggetto) devi sape a priori che è stato allocato con una new. altrimenti non avrebbe senso deallocarlo tamire un riferimento se la variabile fosse temporanea nello stack e non nell'heap. mi pare ovvio.

Originariamente inviato da Albi89

Allocazione è deallocazione vanno SEMPRE svolte allo stesso livello di "astrazione": allocare all'interno di una classe e lasciare la responsabilità della deallocazione all'utente è una pratica da evitare assolutamente; al massimo si può ritornare un oggetto gestore che deallochi il riferimento quando out of scope.

Concordo che non è la pratica migliore in assoluto, ma a volte non si puo' evitare.

[cionci]

Originariamente inviato da Wing_Zero

Deallocando un riferenmento (Comunque delete object e non &object, in quanto avevo specificato che object era l'indirizzo e *object l'oggetto) devi sape a priori che è stato allocato con una new. altrimenti non avrebbe senso deallocarlo tamire un riferimento se la variabile fosse temporanea nello stack e non nell'heap. mi pare ovvio.

object è un puntatore ? Quindi addirittura torno un puntatore allocato con malloc ritornato per riferimento ?
A questo punto le domande sono tre:
- chi dealloca il puntatore
- chi dealloca la memoria puntata dal puntatore
- che tipo di deallocazione va fatta ? una delete o una delete[] sui dati ? Chi ti garantisce che la venga fatta quella giusta ?

Originariamente inviato da Wing_Zero

Concordo che non è la pratica migliore in assoluto, ma a volte non si puo' evitare.

Imho va semplicemente evitata. Se si è costretti ad usarla significa che bisogna fare un refactoring del nostro codice.

[Opcode]

Quindi il controllo delle eccezioni mi forza ad usare un puntatore come singleton, cioè se io volessi fare qualcosa come:

Class MySingleton {
private:
    static MySingleton _instance;
    MySingleton() {};
    MySingleton(const MySingleton&); //disabilito il copy constructor
public:
    static MySingleton &instance() { return _instance; }
};
// inizializzo il singleton
MySingleton MySingleton::_instance; // (1)

Mi chiedevo se fosse quindi possibile intercettare l'eccezione nel punto (1) essendo in ambito globale. Ovviamente qualora non fosse possibile procederei come hai descritto tu, ma sempre restituendo una reference per evitare il delete.

Originariamente inviato da Albi89

Cioè un approccio tradizionale (senza function try block), ma avendo cautela di far comportare la clausola catch come quella associata a un costruttore (cioè propagando l'eccezione: d'altra parte quella parte del metodo Instance() è deputata alla costruzione è in caso di fallimento non ha mai senso ritornare il puntatore all'istanza).

Beh se fallisce la creazione del singleton non sarebbe opportuno terminare l'esecuzione del programma con uno status di errore? Sempre supponendo che il singleton non venga creato attraverso un'altro oggetto, altrimenti si potrebbe sollevare l'eccezione e riprovare a crearlo.

EDIT: ora che ci ripenso forse una soluzione c'è. Se non erro in mancanza di un handler per l'eccezione viene chiamato terminate() dalla <exception>, quindi se io gestissi in quel punto l'eccezione eventualmente generata, dovrebbe funzionare quanto meno per evitare un crash perchè non ho gestito l'eccezione, non credi? Io intanto faccio qualche test
Scherzavo, non posso cattuare l'eccezione

[marco.r]

Originariamente inviato da Wing_Zero

come chi lo dealloca?
passi il rifermimento all'oggetto,e poi delete(object)

Pessima idea. Quando un oggetto viene ritornato per riferimento l'assunzione implicita e' che chi te la fornito ne mantiene comunque la patria potesta'.
Un po' come un bambino che ti presta il pallone per giocarci a calcio assieme. Pui fare quello che vuoi, ma non puoi portartelo via, e quando se ne va l'altro, il pallone sparisce assieme a lui.
Per motivi analoghi non dovresti prenderne il puntatore e salvarlo da altre parti, salvo rare eccezioni.

(Discorso analogo si potrebbe fare per gli argomenti passati per riferimento, che in generale non si puo' pensare abbiano vita maggiore della chiamata stessa )

[marco.r]

Originariamente inviato da Albi89

Allocazione è deallocazione vanno SEMPRE svolte allo stesso livello di "astrazione": allocare all'interno di una classe e lasciare la
responsabilità della deallocazione all'utente è una pratica da evitare assolutamente;

Direi piuttosto che e' importante che sia chiaro chi e' il proprietario dell'oggetto ritornato.

[marco.r]

Originariamente inviato da Albi89

Un problema più interessante è che, quando si associa un "function try block" ad un costruttore, al termine del blocco catch, se questi non ha propagato l'eccezione ricevuta (o non ne ha lanciata una nuova), l'eccezione originaria è comunque propagata: in soldoni, quando fallisce il costruttore di una sottoparte, deve fallire il costruttore dell'intero oggetto -quindi ricordati di avere un blocco try associato alla costruzione di MyClass, e possibilmente lancia una eccezione "ad hoc" nel blocco catch!-.

Starei attento a lanciare eccezioni nei costruttori. Il primo problema e' che devi fare pulizia di quanto hai gia' inizializzato. Il secondo, ben piu' importante, e' che devi farlo in ogni oggetto che usi una istanza di questa classe come attributo.
Ci si puo' stare attenti ma e' un sacco di lavoro

Una questione simile dovrebbe valere anche per i distruttori, anche se ha implicazioni meno significative (una eccezione in un distruttore dovrebbe sempre terminare il programma, e in generale il codice di un distruttore è meno propenso a fallire).

Un'eccezione in un distruttore e' una ricetta sicura per il disastro, visto che ti puoi trovare in situazioni in cui viene lanciata un'eccezione durante lo stack unwinding.
Direi meglio evitare.
(e se invece l'oggetto era garbage collected che senso ha ?)