Newsgroup: it.comp.lang.c++
Titolo: interfacce e funzioni virtuali

Saluti.
Ho un'altro consiglio da chiedervi sempre riguardo quel
programma di cui mi sto occupando 
[messagio: dubbio su uso del polimorfismo].
Per come lo avevo sviluppato c'erano i Manager
che si occupavano di ricevere dei segnali ed i Receiver che
venivano invocati dai Manager tramite funzioni callback.
Per cercare di tenere tutto indipendente avevo deciso di
rendere i Receiver delle pure interfacce (ed i cui costruttori
si occupavano di registrarsi nel Manager opportuno).
Tuttavia uno dei responsabili del progetto (io faccio solo da
consulenza) ha detto che cosi' c'erano troppe indirezioni
ed ha deciso di togliere di mezzo i Receiver sostituendoli 
con le classi concrete che devono ricevere i vari segnali.
Quello che mi chiedo e' se vale veramente la pena fare una cosa
del genere. Che quadagno di prestazioni si ottiene?
C'e' da dire che non e' un grandissimo programma (la parte che ho
curato io saranno 5000 linee) ed il target e' un sistema embedded.
Avevo deciso di usare le interfacce perche' ero riuscito a separare
l'intero programma in unita' logiche ben separate.
Grazie  Manlio Perillo

 l'intero programma in unita' logiche ben separate.
E questo mi pare un obbiettivo desiderabile.
Ciao,
Nicola
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 curato io saranno 5000 linee) ed il target e' un sistema embedded.
che il tuo programma sia 5000 LOC o 500000 LOC, credo che il costo di una
chiamata a funzione virtuale sia identico :-). Scherzi a parte, avete
prova di un degrado delle performance o è una semplice premonizione del
tuo collega?
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Nulla del genere. Non credo nemmeno sappia cosa e' un profiler.
Ti diro' di piu'.
Ha deciso di cambiare quasi tutto.
Ora non hanno piu' i Manager, ma solo i vari Receiver i quali
si occupano di gestire il segnale.
Ossia, per spiegare meglio.
Come avevo fatto io c'erano i Manager che si occupavano solo
di vedere che tipo di segnale arrivava.
Una volta identificato chiamavano i metodi del ricevitore registrato.
Ora invece fanno tutto i Receiver.
Saluti e grazie  Manlio Perillo

 Ora invece fanno tutto i Receiver.
credo che sia una violazione del SRP (Single Responsibility Principle)
bella e buona! Diglielo! ;-)


 prestazioni tale da richiedere una revisione del design.
Non e' cosi. In assenza di ottimizzazioni una chiamata a funzione
virtuale comporta solo un accesso a memoria in piu' rispetto alla
chiamata ad una funzione non virtuale. Di per se e' sostanzialmente
trascurabile rispetto al costo di una normale chiamata di funzione. Il
problema e' che la chiamata virtuale impedisce al compilatore alcune
ottimizzazioni, prima fra tutte l'inlining. Resta il fatto che non ha
senso parlare di problemi prestazionali se non si sono fatte misure.


Nicola Musatti wrote:


Vero, comunque è da verificare se l'inlining di una funzione sia veramente
un'ottimizzazione. Ricordati che l'OP sta sviluppando su un sistema
embedded dove *probabilmente* la memoria a disposizione è limitata. 


 Ora invece fanno tutto i Receiver.
In realta' e' difficile commentare le tue scelte cosi' in astratto,
perche' l'effettiva bonta' dipende anche dai compiti effettivi delle
diverse classi e dalla complessita' che ne risulta.



Vaglielo a spiegare...
La persona che sta sviluppando il codice (e a cui ho fatto la consulenza)
non conosce quasi per niente il C++ ma un poco di C.
Il responsabile del progetto invece ha esperienza di programmazione ma ha
ammesso che ha poca esperienza con il C++.
Saluti  Manlio Perillo


Hai ragione, ma tanto ormai hanno fatto le loro scelte e quello che mi
da fastidio e che alla fine ho l'impressione che il loro disegno
non porti a prestazioni maggiori rispetto al mio.
Inoltre stanno creando un sacco di dipendenze e questa e' una di quelle
cose che ho cercato di eliminare.
Pensa che nel programma originale (a sua volta riscritto da una base C)
c'erano poche classi con decine (e piu') di metodi.
Addirittura una classe (con due sue derivate) occupava un file di 83 KB!
Ogni cosa dipendeva da un'altra e non si capiva chi faceva cosa.
Saluti  Manlio Perillo

 con le classi concrete che devono ricevere i vari segnali.
spesso e volentieri "indirezione" si sposa molto bene con 
"disaccopiamento", e mi pare che il tuo caso non faccia eccezione; la 
domanda da porti (e da porre al capoprogetto) IMHO e`: "vale la pena di 
progettare un sistema maggiormente accopiato?".
*Se* le prestazioni sono state misuare insoddisfacenti allora puo` valere 
la pena cambiare, altrimenti no.
"L'ottimizzazione prematura e` la radice di tutti i mali" - D. Knuth
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra