[C++] Da puntatore a reference.

[fero86]

Originariamente inviato da marco.r

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

sempre di chiacchiere da corridoio si tratta: cos'é in C++ un "proprietario"? e cos'é un "livello di astrazione"?

dovendo per forza palinfrascare agilmente io avrei preferito la definizione di Albi89

[fero86]

Originariamente inviato da marco.r

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

veramente no, anzi, avviene tutto in automatico: se la costruzione di un oggetto fallisce con un'eccezione C++ (non SEH) vengono distrutti tutti e soli i sotto-oggetti* costruiti fino a quel momento e vengono distrutti in ordine inverso rispetto alla creazione. sempre che il compilatore sia compliant naturalmente.

*per sotto-oggetti intendo i campi di tipo classe.

EDIT - anzi: se devo rappresentare in un programma una risorsa la cui creazione o acquisizione puó fallire, io preferisco sempre lanciare eccezioni dal costruttore, altrimenti il programma diventa piu complesso perché per quella classe devo prevedere due possibili stati: "creato ma non inizializzato" e "creato e inizializzato". i controlli "assert" a quel punto fioriscono.

EDIT2 - anzi, tre stati: "creato ma non inizializzato", "creato e inizializzato con successo" e "creato ma inizializzazione fallita".

[fero86]

Originariamente inviato da marco.r

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.

qualche ulteriore dettaglio?

[marco.r]

Originariamente inviato da fero86

qualche ulteriore dettaglio?

Devi gestire contemporaneamente due eccezione e il programma qualsiasi scelga perde informazioni.
Esempio:

#include <iostream>

struct Bar{};

struct Foo
{
    ~Foo(){ throw Bar(); }
};

void g()
{
    throw 42;
}

void f()
{
    try
    {
        Foo f;
        g();
    }
    catch( int )
    {
        std::cout << "Got int" << std::endl;
    }
}


int main()
{
    try
    {
        f();
    }
    catch( const Bar& b )
    {
        std::cout << "Got Bar" << std::endl;
    }
}

Quando g() lancia l'eccezione, lo stack viene svolto, ad un certo punto pero' deve distruggere Foo che lancia a sua volta un'eccezione. Se gestisci una delle due poi non hai piu' il contesto per gestire l'altra, e infatti il programma finisce con un terminate()

[marco.r]

Originariamente inviato da fero86

sempre di chiacchiere da corridoio si tratta: cos'é in C++ un "proprietario"?

Nel mio contesto, un altro oggetto che ha la responsabilita' di deallocare l'istanza in questione, ne piu' ne meno.

[fero86]

Originariamente inviato da marco.r

Esempio: [...]

vero, sono d'accordo che lanciare eccezioni dai distruttori sia del tutto da evitare visto che i distruttori vengono invocati anche in caso di stack unwinding provocato da un'eccezione, infatti chiedevo chiarimenti perché avevo letto male questo post:

Originariamente inviato da marco.r

Un'eccezione in un distruttore e' una ricetta sicura per il disastro, [...]

avevo letto "costruttore" anziché "distruttore".

Originariamente inviato da marco.r

Nel mio contesto, un altro oggetto che ha la responsabilita' di deallocare l'istanza in questione, ne piu' ne meno.

non é detto che un oggetto sia allocato sotto forma di variabile membro di un'altra classe e non é detto neanche che esso sia stato allocato dinamicamente dal codice di una funzione membro.

parlando a livello intuitivo non é detto che il "proprietario" di un oggetto sia un altro oggetto. il concetto di livello di astrazione mi piaceva di piu

[Wing_Zero]

Originariamente inviato da cionci

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 ?

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

chi dealloca l'oggetto?
il chiamante quando sa che non gli serve più.

Chi dealloca il puntatore?
Scusa, ma come si dealloca un puntatore? al massimo lo metti =0.

esempio pratico: factory che crea una instanza di un oggetto di tipo di un interfaccia generico. Voglio vedere come fai a far distruggere l'oggetto in questo caso alla classe stessa -.-".

[tomminno]

Originariamente inviato da Wing_Zero

chi dealloca l'oggetto?
il chiamante quando sa che non gli serve più.

Questo è un ragionamento proprio del C.
Chi ti dice che il chiamato non utilizzi quello stesso oggetto per i fatti suoi? Che non abbia passato quello stesso oggetto ad altri chiamanti?
Uno dei principi base della programmazione ad oggetti è l'incapsulamento, io chiamante non devo conoscere il funzionamento interno del chiamato. Secondo il tuo ragionamento invece il chiamante deve conoscere il comportamento interno del chiamato. In caso di modifiche interne a quest'ultimo, sei obbligato a rivedere anche il primo.

esempio pratico: factory che crea una instanza di un oggetto di tipo di un interfaccia generico. Voglio vedere come fai a far distruggere l'oggetto in questo caso alla classe stessa -.-".

Per questo esiste da sempre una classe chiamata auto_ptr (ora deprecata in favore di shared_ptr). Con auto_ptr espliciti che il controllo sull'esistenza dell'oggetto passa al chiamante.
Chi ti dice che il Factory non sia di tipo "singleton" ovvero che ritorna sempre la stessa istanza a parità di parametri in ingresso? Se il tuo chiamante ne facesse la delete ti ritroveresti sicuramente nei guai.

[MenageZero]

scusandomi per l'intromissione ...

Originariamente inviato da tomminno

Questo è un ragionamento proprio del C.
Chi ti dice che il chiamato non utilizzi quello stesso oggetto per i fatti suoi? Che non abbia passato quello stesso oggetto ad altri chiamanti?
Uno dei principi base della programmazione ad oggetti è l'incapsulamento, io chiamante non devo conoscere il funzionamento interno del chiamato. Secondo il tuo ragionamento invece il chiamante deve conoscere il comportamento interno del chiamato. In caso di modifiche interne a quest'ultimo, sei obbligato a rivedere anche il primo.

non vedo la necessità di porre obiezioni tanto "in grande":
per esempio, quando ritorni un tipo per valore non è forse la dichiarazione stessa del metodo che ti dice che ogni volta avrai una nuova istanza ?

allo stesso modo, in una situazione in cui può avere senso, come appunto factory in cui per il tipo prodotto è usata a modo di interfaccia una classe astratta, parte della definizione(semantica) formale come api di un metodo può benissimo essere che ti restituisce un puntatore ad una nuova istanza o invece sempre alla stessa, e la cosa essere tranquillamente parte della documentazione di progetto; da qui ce ne passa dal dire che il chiamante sia fortemente dipendente dall'implementazione del chiamato.

andiamo, ci sono api anche molto blasonate con le quali c'è una lista di cose che devi sapere (e quando la documentaziome delle medesime include la lista completa già va di lusso ) quando passi loro un puntatore o te ne ritornano uno, per evitare potenziali "effetti collaterali" ...

non voglio sostenere che non sia opportuno o sia indifferente distruggere un oggetto sullo heap con uno statement parte della stessa classe che lo ha creato, per carità, ma non sempre è possibile applicare tale "regola"

tantomeno mi voglio addentrare su cosa sia più "elegante" o meno etc, ma francamente più passa il tempo meno mi convince che per ogni cosa esista la regoletta universale che va sempre bene e che se "sgarri" allora devi buttare via tutto

Originariamente inviato da tomminno

Per questo esiste da sempre una classe chiamata auto_ptr (ora deprecata in favore di shared_ptr). Con auto_ptr espliciti che il controllo sull'esistenza dell'oggetto passa al chiamante.
Chi ti dice che il Factory non sia di tipo "singleton" ovvero che ritorna sempre la stessa istanza a parità di parametri in ingresso? Se il tuo chiamante ne facesse la delete ti ritroveresti sicuramente nei guai.

in un esempio come quello discusso aggiungere l'uso di auto_prt o chi per esso
può sicuramente essere un'ottima idea, ma personalmente lo vedo più come un miglioramento di dettaglio rispetto ai concetti discussi:

già solo il fatto che la factory ti ritorni (per valore ovviamente) un oggetto auto_ptr ti dice che creerà una nuova istanza ogni volta, un miglioramento perché è la definizione stessa del metodo che ti esclude l'opzione singleton rispetto al ritornare un puntatore, ma non è certo un ipotetico livello di astrazione in più che ti permette id avere indifferentemente la factory normale oppure singleton senza modificare né la definizioen del metodo né il chiamante;

