fek docet... :)

[71104]

su CodeGuru nella sezione di driver programming per Windows è saltato fuori un thread in cui si discute su come mai i drivers si programmano in C e come mai in C++; io, forte delle lezioni del mio maestro () ho fatto la mia figura; ecco il link al thread:
http://www.codeguru.com/forum/showthread.php?t=386346
il mio nick è mrnt, ma penso che quelli di DC lo capiscono dall'avatar...

ah fek, se lo leggi, iscriviti al forum e posta: "look mummy, no if!"

[jappilas]

Originariamente inviato da 71104

su CodeGuru nella sezione di driver programming per Windows è saltato fuori un thread in cui si discute su come mai i drivers si programmano in C e come mai in C++; io, forte delle lezioni del mio maestro () ho fatto la mia figura; ecco il link al thread:
http://www.codeguru.com/forum/showthread.php?t=386346
il mio nick è mrnt, ma penso che quelli di DC lo capiscono dall'avatar...

ah fek, se lo leggi, iscriviti al forum e posta: "look mummy, no if!"

c'è anche un altro paio di fattori che avresti potuto tirare in ballo a riprova: embedded C++, come linguaggio (meglio, subset del linguaggio) fatto per conciliare il c++ e la OOP con i requisiti della progranazione embedded e di sistema
MacOsX, o meglio il suo kernel (cioè non esattamente Mach, come spesso si dice, ma XNU, versione pesantemente modificata), il cui sottosistema Device Expert è appunto realizzato in eC++
L4 :: pistachio, come esempio di kernel scritto in c++ per conciliare le prestazioni con la manutenibilità e la portabilità del codice del (micro)kernel stesso

[tomminno]

Originariamente inviato da 71104

su CodeGuru nella sezione di driver programming per Windows è saltato fuori un thread in cui si discute su come mai i drivers si programmano in C e come mai in C++; io, forte delle lezioni del mio maestro () ho fatto la mia figura; ecco il link al thread:
http://www.codeguru.com/forum/showthread.php?t=386346
il mio nick è mrnt, ma penso che quelli di DC lo capiscono dall'avatar...

ah fek, se lo leggi, iscriviti al forum e posta: "look mummy, no if!"

Quoto l'ultima parte del codice C++ che hai postato:

void DeterminingFunction(BaseEntity *entity) {
	entity->Behave();
}

Questo metodo non ha molto senso, dovevi postare il codice che istanzia entity.
Per riprendere l'esempio C da qualche parte in C++ avrai un qualcosa tipo

void DeterminingFunction(PENTITY Entity) {
	switch (Entity->Type) {
	case ENTITY_TYPE_1:
		entity = new Entity1();
		break;
	case ENTITY_TYPE_2:
		entity = new Entity2();
		break;
	case ENTITY_TYPE_3:
		entity = new Entity3();
		break;
	.
	.
	.
	default:
		ManageError();
		break;
	}
}

altrimenti come fai a stabilire quale classe devi istanziare?
Il codice non è poi diverso da quello C.
Sinceramente non saprei come trovare un metodo alternativo per istanziare entity qualora dipendesse dal valore di Entity->Type.
Ma si può sempre imparare qualcosa di nuovo

[jappilas]

Originariamente inviato da tomminno

Sinceramente non saprei come trovare un metodo alternativo per istanziare entity qualora dipendesse dal valore di Entity->Type.
Ma si può sempre imparare qualcosa di nuovo

state design pattern , per dirne uno
può non essere sempre applicabile o la soluzione migliore, quindi di modi ne esistono e se ne applicano parecchi altri, che spaziano dal factory method, all' uso di qualche if ...

[tomminno]

Originariamente inviato da jappilas

state design pattern , per dirne uno
può non essere sempre applicabile o la soluzione migliore, quindi di modi ne esistono e se ne applicano parecchi altri, che spaziano dal factory method, all' uso di qualche if ...

