Newsgroup: it.comp.lang.c++
Titolo: distruttore virtuale...

ma un distruttore, oltre che virtuale, può essere astratto?
se la risposta è no, come mai
class Pippo {
    virtual Pippo() = 0;
    virtual ~Pippo() = 0;
}
al compilatore non dà fastidio, mentre al linker non piace il fatto che non
ci sia il simbolo.... (ma è virtuale, che lo cerchi a fare?!).
in realtà la situazione è la seguente...
class Pluto: public Pippo {
    Pluto();
    ~Pluto() {};
}
... non è che è implicito -e non evitabile- che venga invocato il
distruttore anche della classe superiore?
Rony.
--
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
"Solo due cose sono infinite,
l'universo e la stupidita' umana,
e non sono sicuro della prima."
Albert Einstein

distruttore anche della classe superiore?
Se con il costruttore è implicita una chiamata al costruttore delle
eventuali classi base dirette, o indirette, allora anche per il
distrittuore è sostanzialmente valido lo stesso discorso. Si potrebbe anche
risolvere il tutto definendo un distruttore nella mia classe derivata che
accede ai campi ereditati pubblici delle superclassi, ma sicuramente non
posso utilizzarlo per i membri private di una base.
Anche se non sono visibili alla classe derivata, gli oggetti private sono
ereditati come qualsiasi altro membro, anche se con le suddette
restrizioni.
Ciao.
 
 

distruttore anche della classe superiore?
Nota che una funzione "virtuale pura" puo' anche essere definita;
nel caso del distruttore *deve* essere definita.
La notazione "=0" non significa che non la definisco... ma che
chi deriva da questa classe e' obbligato a fare l'override.
La funzione "pure virtual" puo' esistere ed essere chiamata.
HTH
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 che non ci sia il simbolo.... (ma è virtuale, che lo cerchi a fare?!).
[...]
Il distruttore non e' un metodo come tutti gli altri.
Quando si invoca un metodo virtuale,  viene invocato solo nella
implementazione della classe effettiva (quindi l'implementazione nell'
eventuale classe base non e' indispensabile).
Per il distrutore (e il costruttore) invece vengono invocate in cascata
tutte le implementazioni della gerarchia.
Esempio:
class A { ... };
class B : A { ... };
class C : B { ... };
quando costruisci un'istanza della classe C vengono invocati,
nell'ordine A(), B() e C().
Quando questa viene distrutta, vengono invocati ~C(), ~B() e ~A().
Siccome potresti avere una cosa del genere:
A* a = new C;
delete a;
e' necessario che il ~A sia dichiarato virtuale. Per il costruttore
non c'e' bisogno (e non avrebbe senso) perche' con "new C" non ci sono
dubbi sulla classe che stiamo istanziando.
Ma con "delete a", se ~A non fosse virtuale, verrebbe invocato solo il
distruttore di A. Col distruttore virtuale invece viene chiamato ~C
quindi ~B e infine ~A.
Saluti,
/fabio
Sent via Deja.com
http://www.deja.com/

 wrote in message
94hvda$20h$2...@pisanino.unipi.it...


 linker) e poi non puoi istanziare oggetti della classe base.
Chiedo scusa... ma temo ancora di non avere capito... ma probabilmente
quanto non capisco è proprio una cosa banale di notazione. Mi spiego meglio:
Quanto all'opportunità di dichiarare virtuale un distruttore, non ci sono
problemi... anzi, mi domandavo quando avesse senso che fosse diversamente,
ma non importa...
Quelolo che mi chiedo è: che significato ha l'assegnamento a 0 di un metodo?
Non vuol dire dichiarare che non se ne darà implementazione?
Evidentemente no, visto che nessuno si è stupito come me del fatto che il
compilatore non segnalasse alcunché alla riga indicata...
    class Pippo {
        ...
        virtual ~Pippo(void) = 0;   // <- QUI!!!
    }