poi cmq l'oggetto sullo heap verrebbe distrutto quando l'oggetto di tipo auto_ptr va fuori scope, quindi nel chiamante e cmq non nel codice classe che lo ha creato, la nostra "regola aurea" potrebbe in fondo ancora lagnarsene formalmente, metti che per caso la situazione lato factory fosse molto complessa ed il codice che crea effettivamente l'istanza non sa che poi verrà passata esternamente trmite un wrapper del puntatore che "takes ownership" dell'istanza ...se ci vogliamo arrovellare concettualmente non cambuia molto rispetto alla questione iniziale

inoltre, tanto per rimanere in tema di factory e "regole assolute" e signleton o meno, trovi pure tanti che predicano animatamente contro il singleton pattern,
qundi in questo esempio ci sarebbe pure un'ulteriore "regola assoluta" che andrebbe a risolvere la diatriba "a monte" anche se il metodo in questione ritornasse solo un normale puntatore

ps: se il l'applicazione del concetto di definizione di un tipo come interfaccia ed il pattern della factory sono in voga ormai da molti anni, consolidati e che io sappia tuttora molto usati e con "reputazione" positiva, ed allo stesso tempo il c++ non implementa esplicitamente il concetto di interfaccia, in fondo non è certo colpa degli utilizzatori del c++

pps: una precisazione, devo scappare di fretta e non ho tempo di correggere bene la forma del post, temo di aver unsato una o più volte la parola "definizione" al posto di "dichiarazione" relativamente ad un metodo (spesso "definizione" è usato come sinonimo di implementazione del metodo)

[tomminno]

Originariamente inviato da MenageZero

non vedo la necessità di porre obiezioni tanto "in grande":
per esempio, quando ritorni un tipo per valore non è forse la dichiarazione stessa del metodo che ti dice che ogni volta avrai una nuova istanza ?

Ma la discussione era partita dal suggerimento di istanziare in un metodo un oggetto nell'heap e di ritornarne un riferimento che poi sarà deallocato dal chiamante.

andiamo, ci sono api anche molto blasonate con le quali c'è una lista di cose che devi sapere (e quando la documentaziome delle medesime include la lista completa già va di lusso ) quando passi loro un puntatore o te ne ritornano uno, per evitare potenziali "effetti collaterali" ...

Tipo? Io conosco solo le Xerces che essendo un ibrido C/C++ ti ritornano puntatori che il più delle volte devi deallocarti.
Ma certamente non esiste una sola API che ti ritorna un riferimento e nella documentazione ti dice che quell'oggetto te lo devi deallocare.

non voglio sostenere che non sia opportuno o sia indifferente distruggere un oggetto sullo heap con uno statement parte della stessa classe che lo ha creato, per carità, ma non sempre è possibile applicare tale "regola"

Se non puoi ci sono nel linguaggio le alternative per indicare tale circostanza, quindi perchè non usarle?
Se non viene fatto il più delle volte è perchè trovi una strutturazione molto alla C.

tantomeno mi voglio addentrare su cosa sia più "elegante" o meno etc, ma francamente più passa il tempo meno mi convince che per ogni cosa esista la regoletta universale che va sempre bene e che se "sgarri" allora devi buttare via tutto

Sai un programma lo puoi sempre scrivere tutto nel main oppure strutturare ad oggetti applicando tutti i pattern di questo mondo. Il programma può funzionare benissimo in entrambi i casi.
Per questo si parla di best practices.

poi cmq l'oggetto sullo heap verrebbe distrutto quando l'oggetto di tipo auto_ptr va fuori scope, quindi nel chiamante e cmq non nel codice classe che lo ha creato, la nostra "regola aurea" potrebbe in fondo ancora lagnarsene formalmente,

E questo che c'entra? Anche un oggetto ritornato per valore viene deallocato quando va fuori dallo scope nel chiamante e allora?

metti che per caso la situazione lato factory fosse molto complessa ed il codice che crea effettivamente l'istanza non sa che poi verrà passata esternamente trmite un wrapper del puntatore che "takes ownership" dell'istanza ...se ci vogliamo arrovellare concettualmente non cambuia molto rispetto alla questione iniziale