Sarà che mi manca di vedere un codice completo di un design pattern tipo il Factory Method, gli esempi che trovo in rete non mi hanno mai chiarito le idee a riguardo perchè sono sempre brandelli di codice separati. Ho pure il libro della GOF, ma le idee non mi si sono chiarite per niente, ho capito quando usarlo, ma non come realizzarlo.
Il Factory Method si usa quando una classe non sa quale tipo di sottoclasse istanziare, quindi la si demanda ad una classe Creator (generalmente astratta) il compito di decidere quale. Questa classe Creator generalmente si specializza in base alle classi che possono essere istanziate.
Ma nel caso della parametrizzazione, come il suddetto esempio, il Factory Method utilizza anche lui uno switch (almeno sempre negli esempi che ho potuto trovare) e sinceramente non riesco a vedere una soluzione alternativa.

Mi interesserebbe capire veramente come farlo semplicemente usando il subclassing e senza l'utilizzo dello switch.

[thebol]

Originariamente inviato da tomminno

Sarà che mi manca di vedere un codice completo di un design pattern tipo il Factory Method, gli esempi che trovo in rete non mi hanno mai chiarito le idee a riguardo perchè sono sempre brandelli di codice separati. Ho pure il libro della GOF, ma le idee non mi si sono chiarite per niente, ho capito quando usarlo, ma non come realizzarlo.
Il Factory Method si usa quando una classe non sa quale tipo di sottoclasse istanziare, quindi la si demanda ad una classe Creator (generalmente astratta) il compito di decidere quale. Questa classe Creator generalmente si specializza in base alle classi che possono essere istanziate.
Ma nel caso della parametrizzazione, come il suddetto esempio, il Factory Method utilizza anche lui uno switch (almeno sempre negli esempi che ho potuto trovare) e sinceramente non riesco a vedere una soluzione alternativa.

Mi interesserebbe capire veramente come farlo semplicemente usando il subclassing e senza l'utilizzo dello switch.

Vero, ma il vantaggio del factory e che la scelta avviene una volta sola(la cosa non è magari sempre fattibile), mentre invece in C con lo switch ci passi sempre.

Il trade-off è probabilmente nell'occupazione di memoria dell'oggetto instanziato, ma quella varia da caso a caso(e puo essere minima)

[tomminno]

Originariamente inviato da thebol

Vero, ma il vantaggio del factory e che la scelta avviene una volta sola(la cosa non è magari sempre fattibile), mentre invece in C con lo switch ci passi sempre.

Il trade-off è probabilmente nell'occupazione di memoria dell'oggetto instanziato, ma quella varia da caso a caso(e puo essere minima)

In realtà puoi evitarlo anche con il C usando i puntatori a funzione, usi una volta sola lo switch e poi il puntatore.
Il problema però si ripresenta immutato se devi switchare tra un metodo e l'altro in continuazione al variare degli ingressi. Fortunatamente in tutti i casi che mi sono capitati lo switch lo uso una volta sola.
In un caso come quello riportato se quello che cambia è solo un metodo io userei un puntatore a metodo invece del subclassing (ma anche qui è tutto da vedere).

Però mi rimane il dubbio, se si può fare effettivamente senza usare lo switch, vorrei capire come fare.

[thebol]

Originariamente inviato da tomminno

In realtà puoi evitarlo anche con il C usando i puntatori a funzione, usi una volta sola lo switch e poi il puntatore.
Il problema però si ripresenta immutato se devi switchare tra un metodo e l'altro in continuazione al variare degli ingressi. Fortunatamente in tutti i casi che mi sono capitati lo switch lo uso una volta sola.
In un caso come quello riportato se quello che cambia è solo un metodo io userei un puntatore a metodo invece del subclassing (ma anche qui è tutto da vedere).

Però mi rimane il dubbio, se si può fare effettivamente senza usare lo switch, vorrei capire come fare.

