[c++]Policy classes

[giuseppe500]

ciao.
Sto leggendo modern c++ design e ho un pccolo dubbio su quanto riguarda la costruzione e l'uso delle policy classes .
Da quello che ho capito la "grande esplosione" di possibilità di configurazione sta nell utilizzo delle polices ortogonali(le chiama cosi') nel senso che non hanno nulla a che vedere con le altre policies e nella specializzazionone di queste polices che sono template e usano questa caratteristica(specializzazione).
in pratica tramite la specializzazione posso ottenere una specie di polimorfismo(sbaglio?)a compile time.
questo è per ottenere un codice manutenibile e pulito ed estendibile?
ad es voglio aggiungere una configurazione , aggiungo una specializzazione , parziale o non della police interessata.
Un altra cosa su cui ho dei dubbi è questa:
La host class che "assemblo" eredita dalle polices passate come parametro template, ma questo è per ottenere un interfaccia della host class composta dalle varie polices o perchè?c'è qualche altro motivo?non si puo' utilizzare i paraametri template e basta?
è solo per avere una interfaccia reale?

grazie.

[shodan]

Originariamente inviato da giuseppe500
in pratica tramite la specializzazione posso ottenere una specie di polimorfismo(sbaglio?)a compile time.

Esatto.

questo è per ottenere un codice manutenibile e pulito ed estendibile?

Estensibile si, mantenibile e pulito è questione di abilità che si acquisisce con la pratica (come un po' tutto del resto).

La host class che "assemblo" eredita dalle polices passate come parametro template

Con "ereditare" intendi una derivazione dalla classe policy o un suo uso interno? Occhio che i termini sono importanti per evitare confusione.

[giuseppe500]

Originariamente inviato da shodan
Con "ereditare" intendi una derivazione dalla classe policy o un suo uso interno? Occhio che i termini sono importanti per evitare confusione.

intendo derivazione dalla classe policy che da quello che ho capito serve per definire(costruire)un interfaccia per la classe host.
In pratica se non derivassi dalle classi policy la mia classe host non avrebbe interfaccia invece facendola derivare in pratica la "monto" l'interfaccia e se ho ccapito bene è un bel metodo secondo me , ma forse non ho capito perchè :

Con "ereditare" intendi una derivazione dalla classe policy o un suo uso interno?

per uso interno: posso usare le classy policy anche se ho ereditato da esse per "uso interno"
cosa intendi per uso interno?
grazie Shodan.
ciao.

[shodan]

Originariamente inviato da giuseppe500
intendo derivazione dalla classe policy che da quello che ho capito serve per definire(costruire)un interfaccia per la classe host.

Non proprio. La classe policy determina il comportamento della classe host, ma non ha nulla a che vedere con l'interfaccia di quest'ultima.
Un esempio è la classe std::vector.
std::vector è definita più o meno:

template <class T, class Alloc = std::allocator<T>
class vector { ... etc.

La policy di default è di usare std::allocator per la gestione interna della memoria, ma nell'interfaccia di vector non c'è niente che faccia riferimento ai metodi di std::allocator.
Significa che se crei g500:ersonal_allocator (rispettando l'interfaccia stabilita per gli allocatori) puoi usare un vector come:

vector<data_type, g500::personal_allocator<data_type>> vec;

senza dover modificare l'interfaccia di vector.
Diciamo che la policy lavora dietro le quinte senza mai farsi vedere (uso interno).

per uso interno: posso usare le classy policy anche se ho ereditato da esse per "uso interno"
ciao.

Sono classi, quindi puoi ereditare senza problemi, ma una policy può definire nomi di dato tramite dei typedef pertanto se una classe host si aspetta dei tipi di dato definiti da una policy derivata, non puoi passargli la policy base senza i typedef che la classe host si aspetta dalla policy derivata.
La classe host non deve avere idea di star usando una classe policy.

[giuseppe500]

grazie Shodan, grazie di avermi chiarito perchè avevo capito male.

scusa se rompo ma ho altre due domande:

1)la policy quindi lavora utilizzando le sue funzioni all interno della classe host , senza modificarne l'interfaccia , perchè al suo interno ha definito la logica e i metodi che fanno una certa cosa (adesso capisco perchè le policy devono essere ortogonali cosi dice il libroer non pestarsi i piedi in pratica e fornire un esplosione di possibilità di configurazione).Ma queste classi policy possono derivare da qualcosa d'altro o usare funzioni per es di un model, se incapsulo classi nella policy o è da sconsigliare?

2)il fatto di dare un comportamento diverso per ogni policy è dato dalla specializzazione parziale o completa o anche da una diversa implementazione e/o classi che posso includere nella policy o è megio di no?


grazie.

[shodan]

Originariamente inviato da giuseppe500
Ma queste classi policy possono derivare da qualcosa d'altro o usare funzioni per es di un model, se incapsulo classi nella policy o è da sconsigliare?

Alla classe host importa solo delle funzioni e dei tipi di dato esposti dall'interfaccia della classe policy. Che poi la classe policy sia derivata, composta o creata da zero, non importa.
E' un pò come quando sali in macchina: non ti interessa sapere la cilindrata del motore, ma che si avvii e parta. Se poi dentro ci sono quattro criceti invece dei pistoni è un dettaglio implementativo: comunque ti muovi.

2)il fatto di dare un comportamento diverso per ogni policy è dato dalla specializzazione parziale o completa o anche da una diversa implementazione e/o classi che posso includere nella policy o è megio di no?

E' un insieme di questi fattori. Tornando all'esempio del vector e del suo allocatore, se un giorno scopri una funzione di allocazione che ad esempio funziona alla grande per i float ma pessima per gli int, puoi creare un tuo specifico allocatore oppure una specializzazione per std::allocator specifica per i float. Il vector non si accorgerebbe di niente.
Puoi anche creare un tuo allocatore che a sua volta utilizza una classe policy, che contiene le reali funzioni di allocazione della memoria.
Tempo fa ho usato proprio questo sistema per testare diversi container con funzioni di allocazione e deallocazione diverse. L'alternativa era o modificare manualmente il codice o creare quattro allocator diversi.
In ogni caso, il container testato non ha fatto una piega.

[XWolverineX]

Lo sto leggendo anche io proprio ora. Sono rimasto scioccato dalle policy class!

[giuseppe500]

ho un altra domanda:
sto cercando di applicare le policy classes a opengl .
per es una texture è il classico esempio di oggetto che richiede una configurazione e ha moltissime configurazioni possibili.
ho innanzitutto creato la host class:

template
<
class TipoFiltro,
class Compressione
 class Mipmap
>

class managerTexture
: public TipoFiltro
, public Compressione
, public MipMap
{
...
gltexture Create()
{
      gltexture mytexture ..... inizializzazione
      TipoFiltro::filter(mytexture );      
      Compressione::Compress(mytexture );
      MipMap::CreateMipMap(mytexture )

     return mytexture ;
}
private:

};

chiaramente in questo modo se creo una serie di classi per ogni policy ortonormale
1)TipoFiltro
2)Compressione
3)MipMap