Lo Stroustrup è un po' sbrigativo a riguardo, e dice (§12.3, III edition)
che un metodo cui si assegna 0 è "pure virtual", e che una classe che lo
contiene è astratta etc. etc.
Per quanto mi riguarda, aldilà dello pseudoeleganza della notazione, ma se
questo assegnamento a zero ha effetto solo sulla classe e non sul metodo,
non avrebbe senso metterlo, che ne so, su di un metodo solo?
Il fatto che tale assegnamento si ripetesse su più membri di una stessa
classe mi suggeriva (e sbagliavo!) che si indicasse qualcosa di più, ovvero:
"questa classe è astratta, ergo non può essere istanziata; inoltre di questo
metodo le derivate dovranno dare un'implementazione, e questa non richiamerà
il metodo di questa classe base, perché non ha corpo".
In realtà ho notato che questo non è affatto vero, anche in altri casi!
Al compilatore questa cosa passa inosservata...!
In questo esempio:
    class Base {
        ...
        virtual const AnsiString Print() = 0;
    };
    class Derived: public Base {
        ...
        const AnsiString Print() { return Base::Print() + "cazpita!"; };
    };
il _compilatore_ non dà alcun errore!!!
Ovviamente, né potrebbe essere diversamente, il _linker_ resta un po' deluso
e si lamenta...
Analogamente se, da qualche parte, dichiaro
AnsiString Base::Print() {
    return "linkatemi!";
}
il _compilatore_ è bello contento...
A questo punto, veramente, mi domando a cosa serva quell'assegnamento
(sintattico) "= 0"?!


quindi ~B e infine ~A.
Questo non e' esatto. Secondo lo standard chiamare "delete" quando
il tipo statico non coincide con il tipo dinamico (il caso che
hai esemplificato tu) e la classe puntata ha un distruttore
non virtuale e' "undefined behaviour".
In tutte le implementazioni ho visto succedere la cosa piu' ovvia,
ovvero che viene chiamato solo il distruttore della classe base;
ma potrebbero esserci compilatori/ambienti/giornate in cui invece
fare una cosa simile ti provoca la fuoriuscita di una quindicina
di demoni maligni dalla narice destra.


 ma non importa...


 Thinking in c++ di bruce eckel, volume I.
Allora il fatto che il compilatore non dia alcun errore nel momento in cui
implemento il metodo o in cui lo richiamo in un metodo di una classe
derivata, devo interpretarlo come un errore? (vedi l'esempio con il metodo
print sul messaggio cui hai risposto!).
Riallego, per chiarezza...
#include <iostream>
class Base {
public:
  virtual void pippo() = 0;
};
class Derived: public Base {
public:
  void pippo();
};
void Base::pippo(void) {
  cout << "padre" << endl;
}
void Derived::pippo(void) {
  Base::pippo();
  cout << "figlio" << endl;
}
int main() {
  Base *a = new Derived;
  a->pippo();
}
Il compilatore (egcs-2.91.66) non dà alcun errore... e l'output
dell'esecuzione è:
padre
figlio
...!?
Mi sarei aspettato almeno due errori... alla riga in cui implemento
Base::pippo, e alla riga in cui invoco Base::pippo.
Commenti?!

 Thinking in c++ di bruce eckel, volume I.
Devo controllare "Thinking in C++", ma quello che stai dicendo
non e' corretto. Dire "=0" significa semplicemente informare
il compilatore che non e' permesso istanziare la classe e che
eventuali classi derivate devono fare l'override di tutte le
funzioni virtuali pure.
Le funzioni virtuali pure sono pero' assolutamente "normali" e
possono (se si vuole) essere richiamate:
  class X
  {
    public:
      virtual void f() = 0;
  };
  void X::f()
  { std::cout << "X::f()\n"; }
  class Y: public X
  {
    public:
      virtual void f()
      {
        std::cout << "Y::f()\n";
        X::f(); // richiama la virtuale pura
      }
  };
Nel caso del distruttore l'implementazione della base viene
sempre richiamata dal distruttore della derivata e quindi
*DEVE* essere implementata.
Onestamente ho sempre trovato la scelta di chiamare "virtuale
pura" una funzione membro di questo tipo discutibile, in
quanto questo nome si presta all'interpretazione che ne hai
dato tu (ovvero che non *possa* esistere una implementazione).
Andrea
--
----------------------------------------------------------------
 <\___/>  Andrea        email: agriff at tin dot it
 / . . \  "6502"          irc: _6502_@EFNET#italia