per come la vedo io, è impossibile non usarli. Ma li si puo limitare a oggetti factory o cmq alla creazione dell'oggetto stesso. Questo soprattutto quando hai a che fare con oggetti vicini al basso livello. Che li fornisce qualche if lo dovra avere, il vantaggio deve essere in chi li usa.

[jappilas]

Originariamente inviato da thebol

per come la vedo io, è impossibile non usarli. Ma li si puo limitare a oggetti factory o cmq alla creazione dell'oggetto stesso. Questo soprattutto quando hai a che fare con oggetti vicini al basso livello. Che li fornisce qualche if lo dovra avere, il vantaggio deve essere in chi li usa.

in realta' in certi, magari rari, casi si puo' evitare anche l' if o quantomeno evitare degli switch laddove si pensa di doverne usare...
come ho imparato tramite diamonds si possono usare oggetti "stato" che, quando invocato un loro metodo getNext(), o update(), o... , ritornano o se stessi, o l' oggetto corrispondente allo stato successivo della state machine , contenuto in una variabile membro sul tipo

private nextConcreteState newstate;

certo, in altri casi qualche if incapsulato in un metodo creatore sara' comunque una soluzione migliore (piu' semplice ed efficiente) di questo schema...
quindi alla fine si ricade nel primo punto del fek - insegnamento, cioe' saper scegliere lo strumento migliore a seconda delel circostanze e usarlo...

[thebol]

Originariamente inviato da jappilas

in realta' in certi, magari rari, casi si puo' evitare anche l' if o quantomeno evitare degli switch laddove si pensa di doverne usare...
come ho imparato tramite diamonds si possono usare oggetti "stato" che, quando invocato un loro metodo getNext(), o update(), o... , ritornano o se stessi, o l' oggetto corrispondente allo stato successivo della state machine , contenuto in una variabile membro sul tipo

private nextConcreteState newstate;

quel o sarà un if nello stato
o meglio non sempre(se quell'o puo essere deciso a tempo di creazione dell'oggetto, si possono fare + costruttori)(oppure con factory, come dicevi tu).

Diciamo che tramite l'OOP se ne puo limitare fortemente l'uso..
alla java conference dell'anno scorso, il ragazzo di xpLabs mostro proprio come realizzare un programma di gestione paghe, limitando al max l'uso degli if e facendo in modo che per inserire una nuova funzionalita non si dovesse modificare il codice esistente(o farlo in maniera molto limitata) ma si dovesse solo creare nuove classi/oggetti.

Per quest'anno aveva promesso di mostrarci come non utilizzare i cicli, ma ho visto fa solo le sessioni a pagamento, e non so se ci potrò andare..

[cdimauro]

Con Delphi si possono in parte risolvere ricorrendo ai costruttori virtuali (chiamati anche "meta classi"): http://blogs.borland.com/abauer/arch...10/11/258.aspx

[thebol]

Originariamente inviato da cdimauro

Con Delphi si possono in parte risolvere ricorrendo ai costruttori virtuali (chiamati anche "meta classi"): http://blogs.borland.com/abauer/arch...10/11/258.aspx

in java si puo fare appoggiandosi all'oggetto Class.newInstace(), che usa (se lo trova) il costruttore senza parametri. Utilizzando la reflection si possono usare anche costruttori con paramentri, ma in effetti non è possibile definire un costruttore virtuale per una gerarchia di classi a livello di linguaggio

[tomminno]

Originariamente inviato da cdimauro

Con Delphi si possono in parte risolvere ricorrendo ai costruttori virtuali (chiamati anche "meta classi"): http://blogs.borland.com/abauer/arch...10/11/258.aspx

Chissà perchè mi ricordano un pò il Factory Method realizzato con metodi template

Comunque siamo punto e da capo prendendo il codice Delphi, te sai che AComponent è un TMyComponent, e AnotherComponent è un TMyOtherComponent. Direi proprio che sono noti a compile-time, non a run-time.

procedure CreateComponents;
var
  AComponent: TComponent;
  AnotherComponent: TComponent;