Infatti esiste da quel dì una classe chiamata shared_ptr, devi tornare un puntatore e non sai come viene usato? Torna uno shared_ptr e vedrai che risolverai molti dei tuoi problemi. Non a caso auto_ptr è deprecato.

inoltre, tanto per rimanere in tema di factory e "regole assolute" e signleton o meno, trovi pure tanti che predicano animatamente contro il singleton pattern,

Direi che questo c'entra poco con il discorso.
E' vero che tanti dicono male del singleton, ma in un programma ci sono delle variabili effettivamente globali, tipo le configurazioni.
Oppure pensa solo all'MVC se dei controller devono condividere lo stesso Model a chi chiederanno l'istanza del Model? Se non lo fai con un factory "singleton" io non ho molte altre alternative, se non quella che gli venga passato dal chiamante, ma non necessariamente il chiamante è in un contesto tale da avere un riferimento al Model richiesto.
Qualcuno ha altre alternative?

qundi in questo esempio ci sarebbe pure un'ulteriore "regola assoluta" che andrebbe a risolvere la diatriba "a monte" anche se il metodo in questione ritornasse solo un normale puntatore

Sei te che l'hai presa come "regola assoluta", qui stiamo parlando di "best practice".
Sennò perchè non consigliare di scrivere tutto nel main così ci si evitano direttamente chiamate a funzioni o metodi con tutti gli eventuali problemi della gestione del ritorno?

ps: se il l'applicazione del concetto di definizione di un tipo come interfaccia ed il pattern della factory sono in voga ormai da molti anni, consolidati e che io sappia tuttora molto usati e con "reputazione" positiva, ed allo stesso tempo il c++ non implementa esplicitamente il concetto di interfaccia, in fondo non è certo colpa degli utilizzatori del c++

E questo che c'entra? Non ci sono certo problemi nell'implementare interfacce in C++, nè tanto meno factory.

[marco.r]

Originariamente inviato da fero86

veramente no, anzi, avviene tutto in automatico: se la costruzione di un oggetto fallisce con un'eccezione C++ (non SEH) vengono distrutti tutti e soli i sotto-oggetti* costruiti fino a quel momento e vengono distrutti in ordine inverso rispetto alla creazione. sempre che il compilatore sia compliant naturalmente.

Hai ragione, mi sono sbagliato.

EDIT - anzi: se devo rappresentare in un programma una risorsa la cui creazione o acquisizione puó fallire, io preferisco sempre lanciare eccezioni dal costruttore, altrimenti il programma diventa piu complesso perché per quella classe devo prevedere due possibili stati: "creato ma non inizializzato" e "creato e inizializzato". i controlli "assert" a quel punto fioriscono.

EDIT2 - anzi, tre stati: "creato ma non inizializzato", "creato e inizializzato con successo" e "creato ma inizializzazione fallita".

[/quote]
Una alternativa e' forzare l'uso di una factory, con costruttori privati e friend factory. In quel modo puoi inizializzare come vuoi ed evitare qualsiasi stato invalido (ed avere dei costruttori "virtuali")

[marco.r]

Originariamente inviato da fero86

parlando a livello intuitivo non é detto che il "proprietario" di un oggetto sia un altro oggetto. il concetto di livello di astrazione mi piaceva di piu

L'oggetto da qualche parte deve stare, che sia lo stack delle chiamate, una variabile globale o un qualsiasi struttura dati. Se il puntatore all'oggetto e' presente in piu' parti bisogna decidere dove/da chi deve venire deallocato (o ricorrere a oggetti tipo shared_ptr), Il senso del mio intervento era questo, niente di piu'.

[MenageZero]

Originariamente inviato da tomminno

Ma la discussione era partita dal suggerimento di istanziare in un metodo un oggetto nell'heap e di ritornarne un riferimento che poi sarà deallocato dal chiamante.

che è quello che devi fare "per forza" se vuoi usare una classe astratta come interfaccia per il prodotto di una factory. poi puoi chiaramente esplicitare la
situazione ed automatizzare la distruzione usando qualcosa come auto_ptr o shared_ptr, come hai giustamente ricordato e mi pare di aver convenuto con te sull'opportunità di farlo;

rimane il fatto che l'oggetto sullo heap non verrà distrutto dalla classe che lo ha creato e mi pare che proprio questo sembrava dover essere "scandaloso" a prescindere da tutto.