(  (")  ) Griffini   homepage: 
http://www.netservers.com/~agriff


 e questa non richiamerà il metodo di questa classe base, perché non ha corpo".
Questa parte non e' vera.
	Mauro

Non ho studiato lo standard ma, a occhio e croce, credo che quando
si dichiara un metodo virtuale puro, quello che effettivamente succede
e' che la virtual table per quella classe contiene 0 come indirizzo del
metodo incriminato.
Quando specifichi l'implementazione del metodo, significa che l'oggetto
generato contiene quel metodo, anche se la classe stessa non lo
referenzia nella sua vtable. Cosi' il linker non ha problemi a trovarlo
se viene invocato esplicitamente. Nelle stesso tempo la classe in
questione ha un'entry nulla nella vtable e non puo' essere istanziata.
Questa vuole essere soltanto una possibile spiegazione del perche' quel
programma funziona, credo che (alcuni) compilatori si comportino in
questo modo.
Ma non mi stupirei se invocando il metodo (puro) della classe base dalla
classe derivata si avesse un "undefined behaviour"... ;-)
fabio


Grazie a tutti, ora la cosa č chiara! :)


 "undefined behaviour"... ;-)
Il linguaggio lo permette e quindi con un compilatore conforme
su questo punto non ci dovrebbero essere problemi (se non e'
qualcosa che e' cambiato dal draft allo standard).
Andrea
--
----------------------------------------------------------------
 <\___/>  Andrea        email: agriff at tin dot it
 / . . \  "6502"          irc: _6502_@EFNET#italia
(  (")  ) Griffini   homepage: 
http://www.netservers.com/~agriff



Scusate se mi intrometto, ma non sapevo fosse
ammessa una sintassi come quella qui sopra: quando
è possibile usarla e quando no? Ha altri significati
oltre a costringere a fare l'override nelle classi
derivate?

nelle classi derivate?
L'effetto di "=0" e' di rendere la classe una
classe base astratta non istanziabile; sono
istanziabili le derivate se queste forniscono
una implementazione non virtuale pura di tutti
i metodi virtuali puri della base.
Se una classe derivata fornisce una propria
versione non virtuale pura di solo una parte
dei metodi virtuali puri della base allora
anche la classe derivata non e' istanziabile.


 wrote in message
3a6def57...@news.interbusiness.it...

ma a voi non è mai venuta la voglia perversa di scrivere un
compilatore c++ il cui unico scopo sia quello di individuare qualche
codice 'undefined behaviour' e fare danni su danni sulla macchina
dell'utilizzatore?
Credo di essere malato...

Credo di essere malato...
No. Ma piu' volte ho pensato che se mai dovessi scrivere un compilatore
C++ (cosa di cui dubito, mi e' bastato il mal di testa di quando ero 
alfa tester del symantec) cercherei di "trappare" tutti i casi di 
undefined behaviour che posso e li implementerei con un bel ERROR (se
possibile a compile time, altrimenti a run time).
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556
 
-- 
Posted from 
adsl-21-135.38-151.net24.it
 [151.38.135.21] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 possibile a compile time, altrimenti a run time).
Se puo' incoraggiarvi, le (ultime prima del rilascio finale) beta del
gcc 3 emettono un diagnostico per alcuni dei casi piu' banali (a[i] =
i++; i++*i++; ...); il fatto e' che non e' molto facile individuare
_tutti_ i casi di u.b. .
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it
The instructions said to use Windows 98 or better - so I installed FreeBSD.

 Credo di essere malato...
Danni su danni... diciamo scherzetti innocenti :-)
Ciao,
Nicola

 Credo di essere malato...
No, 6 in buona kompagnia dei programmatori Mikro$oft...
-- 
"Si vive una volta sola,
 tanto vale godersela."
BW2K+1