begin
  AComponent := CreateComponent(TMyComponent);
  AnotherComponent := CreateComponent(TMyOtherComponent);
end;

Come lo scriveresti il codice se AComponent dovesse essere TMyComponent o TMyOtherComponent a seconda del valore di un qualche parametro fornito al costruttore della classe? Cioè se il loro tipo fosse noto a run-time?

[cdimauro]

Originariamente inviato da tomminno

Chissà perchè mi ricordano un pò il Factory Method realizzato con metodi template

Comunque siamo punto e da capo prendendo il codice Delphi, te sai che AComponent è un TMyComponent, e AnotherComponent è un TMyOtherComponent. Direi proprio che sono noti a compile-time, non a run-time.

procedure CreateComponents;
var
  AComponent: TComponent;
  AnotherComponent: TComponent;
begin
  AComponent := CreateComponent(TMyComponent);
  AnotherComponent := CreateComponent(TMyOtherComponent);
end;

Come lo scriveresti il codice se AComponent dovesse essere TMyComponent o TMyOtherComponent a seconda del valore di un qualche parametro fornito al costruttore della classe? Cioè se il loro tipo fosse noto a run-time?

Dipende da quello che ci devi fare. Quello era soltanto un esempio, e per forza di cose dev'essere semplice: l'obiettivo è quello di far capire il concetto di costruttore virtuale (o meta classe che dir si voglia).

Torniamo all'esempio di cui si stava parlando, così magari si capisce meglio. Nel caso dello switch, il codice lo scriverei in maniera similare (a parte lo switch chiaramente). Mi spiego.

Qualcuno dovrà pur avere settato quel valore che viene passato alle varie funzioni, giusto? Finché poi non giunge al codice in cui c'è quello switch che serve a costruire finalmente la classe in questione.

Bene, il concetto è esattamento lo stesso, salvo che al posto di settare un ben preciso valore e trascinarselo dietro fino allo switch, come valore passo il riferimento alla classe che m'interessa.

Questo per rispondere alla domanda che ponevi. Quindi il concetto è quello di passare riferimenti a classi anziché valori "classici" (numeri, enumativi, stringhe, ecc.).

In questo modo, quando arriverà al codice in oggetto, anziché eseguire lo switch, si eseguirà semplicemente AComponent.Create() e otterremo l'istanza della classe desiderata.

In soldoni il codice, usando i costruttori virtuali (con la sintassi del C++), sarebbe il seguente:

void DeterminingFunction(ENTITYCLASS Entity) {
   entity = new Entity();
   entity->Behave();
}

Semplice, no?

Io l'ho usato come il pane nei miei progetti con Delphi. E' uno strumento sintattico molto utile.

EDIT. Dimenticavo. Anche in Python si può fare la stessa cosa:

class Pippo():

  def Mostra(self):
    print 'Prova pippo'

class Pluto():

  def Mostra(self):
    print 'Prova pluto'


def Prova(Classe):

  a = Classe()
  a.Mostra()


Prova(Pippo) # --> 'Prova pippo'
Prova(Pluto) # --> 'Prova pluto'

Python rulez.

[thebol]

Originariamente inviato da cdimauro

Bene, il concetto è esattamento lo stesso, salvo che al posto di settare un bel preciso valore e trascinarselo dietro fino allo switch, come valore passo il riferimento alla classe che m'interessa.

Questo per rispondere alla domanda che ponevi. Quindi il concetto è quello di passare riferimenti a classi anché valori "classici" (numeri, enumativi, stringhe, ecc.).

In questo modo, quando arriverà al codice in oggetto, anziché eseguire lo switch, si eseguirà semplicemente AComponent.Create() e otterremo l'istanza della classe desiderata.

e per questo che dicevo che piu usi oggetti vicino al basso livello, o cmq oggetti su cui non hai il controllo, piu è facile dover'usare gli if. Certo che si puo realizzare uno strato, che faccia questo lavoro

[Angus]

Originariamente inviato da thebol

Il trade-off è probabilmente nell'occupazione di memoria dell'oggetto instanziato, ma quella varia da caso a caso(e puo essere minima)

Personalmente credo che hai colto il punto della questione: trade-off tra diversi aspetti di complessità. In C++ posso scrivere apparentemente codice meno esoso di CPU ma più esoso di memoria rispetto al C. Dico apparentemente perchè conosco solo superficialmente i meccanismi dei rispettivi compilatori: sarebbe opportuno confrontare il codice macchina prodotto per misurare l'effettivo overhead.

[cdimauro]

Originariamente inviato da thebol

e per questo che dicevo che piu usi oggetti vicino al basso livello, o cmq oggetti su cui non hai il controllo, piu è facile dover'usare gli if. Certo che si puo realizzare uno strato, che faccia questo lavoro

Beh, coi costruttori virtuali siamo comunque a un livello basso, dal punto di vista implementativo, visto che viene sostanzialmente passato un puntatore alla VMT della classe, in giro per il codice.

La differenza è che qui hai un controllo maggiore / migliore, perché non puoi sbagliare a passare una costante: il compilatore Delphi ti sega le mani alla prima passata del sorgente, appena ci provi.

Inoltre il codice è molto più chiaro e leggibile (e senza if).

Certo, può essere un prezzo salato da pagare, visto che si deve istanziare una classe, ma dipende al tipo di codice che si sta realizzando.

Come dicevi tu, c'è un tradeoff da considerare, ma fra questi c'è pure quello relativo all'assenza di if, che evita i salti ed eventuali svuotamenti della pipeline del processore, ad esempio.

[tomminno]

Originariamente inviato da cdimauro

Qualcuno dovrà pur avere settato quel valore che viene passato alle varie funzioni, giusto? Finché poi non giunge al codice in cui c'è quello switch che serve a costruire finalmente la classe in questione.

Possiamo pure pensare che sia un parametro del costruttore della classe che deve occuparsi di istanziare la classe corretta (il ConcreteCreator per dirla nei termini del Pattern Factory).

Bene, il concetto è esattamento lo stesso, salvo che al posto di settare un bel preciso valore e trascinarselo dietro fino allo switch, come valore passo il riferimento alla classe che m'interessa.

E' qui che non capisco. Come fai a conoscere la classe che ti interessa se non esamini il valore del parametro?

Questo per rispondere alla domanda che ponevi. Quindi il concetto è quello di passare riferimenti a classi anché valori "classici" (numeri, enumativi, stringhe, ecc.).

In questo modo, quando arriverà al codice in oggetto, anziché eseguire lo switch, si eseguirà semplicemente AComponent.Create() e otterremo l'istanza della classe desiderata.

In soldoni il codice, usando i costruttori virtuali (con la sintassi del C++), sarebbe il seguente:

void DeterminingFunction(ENTITYCLASS Entity) {
   entity = new Entity();
   entity->Behave();
}

Semplice, no?

Io l'ho usato come il pane nei miei progetti con Delphi. E' uno strumento sintattico molto utile.

EDIT. Dimenticavo. Anche in Python si può fare la stessa cosa:

class Pippo():

  def Mostra(self):
    print 'Prova pippo'

class Pluto():

  def Mostra(self):
    print 'Prova pluto'


def Prova(Classe):

  a = Classe()
  a.Mostra()


Prova(Pippo) # --> 'Prova pippo'
Prova(Pluto) # --> 'Prova pluto'

Python rulez.

Ma se la logica è del tipo:

class Stampa;
class StampaPippo : public Stampa;
class StampaPluto : public Stampa;

Stampa * DecidiStampa(int ID)
{
    if (ID == 0)
        return new StampaPippo();
    if (ID == 1)
        return new StampaPluto();
}

Come utilizzi il pattern senza passare dagli if? A run time qualcuno imposta il valore di ID, in base a questo valore io poi devo utilizzare StampaPippo o StampaPluto.