l'alternativa è usare come interfaccia una classe non astratta (i metodi della quale ovviamente sarebbero implementati per non fare nulla, trattandosi dela "paradosso" di una istanza di un'interfaccia, nel caso venisse creato un oggetto di tale tipo) e ritornare l'oggeto del tipo concreto prodotto per valore, ma cadrebbe lo spunto iniziale visto che l'oggetto di interesse non sarebbe più sullo heap. (la discussione concettuale si sposterebbe altrove, immagino sia molto criticabile anche il fatto di poter creare un'istanza di un'interfaccia, anche se sarebbe inutile e non verrebbe mai effettivamente fatto)

Originariamente inviato da tomminno

Tipo? Io conosco solo le Xerces che essendo un ibrido C/C++ ti ritornano puntatori che il più delle volte devi deallocarti.
Ma certamente non esiste una sola API che ti ritorna un riferimento e nella documentazione ti dice che quell'oggetto te lo devi deallocare.

http://doc.trolltech.com/4.6/qtextco...ml#codecForMib

per es questo metodo ritorna un puntatore ad un oggetto e la documentazione non ti dice nulla sul fatto se diventa roba tua, l'oggetto, o se sarà la lib. a gestirne il ciclo di vita ...

poi, visto che si può supporre che by design avranno teso a minimizzare le probabilità di leak, e visto che non dicono esplcitamente di distruggerlo finito l'uso, si può optare per evitare la delete nel chiamante, ma in prima istanza rimane solo una ipotesi/deduzione, .. .una riga in più nella documentazione non faceva male ...

... tanto più che, senza nemmeno farlo apposta trovo nella documentazione della medesima classe uno snippet di esempio in cui al contrario un ulteriore oggetto restituito per indirizzo viene proprio deallocato dal chiamante quando non gli serve più

inoltre ben più comune è il caso "inverso" ma concettualmente simile, in cui passi un puntatore ad una api, puntatore ad un oggetto che hai creato nel chiamante o cmq altrove nel tuo codice "client" rispetto alla lib, ma che non avrai necessità o anche non dovrai permetterti di deallocare. situazione opposta alla factory ma che ripropone ancora un caso di oggetti sullo heap non distrutti dalla classe che li ha creati.

Originariamente inviato da tomminno

Se non puoi ci sono nel linguaggio le alternative per indicare tale circostanza, quindi perchè non usarle?
Se non viene fatto il più delle volte è perchè trovi una strutturazione molto alla C.

infatti ribadisco che non ho sostenuto nulla contro l'uso di auto_ptr et similia, ci deve essere stato anche un malinteso strada facendo

Originariamente inviato da tomminno

Sai un programma lo puoi sempre scrivere tutto nel main oppure strutturare ad oggetti applicando tutti i pattern di questo mondo. Il programma può funzionare benissimo in entrambi i casi.
Per questo si parla di best practices.

così mi metti un po' in imbarazzo ... qualunque risposta a questo punto sembrerà un accettare un invito alla polemica ... d'altra parte non ho voluto escluderlo perché avendo quotato tutti i punti poteva sembrare di volerne ignorare uno per "comodità" ... cmq nessuna "animosità" , per carità ... e, per la cronaca, anch'io voto per strutturazione e best practices, come tutti immagino.

Originariamente inviato da tomminno

E questo che c'entra? Anche un oggetto ritornato per valore viene deallocato quando va fuori dallo scope nel chiamante e allora?

infatti, lo scandalo era sul non distruggere un oggetto sullo heap nella stessa classe che lo ha creato, il caso ben più "tranquillo" di un oggetto sullo stack direi che esula dal punto inizialmente in questione

Originariamente inviato da tomminno

Infatti esiste da quel dì una classe chiamata shared_ptr, devi tornare un puntatore e non sai come viene usato? Torna uno shared_ptr e vedrai che risolverai molti dei tuoi problemi. Non a caso auto_ptr è deprecato.

ribadisco che nessuno ti ha "dato contro" sull'uso di auto_ptr/shared_ptr

Originariamente inviato da tomminno