_tutti_ i casi di u.b. .
Uno degli articoli di "Effective C++ CD" descrive una analisi di
dettaglio di un gruppo di analizzatori di codice relativamente ad
una serie di errori potenziali "standard" in C++ (come avere classi
base con distruttore non virtuale oppure remote ownership senza
ridefinizione di assegnazione e costruttore copia).
Oltre a pacchetti specifici di analisi sono stati considerati anche
dei normali compilatori C++ (incluso gcc) e questi ultimi non hanno
fatto un granche' di figura nel segnalare (come warning) questi
costrutti che rappresentano rischi potenziali.
Quello di cui hai parlato tu sono pero' i casi in cui e' *certo*
che si vada ad incappare in un undefined behaviour...


 _tutti_ i casi di u.b. .
ma secondo te/voi, quando cominceremo a vedere dei compilatori che
siano completamente aderenti allo standard su piattaforma Windows?
Considerando che ormai contano di più l'interfaccia grafica ed i
wizard annessi, purtroppo penso che sarà molto lontano quel giorno.
Dico purtroppo perchè se anche volessi (e sto tentando) di impararmi
_IL_ C++, in realtà esso non mi sarà mai di alcun aiuto, perchè dovrò
sempre disimpararne alcune parti per venire incontro ai compilatori
che volente o nolente in ambiente lavorativo ti tocca utilizzare. Una
bella rottura di coglioni, io direi...

 siano completamente aderenti allo standard su piattaforma Windows?
Riguardo a prodotti commerciale, non e' che U*x sia messo meglio.
E riguardo open-source ... quei compilatori in genere funzionano
uguale su entrambe le piattaforme.
Per il QUANDO la risposta e' ovvia: appena qualcuno si prende la briga
di farlo.
Ovvero appena qualcuno considera l'assenza di un compilatore 100%
compliant un limite imprescindibile.
Se per te questo limite e' troppo ... limitante: parti da un
OpenSource e rendilo compliant.

giusto qualche segnalazione:
http://www.comeaucomputing.com/
 - Comeau e' uno dei compilatori piu'
aderenti allo standard, ma richiede un compilatore C. Esiste su win32 e
costa 50$.
http://www.gnu.org/software/gcc/gcc.html
 - gcc e' gia' piuttosto
conforme allo standard, e mi aspetto che la futura release 3.0 lo sia di
piu'.
http://www.borland.com/bcppbuilder/freecompiler/
 - bcc e'
ragionevolmente conforme, anche se ha dei buchi qua e la.
Di CodeWarrior della MetroWerks non conosco il grado di aderenza, anche
se so che ha i suoi adepti.
Ciao,
Nicola

siano completamente aderenti allo standard su piattaforma Windows?
Mai, finquando prevarranno le scelte commerciali a quelle di
principio.
--
Andrea Laforgia (ICQ 87230455)
http://www.geocities.com/AndreaLaforgia
"ci sono tre tipi di persone nel mondo : quelli che
 sono bravi in matematica e quelli che non lo sono."

 OpenSource e rendilo compliant.
fossi capace!
appena avrņ la vostra esperienza, forse mi ci metterņ... ;-)

 ragionevolmente conforme, anche se ha dei buchi qua e la.
