Newsgroup: it.comp.lang.c++
Titolo: virtual constructor

Non è un po' fastidioso che un costruttore non possa essere virtuale?
Stavo cercando di definire un'interfaccia tramite una "classe virtuale".
Kiuhnm

 Stavo cercando di definire un'interfaccia tramite una "classe virtuale".
come faresti funzionare un costruttore virtuale?
-- 
sbi

 come faresti funzionare un costruttore virtuale?
Vorrei solo che costringesse il compilatore a controllare la presenza di 
un determinato costruttore nelle classi derivate.
Sarebbe comodo (sebbene non indispensabile).
Kiuhnm

 come faresti funzionare un costruttore virtuale?
magari chiamando nell'ordine i costruttori delle classi base e poi
quello della classe derivata?           8^)
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Dept. of Physics, Univ. of Padova, Italy              ROT13: 
ybe...@cq.vasa.vg

 un determinato costruttore nelle classi derivate.
in _quale_ classe derivata?
non ti seguo..
  un esempio? un mezzo caso d'uso?
-- 
sbi

 quello della classe derivata?           8^)
mi sembra un'ottima idea :>
-- 
sbi

  un esempio? un mezzo caso d'uso?
Assumi di voler generalizzare completamente un'operazione in modo che 
possa operare su oggetti generici. Decidi di delegare buona parte delle 
operazioni a una classe di tipo ObjOp e ne stabilisci un'interfaccia per 
poterla utilizzare. Anziché limitarti a descriverne i requisiti, chiedi 
all'utente di usare ObjOp come classe base, offrendo così un ulteriore 
controllo. La classe utente verrà passata come argomento a un template. 
I template segnalano errori incomprensibili ai più quindi un controllo a 
priori potrebbe aiutare notevolmente.
Kiuhnm

 priori potrebbe aiutare notevolmente.
cioè volevi leggere questo?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1510.pdf
-- 
sbi

 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1510.pdf
No. Sono a conoscenza di questa "iniziativa", ma ho deciso di usare 
soltanto quello che è supportato "nativamente" ed ora dal C++.
Temo che il prossimo C++ sarà ancora più complicato di quello attuale. 
IMHO, i problemi del C++ non si risolvono aggiungendo feature, ma 
eliminandone le rigidità più gravi. I template per es. portano a una 
duplicazione del codice spesso immotivata e le funzioni virtuali hanno 
funzionalità limitate.
Il compile-time checking dovrebbe eliminare molti problemi a priori, ma 
in realtà rende il linguaggio estremamente complicato e introduce una 
vasta gamma di errori derivati. D'altra parte, il late-binding 
semplifica molti problemi rendendo la struttura del codice molto più 
semplice e permettendone il testing in run-time mediante test-unit 
mirate. I template andrebbero usati solo per ottenere la massima 
efficienza in determinati punti strategici. Per il resto sono veramente 
controproducenti, così come è controproducente dichiarare tutte le 
funzioni inline (specialmente disponendo di un compilatore troppo servile).
Kiuhnm

 [alcune_opinioni]
-- 
sbi

> [alcune_opinioni]
ROTFL.
Kiuhnm


Vero. Pensa quanti errori potrei eliminare!
Prima scrivo la classe base. Poi la compilo. Poi ispeziono il 
disassemblato e vedo se commetterò degli errori quando scriverò le 
classi derivate.
Dato che il codice della classe base non cambia e ho già la sua versione 
compilata, questa conterrà già tutto quello che servirà per richiamare i 
costruttori delle classi derivate.
Il fatto che non le ho ancora scritte è totalmente irrilevante: il file 
oggetto con il codice della classe base non dipende dai sorgenti delle 
classi derivate.

 un determinato costruttore nelle classi derivate.
Non puoi controllare nel construttore la presenza della funzione virtule
"Check"? Mi sembra che alla fine della fiera il risultato non cambi.

 "Check"? Mi sembra che alla fine della fiera il risultato non cambi.
Non ti seguo. L'intenzione è quella di controllare che sia stato 
implementato un determinato costruttore.
Non è un problema. Dato che non lo si può fare nativamente, non lo 
faccio. Complicare le cose aggiungendo altri meccanismi non mi porta 
vantaggi.
Kiuhnm

 implementato un determinato costruttore