Direi che questo c'entra poco con il discorso.
E' vero che tanti dicono male del singleton, ma in un programma ci sono delle variabili effettivamente globali, tipo le configurazioni.
Oppure pensa solo all'MVC se dei controller devono condividere lo stesso Model a chi chiederanno l'istanza del Model? Se non lo fai con un factory "singleton" io non ho molte altre alternative, se non quella che gli venga passato dal chiamante, ma non necessariamente il chiamante è in un contesto tale da avere un riferimento al Model richiesto.
Qualcuno ha altre alternative?

guarda che sul non abolire universalmente il singleton pattern con me sfondi una porta apreta

Originariamente inviato da tomminno

Sei te che l'hai presa come "regola assoluta", qui stiamo parlando di "best practice".
Sennò perchè non consigliare di scrivere tutto nel main così ci si evitano direttamente chiamate a funzioni o metodi con tutti gli eventuali problemi della gestione del ritorno?

best practice appunto, che non sempre però è possibile applicare. ti ricordo che inizialmente la best practice di cui si parlava era semplicemente di deallocare un oggetto sullo heap nel codice della stessa classe che lo ha creato e che a più d'uno è sembrato "scandaloso" ipotizzare situazioni in cui questo non avvenga, mentre continua sembrarmi chiaro che ci siano casi in cui è inevitabile

Originariamente inviato da tomminno

E questo che c'entra? Non ci sono certo problemi nell'implementare interfacce in C++, nè tanto meno factory.

no nessun problema radicale per carità, però se come interfaccia usi una classe astratta ed il prodotto lo vuoi ritornare come il tipo intefaccia, allora lo devi creare sullo heape ritornare per indirizzo ... ma non lo puoi deallocare nella stessa classe che lo ha creato (non molto sensatamente almeno essendo una factory) ... siamo partiti più o meno da qui no ?

[Wing_Zero]

Originariamente inviato da MenageZero

no nessun problema radicale per carità, però se come interfaccia usi una classe astratta ed il prodotto lo vuoi ritornare come il tipo intefaccia, allora lo devi creare sullo heape ritornare per indirizzo ... ma non lo puoi deallocare nella stessa classe che lo ha creato (non molto sensatamente almeno essendo una factory) ... siamo partiti più o meno da qui no ?

Ecco, appunto. esattamente quello che intendevo.
Penso sia troppo palese per non concordare su questo punto.

[cionci]

Originariamente inviato da Wing_Zero

chi dealloca l'oggetto?
il chiamante quando sa che non gli serve più.

E chi ti ha detto che non serva più a chi te lo ha ritornato ?

Originariamente inviato da Wing_Zero

Chi dealloca il puntatore?
Scusa, ma come si dealloca un puntatore? al massimo lo metti =0.

Avevo frainteso il tuo discorso su object come puntatore, credevo ti riferissi ad Object.

Comunque riprendendo l'esempio che hai fatto:

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

Forse return *object ?
O Object * come tipo di ritorno ?

Sui Factory object o Factory method... Tipicamente mi piace che non ritornino per riferimento o per puntatore. Dal punto di vista prestazionale certo non è la scelta migliore ed in altri casi non è nemmeno la scelta migliore dal punto di vista architetturale.

Nel caso in cui si ritorni un puntatore, allora è implicito per la natura dei pattern stessi che perdano il controllo su ciò che producono.

Solitamente se si ritorna per riferimento, il chiamante ha in mano un alias ad un altro oggetto, quindi implicitamente si accetta che l'oggetto abbia vita oltre alla distruzione dell'alias. Mi sembra francamente la soluzione peggiore per uno dei pattern sopra, a meno che il Factory object (farlo con un Factory method sarebbe assurdo) non resti il proprietario dell'oggetto e ne sia responsabile anche della deallocazione.

Giusto per fare un esempio, generalizzando:
- se ritorno un puntatore ad una macchina è come se mi dicessero: "la macchina è tua e ti regalo anche le chiavi"
- se invece ritorno un riferimento ad una macchina è come se mi dicessero: "ti presto la macchina, ma resta mia, usala con le chiavi di riserva, ma le altre ce l'ho io, quindi la posso usare anche io"

[MenageZero]

Originariamente inviato da cionci

E chi ti ha detto che non serva più a chi te lo ha ritornato ?

Avevo frainteso il tuo discorso su object come puntatore, credevo ti riferissi ad Object.

Comunque riprendendo l'esempio che hai fatto:

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

Forse return *object ?
O Object * come tipo di ritorno ?

Sui Factory object o Factory method... Tipicamente mi piace che non ritornino per riferimento o per puntatore. Dal punto di vista prestazionale certo non è la scelta migliore ed in altri casi non è nemmeno la scelta migliore dal punto di vista architetturale.

Nel caso in cui si ritorni un puntatore, allora è implicito per la natura dei pattern stessi che perdano il controllo su ciò che producono.

Solitamente se si ritorna per riferimento, il chiamante ha in mano un alias ad un altro oggetto, quindi implicitamente si accetta che l'oggetto abbia vita oltre alla distruzione dell'alias. Mi sembra francamente la soluzione peggiore per uno dei pattern sopra, a meno che il Factory object (farlo con un Factory method sarebbe assurdo) non resti il proprietario dell'oggetto e ne sia responsabile anche della deallocazione.

Giusto per fare un esempio, generalizzando:
- se ritorno un puntatore ad una macchina è come se mi dicessero: "la macchina è tua e ti regalo anche le chiavi"
- se invece ritorno un riferimento ad una macchina è come se mi dicessero: "ti presto la macchina, ma resta mia, usala con le chiavi di riserva, ma le altre ce l'ho io, quindi la posso usare anche io"

mi permetto di aggiungere qualche considerazione sull'esempio di wing e sulle tue osservazioni visto che mi ero "intromesso" nella discussione proprio attarverso l'esempio della factory

secondo me l' "&" è una svista, azzarderi che intendesse Qbject* come tipo di ritorno visto che si parlava di lasciare al chiamante la distruzione di object

in uno scenario del genere penso si posa considerare l'assunzione che chi ritorna Object* perda ogni riferimento e controllo su object, visto che appunto il chiamato sarebbe una classe Factory; come tra l'altro tu stesso puntualizzi nel discutere l'opzione con Object* come tipo di ritorno, no ?

forse sbaglio ma una factory che rimane proprietario delle istanze prodotto mi parrebbe ben poco factory semanticamente ,
un chiamato che ritorna un puntatore o riferimento ed è proprietario dell'oggetto(o che cmq semanticamente include l'assunzione che il chiamante non deve deallocare l'oggetto) mi da più l'dea di situazione da pattern tipo registry/repository o semplicemente "mappa", in generale ... cmq non factory .. che ne pensi ?

edit:
volevo anche chiedere un parere (anche a chiunque altro volesse dire al sua ovviamente)su una cosa che avevo accennato in un altro post,