quindi il Borland C++ Builder 5, visto che il bcc č il cuore del
sistema di sviluppo di casa Borland? In ufficio effettivamente mi
piacerebbe utilizzarlo, visto che c'č, ma mi dicono che č meglio fare
in VC6, perchč le DLL prodotte dal BCB non sono integrabili con quelle
di altri compilatori (quando non uso il Power++ :(( )

 preprocessore? curioso...
Mica tanto! Da quando B.Stroustrup inizio' i suoi ragionamenti su un
"C with classes" alla prima comparsa di un compilatore C++ che
generasse codice nativo sono passati una decina di anni. E per tutto
questo tempo i compilatori C++ erano tutti del tipo "C front" (che
incidentalmente e' il nome del primo, sviluppato da Stroustrup
stesso). E di "C front" come compilatore di riferimento si e' parlato
fino a ben oltre la meta' degli anni novanta!
--


 appena avrò la vostra esperienza, forse mi ci metterò... ;-)
Bastasse!
Secondo te perche nessuno di noi ci si e' messo?
Vuoi la mia opinione? Eccola:
Un compiltore richiede molti tool di supporto. Facciamo conto di
ignorare:
-) l'IDE, facciamo un tool a linea di comando
-) il debugger, non solo non lo scriviamo ma non generiamo neppure i
simboli di debug: solo il codice
-) il linker, non solo non lo scriviamo ma non generiamo neppure un
vero codice linkabile, il nostro compilatore genera "pseudo assembler"
o un qualche tipo di "p-code"
-) le librerie e il librarian, scriviamo semplicemente un compilatore
che genera il p-code di una transaltion unit, il resto e' poesia
-) l'ottimizzazione, chi se ne frega, per il momento ci basta che sia
generato codice (o meglio p-codice) corretto. Di quanto e' compatto o
veloce ce ne freghiamo
-) le prestazioni: chi se ne frega se per compilare 10 righe ci
impiega 10 minuti
A queste condizioni ti dico:
Se dovessi scrivere un compilatore C compliant, partendo da zero e
scrivendo direttamente in C++ senza usare tool di supporto (come uno
yacc o cose simili), credo che, lavorando da solo, in meno di un
mesetto potrei portare a termine il lavoro (progetto, codifica,
debugging e documentazione).
Se dovessi fare la stessa cosa per il C++ ... direi circa uno o ue
anni e probabilmente non sarebbe ancora al 100% compliant e avrebbe
parecchi bachi sparsi. Sempre ammesso che ci riuscirei!


 preprocessore? curioso...
In realta' e' un vero e proprio compilatore a quanto ho letto, non un
preprocessore. Credo sia nato con l'obbiettivo di poter programmare in
C++ su piattaforme dove era disponibile solo il C (ovvero praticamente
tutte :-).
Ciao,
Nicola

 fino a ben oltre la meta' degli anni novanta!
se č cosģ, sono perdonato, io fino alla meta degli anni novanta stavo
facendo la 3^ superiore e programmavo in Pascal! Scherzi a parte,
avevo gią letto da qualche parte del C front, di sfuggita, ma non mi
ero dato preoccupazione di cosa fosse. Al momento, quello che
sinceramente mi interessava era di imparare per bene il linguaggio
c++, che poi me lo compilasse un compilatore c++, c o assembly non mi
interessava particolarmente... cmq, una domanda personale, anche se
sono su un ng pubblico: tu da quanto ci sei dietro alla programmazione
in generale e c++ in particolare?

 tutte :-).
ma sul sito, che sono andato a vedere, dice espressamente che comeau
richiede la presenza di un compilatore C! Da questo, suppongo che il
codice c++ venga tradotto in codice c standard da dare in pasto al
compilatore c (ed č per questo che l'ho considerato _una sorta_ di
preprocessore). Altrimenti a cosa servirebbe il compilatore c?

 More info 
http://www.brainbench.com/transcript.jsp?pid=2522556
non riuscirò a fare un compilatore c++ decente? neanche provando a
scrivere un 'precompilatore' che genera codice c dal c++? che
peccato...

 peccato...
Se poi consideri che gli scores suddetti li ho ottenuti dopo 2 anni
che non vedo un riga di C++ neppure col binocolo e dopo quasi 4 anni
che non "leggo" il draft (o lo standard) ...
Comunque anche con un punteggio di 5 e highter than 100% of previous
takers in un test sulla conoscenza del C++, mica puoi scrivere un
compilatore.
Quella e' condizione necessaria ma non sufficiente.
Quello che ti serve veramente sono altre tecnologie. Linguaggi,
Automi, Sintassi e Semantica etc.
Andrea Ferro


 in generale e c++ in particolare?