Porta pazienza, seguo il NG nei ritagli di tempo. Il problema è che i
template danno di messaggi di errore incomprensibili, oppure vuoi
"veramente" che sia implementato un costruttore. Nel secondo caso cosa non
va bene nella clausola "explicit"?
+++
Immagino anche che i soliti trucchi non funzionino
template <typename T>
class Base
{
public:
	Base(int t){}
	Base(char t){}
private:
	Base(T t){}
};
template <typename T>
class FiglioDiBase: private Base
{
public:
	FiglioDiBase(T t):Base(t){};
}

 Immagino anche che i soliti trucchi non funzionino
Niente trucchi nei progetti grandi e complessi! Pochi riuscirebbero a 
mettere le mani nel mio codice.
Kiuhnm

 mettere le mani nel mio codice.
Sinceramente, qualcuno metterà mai mani sul tuo codice?
Problemi complessi necessitano di soluzioni complesse, ovvero nessuno fa
miracoli. Io sto lavorando in questo momento su codice altrui, molto
elegante e con molti template. Bestemmio. Semplicità "teorica" di design
che alla fine genera una complessa ramificazione di interdipendenze tra
classi templizzate. Non si capisce una mazza, e una piccola modifica di un
file header (i template si trovano ovviamente lì) porta a ricompilare mezzo
mondo.
Un tempo si abusava delle classi, poi dei template, poi dei pattern (io
vedo un abuso dei singleton sui progetti su cui metto le mani).
Bisognerebbe ridare dignità ad hack e trucchi vari :-)

 Bisognerebbe ridare dignità ad hack e trucchi vari :-)
Mai! :-)
Ciao,
Nicola

 Bisognerebbe ridare dignità ad hack e trucchi vari :-)
Ne ho visti fin troppi in asm.
Kiuhnm

 specifiche DLL
Preferisco le lib alle dll, comunque in questo caso c'è l'eterno problema
della versione, oltre a quella del programmatore impegnato a fare altro. 
A: "La tua DLL non funziona nel caso Y."
B: "Ma stai usando l'ultima versione?"
A: "Se la uso smette di funzionare nel caso Z."
B: "Non ho tempo di metterlo a posto."
A: "Dammi i sorgenti, ci metto una pezza."
Aka: la proliferazione delle versioni
++++
Se esistessero le pallottole d'argento il software lo scriverebbero gli
orefici, e non i programmtori.

 Aka: la proliferazione delle versioni
Non puo' succedere: da queste parti oltre al mio team non c'e' nessuno
che sviluppa in C++ ;-)
In ogni caso non c'e' soluzione tecnica che eviti il problema
dell'indisciplina dei programmatori.
Ciao,
Nicola

 dell'indisciplina dei programmatori.
Una revisione del codice penale basterebbe.
Kiuhnm


Hai idea di quante release passerebbero prima di vederla applicata?
Ciao,
Nicola

 Hai idea di quante release passerebbero prima di vederla applicata?
In questo caso la laziness potrebbe deporre a loro favore...
Kiuhnm

 dell'indisciplina dei programmatori.
Obbligare i primi 10 di vita lavorativa di un programmatore a lavorare su
codice altrui inculcherebbe nella testa di un mucchio di persone scrivere
pulito, semplice, e commentato. 
Purtroppo le stelle delle programmazione con cui ho a che fare non devono
maneggiare codice altrui, e sono più attratti dalle guerri di religione su
questo o quest' altro linguaggio, su questo o quest'altro pattern.
Poi però ci sarebbe il problema dei capi progetti, e di moltissimi clienti,
per cui il software è una baggianata che qualsiasi ragazzino neolaureato
può scrivere ad alto livello fin dal primo giorno. Anzi, spesso il software
è visto come una "comodity".
Più tempo passa, e più tendo ad usare il meno possibile le potenzialità del
C++. Non saprei dire un esempio pratico in cui mi è necessaria l'eredità
multipla, e ormai uso i template solo per scrivere algoritmi su tipi
generici, e mai per avere strutture dati generiche (cose tipo generalizzare
il tipo di output, che per quanto mi riguarda puo essere solo console, file
e socket).

 e socket).
Beh, come direbbe Woody Allen, te la prendi sempre coi miei passatempi
preferiti :-)
Ciao,
Nicola

 preferiti :-)
Semplicemente non sono un programmatore fuoriclasse, e conscio dei miei
limiti, mi limito. Con fatica devo dire, ho la cattiva abitudine a
generalizzare troppo, e a scrivere codice riusabile che non riuso alla
prova dei fatti.
Però devo dire che per quanto mi piaccia Python, faccio fatica ad
abbandonare il C++. Per direttive aziendale poi dovrei addirittura passare
al C# ovunque. Ormai faccio parte del piccolo gruppo di peleotici che tende
a NON usare il C# per una nutrita classe di problemi.