l'esplosione di configurazioni è enorme.
inoltre in ogni policy per es di Compressione avro un algoritmo diverso , tipo lo strategy pattern della gof per intenderci, quindi lascierò al client la scelta dell algoritmo di compressione da usare , oppure permettero' di crearne uno personalizzato e cosi' per tutte le altre policy.

fino qui bene?

ecco la domanda :
se non voglio implementare nessun tipo di compressione , come posso fare? purtroppo non so se ho fatto un errore o meno ma il mio codice nella host class appare ed è piuttosto vincolante, sono io che non ho capito qualcosa?
Ho pensato :
posso usare una policy di default che ha una funzione vuota nel compress() , cosi non fa nulla se non la inserisco e non la voglio usare .

Ma è questo il modo di lavorare?
o sbaglio qualcosa?

grazie.

[giuseppe500]

ho pensato a un metodo per risolvere il problema:
la specializzazione parziale o completa:
nella specializzazione parziale o completa riscrivo la create in modo da utilizzare solo cio' che è necessario a seconda delle combinazioni di policy.
Il problema è che devo riscrivere parti del codice anche se, nel caso usi la specializzazione parziale risparmio un sacco di lavoro, mi sembra un metodo piuttosto pulito.

ciao.

[shodan]

Mi sa che non hai capito bene.
La classe managerTexture deve solo usare le class policies, non ereditare da loro altrimenti diventa essa stessa una classe policy, per non parlare di altri problemi esistenziali della classe stessa. Quando parlavo che puoi ereditare da una class policy, intendevo che puoi creare una nuova class policy da una esistente, non creare una classe derivata qualsiasi.

Inoltre quando erediti da una classe devi sempre chiederti: è un oppure ha un.
managerTexture è un TipoFiltro oppure ha un TipoFiltro? E' un Compressione oppure ha un Compressione? E' un Mipmap oppure ha un Mipmap?

inoltre in ogni policy per es di Compressione avro un algoritmo diverso , tipo lo strategy pattern della gof per intenderci, quindi lascierò al client la scelta dell algoritmo di compressione da usare , oppure permettero' di crearne uno personalizzato e cosi' per tutte le altre policy.

Che intendi con: lasciarlo al client? Scegliere l'algoritmo mentre in programma è in esecuzione?

se non voglio implementare nessun tipo di compressione , come posso fare? purtroppo non so se ho fatto un errore o meno ma il mio codice nella host class appare ed è piuttosto vincolante, sono io che non ho capito qualcosa?

Certo che il codice di una policy è vincolante, altrimenti non sarebbe una policy. Ma è vincolante solo in rapporto alla sua interfaccia non a quello che fa internamente.

posso usare una policy di default che ha una funzione vuota nel compress() , cosi non fa nulla se non la inserisco e non la voglio usare .
Ma è questo il modo di lavorare?

Si. Non è obbligatorio che la policy faccia sempre qualcosa. Se necessario può anche non fare nulla.