hehe, sei comunque perdonabile. Ma non incolpevole ;-)
Dunque. Ho 34 anni. I primi "esperimenti" di "programmazione"
risalgono alla prima media. Non esistevano i PC. E infatti si trattava
di una calcolatrice "programmabile" della texas instruments (credo il
modello si chiamasse TI 59). Io non l'avevo ma avevo incontrato un
ragazzo che alora faceva l'universita' che la usava. E mi ero fatto
prestare il manuale. L'idea dei "comandi memorizzabili ed eseguibili
in un secondo tempo" mi aveva intrigato. Cosi' passavo ore a scrivere
programmini. Su carta. Mai provati. (chissa' quanti bachi!). Mi
appassionava il semplice "esercizio mentale". Non sapevo che stavo
programmando.
In terza media (se non ricordo male) avevo messo le mani su due cose:
un reference completo dell'assembler del 6510 e un paio di articoli
che accennavano al basic in forma didattica. Ti sembrera' assurdo ma
il basic mi sembrava astruso. Non capivo le stringhe e le variabili. E
tanto meno comandi come print e input. Non capivo il concetto di
schermo e di tastiera. (ricorda che non avevo mai visto nulla di manco
lontanamente simile ad un computer. Ancora praticamente non c'erano).
Pero' capivo perfettamente i concetti di locazione di memoria, bit e
byte, registri della CPU e via dicendo. Quindi "elevai" i miei
esercizi dal livello calcolatrice al livello Assembler. Ma per me non
esistevano ancora i concetti di input output. Per me: Mettevi in
memoria il programma direttamente in esadecimale. Mettevi dei valori
di partenza in alcune locazioni (sempre in hex). Lanciavi il
programma. Leggevi il risultato (in hex) nelle apposite locazioni.
Fine del discorso.
Dovetti attendere fino alla terza superiore (ovviamente ITIS
Informatica) per "vedere" un computer. A quel tempo c'erano i
nuovissimi IBM PC (prima ancora degli XT, per non parlare degli AT).
Terza superiore: anno di gioia! Imparai: assembler Z80, Basic
(BasicA), Pascal (IBM Pascal su PC con due floppy, no HD!), Fortran IV
(su HP 1000). E ovviamente: DOS (su IBM) e RTE IV (su HP 1000). Non
contento mi feci dare dal mio amico (quello della calcolatrice) il suo
ex testo universitario (era oramai laureato) di Lisp.
Ripetei l'anno perche' avevo meta' materie con l'8, e meta' con il 4.
Non sto a dirti quali!
Ti abbrevio il seguito:
Studio del disassemblato del "BIOS" del commodore 64: '85
Militare: '87
Inizio lavoro come magazziniere di un rivenditore Olivetti: '88
Studio del'assembler 8086: '88
Studio del disassemblato del BIOS di un PC (tipo XT): '88
Studio del'assembler 80286: '89
Acquisto il mio primo PC (classe AT con un 286): '89
Acquisto il compilatore C della MS e studio cel C: '89
Lascio il lavoro e mi propongo come programmatore C: '90
Compero un'implementazione e studio Smalltalk: '91
Usando la mini implementazione nello Smalltalk studio Prolog: '91
Leggo i primi testi che parlano di C++: '91
Compero Zorthech C++: '92
Inizio programmazione Windows in C: '92
... altre varie negli anni successivi fino a:
Studio formale dell'OO: '93-'94
Uso Professionale del C++ (pre ISO): '93-'94
... altre varie fra cui studio di assembler 80386 (anche PM) e poi
80486 etc.
Accesso al draft C++ e alfa-testing di un compilatore C++ quasi-ISO:
'96
Prime letture sui pattern: '96
Studio approfondito dei pattern: '97
... a seguire
Questo pero' non toglie che sappia cosa successe prima.
Se una "materia" che odio e' la storia, una che amo e' la storia della
tecnologia e della tecnica.
Per esempio, linguaggi a parte, se ti interessa come nascono i PC, le
CPU, la Apple, MS etc. e cosa facevano Jobs, Gates e altri negli anni
'60, vedi se riesci a recuperare il probabilmente introvabile ma
appassionantissimo "Fires in the Valley", in italiano "Silicon Valley,
la nascita di un mito". Scoprirai, fra l'altro, perche' HP avrebbe
potuto essere la piu' grande e potente societa' dei nostri tempi
(immaginati di mettere insieme Apple, IBM e MS). E perche' non lo e'.
E scoprirai perche' il primo oggetto che, in un certo senso, era un PC
(inteso come personal computer) si chiamava Altair (nome datogli
grazie a una bambina e tratto da un cartone animato). Etc. Etc.


Il giorno Sat, 3 Feb 2001 22:19:36 +0100, "Andrea Ferro" ha digitato 
quanto segue:
[...]
e tutta la biografia solo in mail, no?-)

preprocessore). Altrimenti a cosa servirebbe il compilatore c?
Non capisco di cosa ti stai scandalizzando. Un compilatore "normale"
traduce codice C++ in codice assembler che poi viene dato in pasto
ad un assemblatore (sono pochi i compilatori che generano direttamente
il codice macchina). La scelta di Comeau e' stata di usare come
linguaggio il C invece dell'assembler vista la sua portabilita'...
cosa c'e' di cosi' terribile ?
Al massimo sono le prestazioni del programma compilato che ne
potrebbero soffrire (sul perche' si potrebbe discutere a lungo) ...
ma nel caso dell'uso di C per compilare C++ l'aggravamento non
dovrebbe essere particolarmente pesante.


> e tutta la biografia solo in mail, no?-)
OOPs  <--- (pun intended)
Credevo di averlo fatto!
Scusate.


 hehe, sei comunque perdonabile. Ma non incolpevole ;-)