ovvero usare come interfaccia una classe concreta (con implementazione dei relativi metodi che ovviamente non fa nulla, e che magari ha un metodo - per es un cosa come bool isNull() - per distinguere se un oggeto di quel tipo è veramente una implementazione dell'interfaccia o una inutile istanza dell' "interfaccia" stessa, anche se in tale scenario probabilmente poco ortdosso ovviamente l'assunzione sarebbe che nessuno creerebbe mai un'istanza dell' "interfaccia")

tale approccio potrebbe servire , in una implementazione di factory, per poter ritornare le istanze prodotto effettivamente per valore aggirando totalmente la questione di dover avere un oggetto sullo heap che non potrà essere distrutto dalla stessa classe/livello di astrazione che lo ha creato.

ovviamente il tutto sposterebbe i problemi concettuali sul fatto di ritrovarsi un' "intefaccia" istanziabile, anche se non ci sarebbe motivo di crearne istanze dirette. magari è riternuto molto peggio che il factory method ritornante un puntatore (magari wrappato con auto_ptr o altro) "comprensivo" di ownership sull'oggetto puntato

[cionci]

Originariamente inviato da MenageZero

mi permetto di aggiungere qualche considerazione sull'esempio di wing e sulle tue osservazioni visto che mi ero "intromesso" nella discussione proprio attarverso l'esempio della factory

secondo me l' "&" è una svista, azzarderi che intendesse Qbject* come tipo di ritorno visto che si parlava di lasciare al chiamante la distruzione di object

Io sinceramente l'avevo letto così nella prima interpretazione:

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

Originariamente inviato da MenageZero

forse sbaglio ma una factory che rimane proprietario delle istanze prodotto mi parrebbe ben poco factory semanticamente

Imho di fatto diventa una via di mezzo fra factory e repository.
Per la parte creazionale resta comunque un factory, perché è l'unico che può creare un oggetto di un certo tipo.

Originariamente inviato da MenageZero

edit:
volevo anche chiedere un parere (anche a chiunque altro volesse dire al sua ovviamente)su una cosa che avevo accennato in un altro post,

ovvero usare come interfaccia una classe concreta (con implementazione dei relativi metodi che ovviamente non fa nulla, e che magari ha un metodo - per es un cosa come bool isNull() - per distinguere se un oggeto di quel tipo è veramente una implementazione dell'interfaccia o una inutile istanza dell' "interfaccia" stessa, anche se in tale scenario probabilmente poco ortdosso ovviamente l'assunzione sarebbe che nessuno creerebbe mai un'istanza dell' "interfaccia")

Non è un Null Object pattern ?

[Wing_Zero]

Originariamente inviato da cionci

E chi ti ha detto che non serva più a chi te lo ha ritornato ?

Avevo frainteso il tuo discorso su object come puntatore, credevo ti riferissi ad Object.

Comunque riprendendo l'esempio che hai fatto:

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

Forse return *object ?
O Object * come tipo di ritorno ?

Sui Factory object o Factory method... Tipicamente mi piace che non ritornino per riferimento o per puntatore. Dal punto di vista prestazionale certo non è la scelta migliore ed in altri casi non è nemmeno la scelta migliore dal punto di vista architetturale.

Nel caso in cui si ritorni un puntatore, allora è implicito per la natura dei pattern stessi che perdano il controllo su ciò che producono.

Solitamente se si ritorna per riferimento, il chiamante ha in mano un alias ad un altro oggetto, quindi implicitamente si accetta che l'oggetto abbia vita oltre alla distruzione dell'alias. Mi sembra francamente la soluzione peggiore per uno dei pattern sopra, a meno che il Factory object (farlo con un Factory method sarebbe assurdo) non resti il proprietario dell'oggetto e ne sia responsabile anche della deallocazione.

Giusto per fare un esempio, generalizzando:
- se ritorno un puntatore ad una macchina è come se mi dicessero: "la macchina è tua e ti regalo anche le chiavi"
- se invece ritorno un riferimento ad una macchina è come se mi dicessero: "ti presto la macchina, ma resta mia, usala con le chiavi di riserva, ma le altre ce l'ho io, quindi la posso usare anche io"

Allora, apparte la svista dell'&, l'esempio pratico che ho portato io era la factory.
Come ha appunto fatto notare managezero in un caso del genere la factory ( prendendo l'esempio della macchina) "ti regala l'unica copia di chiavi che esiste".

In questo caso risulta palese che l'oggetto debba essere distrutto fuori dalla classe stessa...

[MenageZero]

Originariamente inviato da cionci

Non è un Null Object pattern ?

in effetti magari l'idea l'avevo presa da qualche parte, non ho esattamente una memoria di ferro con i nomi, specie se sono di qualcosa che non applico spesso o recentemente

da quello che vedo con una velocissima (qundi imprecisissima) google-ata probabilmente una classe fatta in quel modo può esserevi assimilata, solo a prima vista non ho notato riferimenti a farne un uso da interfaccia

[cionci]

Il Null Pattern comunque può essere usato anche con l'interfaccia, si estrae l'interfaccia (classe astratta) dal Null Pattern che coinciderà con quella delle implementazione concrete.
Quindi il Null Pattern deriverà dalla classe base astratta così come le altre implementazioni.

Originariamente inviato da Wing_Zero

Allora, apparte la svista dell'&, l'esempio pratico che ho portato io era la factory.
Come ha appunto fatto notare managezero in un caso del genere la factory ( prendendo l'esempio della macchina) "ti regala l'unica copia di chiavi che esiste".

In questo caso risulta palese che l'oggetto debba essere distrutto fuori dalla classe stessa...

Certo, ma io partivo dal fatto che tu ritornassi un Object &, non un Object *...

Resta il fatto che se per una factory la cosa è palese, non è sempre palese in altri casi. In questo caso non trovo necessario dover ritornare un puntatore. Meglio un riferimento ma non allocato dinamicamente.