Ho visto anche un'implementazione a template del metodo del tipo:

template <class T> Stampa * Stampa<T>::DecidiStampa()
{
    return new T();
}

Il fatto è come decidi il parametro template da passare?

[cdimauro]

Originariamente inviato da tomminno

Possiamo pure pensare che sia un parametro del costruttore della classe che deve occuparsi di istanziare la classe corretta (il ConcreteCreator per dirla nei termini del Pattern Factory).

Sì, va bene lo stesso (nell'esempio Delphi del link che ho postato usa una semplice funzione, ma possiamo fare quello che vogliamo: è soltanto un parametro).

E' qui che non capisco. Come fai a conoscere la classe che ti interessa se non esamini il valore del parametro?

Perché è il valore stesso a rappresentare la classe.

In sostanza, io sto passando un puntatore alla VMT della classe di cui m'interessa creare un'istanza. Sarà poi al momento della creazione dell'istanza, richiamando il costruttore (virtuale) Create (come nell'esempio Delphi) che verrà prelevato dalla VMT il puntatore alla funzione Create specifica per questa classe, e quindi generata l'istanza.

Ma se la logica è del tipo:

class Stampa;
class StampaPippo : public Stampa;
class StampaPluto : public Stampa;

Stampa * DecidiStampa(int ID)
{
    if (ID == 0)
        return new StampaPippo();
    if (ID == 1)
        return new StampaPluto();
}

Come utilizzi il pattern senza passare dagli if? A run time qualcuno imposta il valore di ID, in base a questo valore io poi devo utilizzare StampaPippo o StampaPluto.

Ho visto anche un'implementazione a template del metodo del tipo:

template <class T> Stampa * Stampa<T>::DecidiStampa()
{
    return new T();
}

Il fatto è come decidi il parametro template da passare?

Il C++ non ha i costruttori virtuali, per cui non c'è un equivalente "diretto".

L'unico modo che mi viene in mente, su due piedi, per fare la stessa cosa, è usando delle funzioni apposite che creano l'apposita istanza della classe a cui sono "legate".

Quindi, in soldoni, definirei un tipo puntatore a funzione, la cui funzione restituisce un puntatore alla classe base Stampa.
Poi creerei due funzioni, una per creare StampaPippo e una per StampaPluto, che tornino le rispettive istanze. Qui si potrebbero benissimo usare due funzioni static dentro le rispettive classi.
A questo punto al factory method passerei come parametro il puntatore alla funzione che mi crea StampaPippo o StampaPluto, a seconda dell'istanza che voglio ottenere.


Anche qui, come "vedi" , il codice non conterrà nessun if.

E' soltanto più macchinoso perché il C++ non ha un equivalente sintattico dei costruttori virtuali, ma si può fare esattamente la stessa cosa.

EDIT: qualcosa di questo tipo:

class Stampa;

class StampaPippo : public Stampa {

   static Stampa* Create() {
       return new StampaPippo();
   }

};

class StampaPluto : public Stampa {

   static Stampa* Create() {
       return new StampaPluto();
   }

};

Stampa* DecidiStampa(Stampa* (*Constructor))
{
    return Constructor();
}

DecidiStampa(&StampaPippo.Create);
DecidiStampa(&StampaPluto.Create);

E' da un bel po' di anni che non scrivo codice C++: spero di non aver scritto delle castronerie...

[tomminno]

Originariamente inviato da cdimauro

A questo punto al factory method passerei come parametro il puntatore alla funzione che mi crea StampaPippo o StampaPluto, a seconda dell'istanza che voglio ottenere.

Proprio qui sta il nodo che non riesco a sciogliere. Come fai a decidere?
Una volta che sai se hai bisogno di StampaPippo o di StampaPluto la soluzione è chiara, è quando ancora non sai se ti serve StampaPippo o StampaPluto che non mi è chiaro.