lo so, lo so... :c)
[mega snip su quello che ha fatto nella vita]
ancora non riesci a scrivere un compilatore c++? ahhh, anni buttati
via ;o)
dopo la battuta, non vado oltre perchè al ng potrebbe non interessare
i racconti personali. Scusate anzi per la domanda personale che ho
rivolto ad Andrea, non è stato educato e non si ripeterà.

 cosa c'e' di cosi' terribile ?
non mi sto affatto scandalizzando e non c'č niente di terribile :c), č
solo che ho capito male il post precedente di Nicola.

cosa del genere...
sei sicuro? non sono esperto in materia di licenze, ma questa mi
giunge nuova. Mi sembra un po' troppo limitante, anche considerando il
fatto che la GNU ha introdotto la LGPL per le librerie, in modo da
permettere anche la scrittura di codice proprietario.
Anto 
--
Antonio Cuni, 18 anni, studente
Brainbench Certification: 
Master C++: 4.44, higher than 97% of all previous test takers.
Visual Basic 5: 3.06, higher than 77% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688

Giusto per chiarezza, qui spiega come funziona:
http://www.comeaucomputing.com/faqs/genfaq.html#ccompiler
Ciao,
Nicola

 rivolto ad Andrea, non č stato educato e non si ripeterą.
Piu' che altro ho sbagliato io a risponderti in NG (tra l'altro pensavo di
averti risposto in e-mail!!)


cosa del genere...
Sei sicuro? Guarda che non mi pare sia vero.
Ciao.
--
Valerio "tutto questo mi ricorda un fumetto..." Benfante
cageka...@katamail.com
http://pc1amov.math.unipa.it/~bitter/
Rimuovete katamiati dalla mia e-mail se volete scrivermi.

 Sei sicuro? Guarda che non mi pare sia vero.
infatti non e' vero _per niente_ : il codice che non utilizza codice 
gpl _all'interno_ dei sorgenti, ma solo nelle librerie linkate, e' un 
caso previsto dalla LGPL, a cui vi rimando.

 Sei sicuro? Guarda che non mi pare sia vero.
dici? Il problema vero non č quello, il problema č che se dove lavoro
salto fuori con una frase del tipo "voglio utilizzare gcc 3.0 su linux
perchč compila conforme allo standard una cifra!" mi prendono per
pazzo e/o mi licenziano! Primo di tutto, scriviamo software per
windows, e poi non ci sono i wizard e, strano ma vero, se non si
sborsa un sacco di soldi per qualcosa 'ci deve essere la fregatura'.

 sborsa un sacco di soldi per qualcosa 'ci deve essere la fregatura'.
Tu affronta le prime due. Io ti risolvo la terza. Quanto sono disposti a
spendere per avere linux e il gcc ?
;-)


 ;-)
chiedo e poi ti faccio sapere  :o))