Newsgroup: it.comp.os.linux.development
Titolo: Imparare a programmare sotto linux.

Salve.
Non ho mai programmato ma ho intensione di iniziare e lo voglio fare
sotto linux visto che ormai da 3 anni uso al 98% solo  linux e diciamo
che me la cavo. Ora, secondo voi quale linguaggio iniziare ad usare.
PEnsate che sia una buona idea iniziare con kylix? ( a proposto . Ho
fatto la registrazione e pur avendo aspettato 24 ore , sono 36 ora, non
ancora ricevo il numero seriale. Possibile che ci vuole cosě tanto?)
Kylix usa il Pacal mi pare. Devo comprarmi un manuale di pascal?
Ho intenzione di creare applicazioni scientifiche che mi aiutano nella
professione di geologo quindi ci vuole un linguaggio adatto allo scopo.
Inoltre ho inizarto a masticare SQL e vorrei creare interfacce a
postgresql.
Che ne dite?
Ciao

 Che ne dite?
Secondo il mio (davvero modesto) parere se usi Linux devi Imparare a
programmare in C++, che e' il linguaggio nativo del SO ed inoltre il 99% dei
programmi e moduli per Linux sono in C/C++.
sotto Linux poi hai sempre il gcc o il g++ per programmare gia' da subito.
Kylix non lo conosco ma mi sembra (corregetemi se sbaglio) che sia derivato
dal Delfi ed inoltre usa L'illegale libreria QT.
Inoltre i compilatori C++ compilano olte al C++ :
C; Pascal; Assembler; SQL (precompilato tramite un collegatore).
Mi sembra quindi che faccia al caso tuo.
Se cerchi dei compilatori visuali (sono di coccio :-) mi hanno rimproverato
perche' non li chiamo IDE) esistono liberamente scaricabili senza attese:
anjuta.sourceforge.net
KDevelop
VDKBuilder
Spero di esserti stato utile.

> ed inoltre usa L'illegale libreria QT.
perché dici illegale?
a me questo, fra tutti i set, sembra il migliore (non so se Kylix 
lo usi, ma io parlo in generale), è disponibile per un bel po' di 
piattaforme e permette di raggiungere un numero altissimo di 
utenti, inoltre mi piace l'idea della Trolltech della doppia 
licenza (che, se non erro, è poi la stessa della Borland con 
Kylix)
ciao,
Marco Zanon [
http://www.marcozanon.com
]

 programmare in C++, che e' il linguaggio nativo del SO
Mica vero. Quello e` il C.
Ciao
 David
-- 
<d.santinoli presso mi. flashnet. it>

dal Delfi ed inoltre usa L'illegale libreria QT.
Ehm.. Delphi, e poi perche' illegale ?
-- 
The Follet

C; Pascal; Assembler; SQL (precompilato tramite un collegatore).
Certo, certo, come no. Il piolo tondo entra nel buco quadrato

programmare in C++, che e' il linguaggio nativo del SO
Linux e' scritto in C, come la maggior parte se non la totalita' del
software di sistema.
-- 
Cop(R)(C) la metodologia di programmazione del futuro! (forse)
http://spazioweb.inwind.it/cop

sotto linux 
Comincia con il Perl.


 Non ho mai programmato ma ho intensione di iniziare ...
un solo consiglio, per un po metti da parte i compilatori e leggiti un buon
libro sull'argomento; non so che tipo di basi tu abbia, ma se parti da zero
un buon libro di programmazione "generica" non può certo farti male; se poi
vuoi iniziare con il C++ (strada tutta in salita...) o in Java (un po
meglio, ma sempre dura) prova a fare un salto sul sito di Bruce Eckel e
scaricati i suoi due bei libri "Thinking in C++" oppure "Thinking in Java";
ah, naturalmente sono in inglese;
questi libri trattano l'argomento programmazione in maniera decisamente
generica, senza calarsi in alcuna situazione reale; per documentarti sulla
programmazione "concreta" sotto linux puoi leggerti anche "The Linux
Programmer's guide" (se segui la strada del C/C++);
oppure tieni presente il sito IBM 
http://www-106.ibm.com/developerworks/
dove potrai trovare un buon numero di tutorial sia per il C/C++ sia per Java
o per altri linguaggi;
per finire, se sei digiuno al 100% di programmazione ti sconsiglio di
iniziare con un RAD sul tipo di Kylix; il "punta e clicca" nelle mani di un
neofita e troppo spesso diseducativo; un minimo di basi di programmazione
"classica" è fondamentale;
se poi vuoi proprio partire da zero con kylix procurati almeno l'ottimo
libro di Marco Cantù su Delphi 5.... con gli opportuni "porting" (magari tra
un po ne scriverà uno anche per kylix)
ciao

postgresql.
per questo tipo di applicazioni conviene il C o il fortran 77 e 90 
(in f77 trovi la maggior parte del software in circolazione)
non sò cosa devi fare nello specifico ma nei linguaggi in parola
puoi trovare librerie già pronte per :
variogrammi, geostatistica, puoi "pilotare" GIS come GRASS etc etc
ciao
-- 
================================================================================
"...Unix, MS-DOS, and Windows NT (also known as the 
    Good, the Bad, and the Ugly)."                     (by Matt Welsh)

 Kylix usa il Pacal mi pare. Devo comprarmi un manuale di pascal?
Object Pascal, giusto qualche annetto luce avanti.  Con Kylix/Delphi
impari a programmare relativamente in fretta, anche senza esperienza
precedente, e alla semplicita` non sacrifichi la potenza, ovvero
difficilmente ti scontrerai contro limiti intrinseci del linguaggio
prima di diventare un guru.
Dal lato C++ la lancetta potrebbe sicuramente pendere se non altro per
via della quantita` sterminata di materiale disponibile.  Se decidi
per questo, c'e` un manuale assolutamente atipico ma secondo me ideale
su 
www.relisoft.com
, che bada a insegnare a programmare ancor prima
che a insegnare il linguaggio.
Se non hai esigenza assoluta di un linguaggio compilato, pero`, mi
permetto di dare il consiglio che do di solito: Ruby
(
www.ruby-lang.org
).  E' interpretato, con un orientamento ad oggetti
pulitissimo, molto immediato e molto veloce nello sviluppo, e con il
suo bel set di moduli di comunicazione ai database (cosa che comunque
hanno anche gli altri linguaggi scripting di grido).  Si e` guadagnato
molti affezionati anche dai mondi di Python e di Perl, il che mi pare
significativo.
Massimiliano

 senza pagare i 1500$ della licenza
Per la licenza di QT, utilizzando Delphi o Kylix, la nostra 
coscienza e' a posto.  Ci ha gia' pensato Borland, per noi,
a pagare il dovuto alla Trolltech.
-- 
Posted from  [80.105.34.80] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

> C; Pascal; Assembler; SQL (precompilato tramite un collegatore).
K:H> Certo, certo, come no. Il piolo tondo entra nel buco quadrato
Come per magilla il piolo tondo entra nel buco quadrato (il diametro è
minore o uguale al lato). La frase non è corretta ma sotto c'è del vero.
Il motore  base è quello del  gcc ma sopra ci  compili Pascal, FORTRAN
77, COBOL  (!!!). L'assembler è  gratis perché è l'ultimo  passo della
compilazione. Per l'embedded SQL si  tratta di usare o librerie oppure
precompilatori.
Nota: Col C++ rischi di brutto di avere codice più lento che col C....
-- 
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )

 Comincia con il Perl.
Bleagh!
Se uno vuole cominciare a fare cose subito, allora un linguaggio di
scripting piu` pulito e strutturato:
Tcl o Python
Se uno vuole imparare in maniera piu` approfondita:
C
Se uno vuole partecipare a un sistema specializzato per migliorare le
prospettative di creare sistemi eterogenici che potenziano il cliente
nel new economy blah blah blah blah blah:
Java
-- 
David N. Welton
   Consulting: 
http://www.dedasys.com/
Free Software: 
http://people.debian.org/~davidw/
   Apache Tcl: 
http://tcl.apache.org/
     Personal: 
http://www.efn.org/~davidw/

 "classica" è fondamentale;
C'e` caso e caso.  Anni fa ho provato tante volte a imparare in modo
``classico'', il C, l'E (su Amiga... qualcuno se lo ricorda?),
l'assembly.  Troppo tempo, prima di avere in mano risultati tangibili,
e l'interesse e` sempre scemato prima di concludere qualcosa.
Invece, dopo aver scoperto Delphi, dei risultati arrivarono subito e
tennero altissimo il mio entusiasmo e divertimento.  Approfondendo,
poi, arrivare ad argomenti di programmazione ``classica'' fu naturale,
e ora mi sento a mio agio anche fuori da un RAD IDE (anzi, di piu`).
Il punto e` che non sarei mai arrivato qui se non fossi partito da un
RAD.  Beninteso, ci sara` sempre qualcuno parte con una motivazione
piu` forte di quella che avevo io.  Ma mostrare il lato divertente
della programmazione prima di quello faticoso, penso sia una strategia
migliore che l'inverso. ;-)
Massimiliano

 Nota: Col C++ rischi di brutto di avere codice più lento che col C....
Chi l'ha detto ? 
Non e' affatto vero, anzi e' vero l'esatto contrario.  
Alex Vinokur ha pubblicato diverso tempo fa su 
comp.lang.c++.moderated un interessante confronto tra 
l'utilizzo della libreria standard C++ e libreria 
standard C e il C++ ne esce vincitore alla grande.
Tieni presente che il C++ viene progettato tenendo
presente le prestazioni che il codice dovra' avere 
(ci sono vincoli precisi per gli implementatori, da
parte dell'organismo internazionale sugli standard), 
mentre per il C non e' cosi'.



Infatti puoi Usare Kylix e far cio' che vuoi ma nessun programma derivato
funzionera' senza la versione di QT incorporata in Kylix e quelle nessuno le
puo' ridistribuire leggete la licenza.
L'unica cosa che potete fare e dire a tutti coloro che date i vostri
programmi di installare Kylix perche' funzionino senza violare la licenza di
QT. Tutto cio' a favore di Borland che avra' un controllo gratuito del
funzionamento di Kylix e degli sviluppatori di QT che aumenteranno le loro
entrate e clienti.
Usate Harmony e Gnome non fatevi fregare!
PS preoccupatevi invece delle nuove norme per il diritto d'autore che ci
daranno in pasto alla SIAE  :-(((


Scusatemi tanto a considero il C++ come l'evoluzione del C non come un
linguaggio separato.
Perdonatemi saro' piu' fiscale la prossima volta.

> Certo, certo, come no. Il piolo tondo entra nel buco quadrato
In questo caso il piolo tondo e' la tua conoscenza dei compilatori C++
leggiti un po' di manuali ne hai bisogno.

 mentre per il C non e' cosi'.
Inoltre se vai a cercare i dati sui siti delle universita' di Napoli e
Bologna dai confronti risulta sempre che i compilatori C++ sono piu'
efficiti dei corrispettivi C. Cio' non avveniva solo con i PRIMISSIMI
compilatori C++ oggi scomparsi (spero).


Ho letto su Linux&C. che l'internet virtual Machine e' diventata Open Source
e che adesso supporta anche C/C++
qualcuno me lo puo' confermare?
Grazie


Scusate ma lo avavo specificato.
Grazie Gian Uberto Lauri, almeno qualcuno qui conosce i compilatori C++

Java
E' bello vedere che hai fatto l'assunzione:
new economy cavolata -> Java cavolata
Non ti facevo cosi' arguto.

Nota: Col C++ rischi di brutto di avere codice più lento che col C....
E' un trade off con la manutenibilita' che puo' essere conveniente o
meno. 


"dinamicamente"
Onestamente non capisco che voglia dire "agire
dinamicamente", non ho mai visto un qualcosa che "agisce
staticamente".  Se me lo spieghi :)
-- 
The Follet

 C'e` caso e caso. .............
d'accordo, forse sono troppo integralista, o forse è solo che ho troppo a
che fare con "programmatori" dell'ultim'ora, cresciuti su piattforme RAD,
che l'unica cosa di concreto che riescono a fare è solo un gran casino;
ciao

QT. 
Spero che tu stia scherzando, se sviluppo del software
commerciale con Kylix, non devo costringere nessuno a
installare Kylix, se voglio distribuirlo.  Se fai, invece,
riferimento alla distribuzione del codice sorgente e' tutto
un altro discorso.
-- 
The Follet

linguaggio separato.
Infatti il C++ e' l'evoluzione del C, ma proprio per quello
e' un linguaggio separato.  Tieni anche presente che ci sono
diverse differenze tra quello che e' il subset C del C++ e
il linguaggio C stesso.
-- 
The Follet

leggiti un po' di manuali ne hai bisogno.
Ehm... vorrei ricordarti che scrivere:
"Inoltre i compilatori C++ compilano olte al C++ :
C; Pascal; Assembler; SQL (precompilato tramite un
collegatore)"
e' sbagliato.
Se stai parlando di gcc allora possiamo essere d'accordo, ma
allora non si tratta de "i compilatori C++".
-- 
The Follet

meno. 
Ma quale trade-off ? ohe' ? ragazzi ? ma stiamo scherzando ?
:)
-- 
The Follet


Ne sono pienamente consapevole ho commesso la leggerzza visto che la domanda
iniziale veniva da un neofita di generalizzare troppo le cose per esprimere
dei concetti che ritenevo basilari.
Ciao.

 --
Non scherzavo affatto, se usi la licenza commerciale paghi i diritti e tutto
e' OK, se usi la Open Source puoi fare cio' che vuoi ma non puoi dare le
librerie QT che servono a farli funzionare Quindi non usatele. Lo ripeto
Utilizzate Harmony e Gnome non fatevi fregare!
Se non mi credi sul sito 
www.gnu.org
 dovresti trovare maggiori informazioni
sull'ambiguita' di QT.
Ciao.


Oltre al gcc ho usato i compilatori Borland sotto Windows (errori di
gioventu') e lo facevano tutti, poi non so'.
Ciao.


Indicavo per dinamicamente le azioni che avvengono al tempo di esecuzione
con allocazioni in C++ dinamica appunto, scuste se sono poco chiaro oggi.
Ciao.

ed escono da grass. Lo conosci il Grass?
stò imparando ad usarlo per cui ne sò ancora poco. 
-- 
================================================================================
"...Unix, MS-DOS, and Windows NT (also known as the 
    Good, the Bad, and the Ugly)."                     (by Matt Welsh)

Ma quale trade-off ? ohe' ? ragazzi ? ma stiamo scherzando ?
No.

gioventu') e lo facevano tutti, poi non so'.
I compilatori C++ Borland sotto Windows NON compilano ne'
Pascal, ne' Fortran, ne' SQL Embedded, ne' Assembly.
-- 
The Follet

con allocazioni in C++ dinamica appunto, scuste se sono poco chiaro oggi.
Anche in questo, non vedo perche' C++ sarebbe piu' lento,
anzi.
-- 
The Follet

No.
Ribadisco: non c'e' motivo per ritenere il C++ piu' lento
del C, anzi e' esattamente vero il contrario nel 99% dei
casi.
-- 
The Follet

casi.
Mi rallegro che il binding dinamico sia piu' veloce di quello statico, e
che classe::getX sia piu' veloce di classe.x 


e che classe::getX sia piu' veloce di classe.x 
Certo, se usi i membri "inline", cosi' come va fatto.
-- 
The Follet


Perche' i vecchi (non gli attuali) non erano fatti per gestire strutture di
cui non conoscevano la dimensione e quindi in piu' tali compilatori creavano
eseguibili, che al tempo di esecuzione dovevano calcolarsela (appunto
calcoli in piu').
Questa spiegazione e' un po semplicistica, per concludere non erano
sufficientemente ottimizzati per tali operazini.
Ciao

 che l'unica cosa di concreto che riescono a fare è solo un gran casino;
No, non sei integralista.  Di quei programmatori mi limiterei a dire
che sulle piattaforme RAD ci sono nati, non che sono cresciuti. ;-)
Massimiliano

cui non conoscevano la dimensione
Senti, cerchiamo di intenderci, perche', senza offesa, mi
sembra che si stia dicendo una marea di idiozie: il C++ e'
un linguaggio che ha sempre gestito l'allocazione dinamica
delle strutture dati, perche' la gestisce, ancor prima, il
C, quindi, alla peggio, si scende alla velocita' del C.
Tieni anche presente che le chiamate a new/delete,
principalmente utilizzate per l'allocazione dinamica in C++
sono molto spesso implementate in termini di chiamate a
malloc/free (non sempre, ma spesso).
-- 
The Follet


Il Borland Builde 5.5 ed il bcc32 a riga di comando me lo hanno sempre
permesso, anche se chiamavo funzioni tipo ASM per intenderci per ottenere il
risultato.
Se poi ho ottenuto dei miracoli non so.
Ciao

risultato.
Quel compilatore possiede un built-in assembler, e' una cosa
diversa.  
-- 
The Follet


Per chiarezza di esposizione (oggi propio non mi riesce di farmi capire)
stavo dicendo che la lentezza non dipendeva dal C++ o dalle sue librerie ma
solo dai compilatori che generavano gli eseguibili.
Oggi avendo dei compilatori ottimizati (generano meno istuzioni assembler
dei vecchi dallo stesso codice) la differenza si vede, C++ nettamente piu'
veloce del C sul 99% dei casi.
FONTI: (non mi invento le cose)
Herbert Schildt  GUDA AL LINGUAGGIO C++ Mc Graw Hill
Carlo Savy DA C++ A UML Mc Graw Hill
siti delle facolta' di Ingegneria Informatica di Napoli e Bologna
Scusa se ho creato equivoci Ciao.

Herbert Schildt  GUDA AL LINGUAGGIO C++ Mc Graw Hill
Ecco scoperto l'arcano, Herbert Schildt e' famosissimo per
dire delle sciocchezze (vieni a trovarci su it.comp.lang.c
e/o it.comp.lang.c++ per ulteriori conferme, o visita la
sezione book reviews di 
www.accu.org
).
Ti consiglio vivamente di documentarti da altre fonti ;)
-- 
The Follet

 Non ti facevo cosi' arguto.
http://www.humorless.com/
Potrebbe essere di aiuto.
Good luck dude,
-- 
David N. Welton
   Consulting: 
http://www.dedasys.com/
Free Software: 
http://people.debian.org/~davidw/
   Apache Tcl: 
http://tcl.apache.org/
     Personal: 
http://www.efn.org/~davidw/

 Ti consiglio vivamente di documentarti da altre fonti ;)
Se e' cosi' verro volentieri e cerchero' altre fonti, grazie, spero di non
averti seccato troppo.
Ciao.

 via Mailgate.ORG Server - 
http://www.Mailgate.ORG
  ===========================
  Alex Vinokur
    mailto:
ale...@bigfoot.com
    mailto:
ale...@dr.com
 
http://up.to/alexvn
 
http://go.to/alexv_math
  ===========================

binding dinamico rispetto al binding statico.
E non dimentico nemmeno i vantaggi di un linguaggio con allocazioni
trasparenti, come Java. Quindi? Java e' piu' veloce del C?

 derivato dal Delfi ed inoltre usa L'illegale libreria QT.
le QT non sono illegali. Al piu' lo sarebbero le applicazioni che le 
usano assieme a codice GPL. Cmq il problema non si pone piu', dato che 
gia' da un po' di tempo le QT sono rilasciate anche sotto GPL.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 Nota: Col C++ rischi di brutto di avere codice più lento che col C....
 
falso. Con le dovute cautele il C++ puo' essere anche piu' efficiente. 
Se sostieni il contrario, fammi vedere dei test.


Quindi? Java e' piu' veloce del C?
Non si puo' confrontare Java con C, Java non e' un
linguaggio compilato.
-- 
The Follet

linguaggio compilato.
Dal newsgroup "it.comp.os.linux.development", abbiamo trasmesso
"Chiacchiere da Bar Sport con argomento: linguaggi di
programmazione". Rimanete sintonizzati per il prossimo spettacolo.

Scusami ora spigo cio' che volevo dire:
Per compilare ho sempre usato DEV che implementa il gcc.
Ho dovuto una volta consegnare dei porgrammi con le template compilati
secondo le direttive Borland.
Mi sono fatto prestare i compilatori (che ho usato per poco).
ho modificato quel poco che che bastava i miei sorgenti per eliminare gli
errori derivanti dalle template.
tutto funzionava e poi basta.
Se tu che li usi, mi dici che sono stato fortunato ci credo.
Volevo solo dire che usandoli non ho riscontrato (sottolineo solo ad occhio)
differenze di uso.
Ciao spero di essermi chiarito

programmazione". Rimanete sintonizzati per il prossimo spettacolo.
Senza offesa, ma le "chiacchiere" le spari fuori tu che, a
quanto pare, ne' conosci, ne' sai confrontare tra loro i
diversi linguaggi di programmazione.  Ti consiglio di
rilassarti maggiormente quando partecipi a queste
discussioni, da questi e da altri interventi intuisco che
non hai molta propensione al dialogo ;)
Si sta parlando di C++ e C e la velocita' di esecuzione e',
nel 99% delle volte, a favore del primo.  Che tu ne sia
convinto o meno, non e' che mi interessi molto, ma per il
bene di chi si avvicina a questi linguaggi di
programmazione, evita, in futuro, di esprimere punti di
vista fuorvianti.  Hai tirato fuori Java, che non c'entra
nulla con la discussione in corso, ma ti rispondo lo stesso:
Java e' un linguaggio ideato, lo sanno tutti meno che te,
perche' il codice prodotto sia portabile sotto diverse
piattaforme.  Per questo fine, Java non e' un linguaggio
compilato (dove per "compilato" si intende che il suo codice
sorgente e' in una forma direttamente eseguibile dalla
macchina), ma ha bisogno di una "macchina virtuale" che
esegua le istruzioni tradotte in byte-code.
L'overhead necessario al sistema per eseguire questo codice
ibrido a meta' tra codice sorgente e codice macchina, si
paga in termini di velocita' di esecuzione.
Se confronti due linguaggi, devi essere sicuro di porti in
una situazione di confronto leale, non puoi considerare un
linguaggio compilato ed uno interpretato.
Tra l'altro, io potrei considerare, a questo punto, un
compilatore COBOL e un interprete C.  Sono sicuro che il
codice prodotto dal primo risulterebbe piu' veloce, ma
questo non basta per dire che il COBOL e' piu' veloce del C.
Se poi consideri un compilatore Java, cioe' una particolare
estensione di una implementazione Java, che consenta di
ottenere del codice eseguibile in formato nativo, non c'e'
nessun motivo per non sospettare che esso possa essere piu'
veloce del corrispettivo C.  Il C non e', per definizione,
il linguaggio piu' veloce di tutti, dipende tutto da come
sono implementate le funzioni base.  La libreria standard
del C non e' progettata per avere delle prestazioni fisse,
mentre quelle del C++ si'.  In generale, non e' assurdo
pensare che un linguaggio OO possa quasi sempre essere piu'
veloce di uno non-OO.
-- 
The Follet


La questione e' che la Trolltech.che detiene i diritti ha dato agli
sviluppatori KDE e Borland i diritti di distribuire i loro prodotti sotto
GPL, ma questo lo puo' fare solo la Trolltech.(violare la propia licenza per
mestiere che spasso), non si puo redistribuire QT sotto GPL senza violare la
licenza di QT obbligandoti ad una licenza commerciale per non violare la GPL
(furbi loro) quindi siccome Kylix usa addirittura una versine di QT
incompatibile con quella di KDE (almeno fino ad ora) qualsiasi versione di
Kylix scegli sei obbligato ad una licenza commerciale. Questo per me e'
illegale ed amorare, mi rifiuto di avere un compilatore GPL che puo'
produrre solo software con licenze commerciali:
Spero di essere stato chiaro ed e' per questo che e' nata Harmony ed il
progetto Gnome,
Ciao.

"The Follet" Scusa la prossima volta staro' piu' attento alle fonti che
scelgo, Le altre le ho controllate e sono corrette ora devo solo dimenticare
quel maledetto manuale.
Ciao.

leggiti un po' di manuali ne hai bisogno.
Fammi vedere un compilatore C++ che compila il Pascal. Avanti.

 veloce del corrispettivo C.
Sě che c'č. I bounds checks sugli array, per esempio.
Ciao
 David
-- 
<d.santinoli presso mi. flashnet. it>

Sě che c'č. I bounds checks sugli array, per esempio.
...che forniscono un grado in piu' di sicurezza e a volte la
sicurezza del codice vale piu' della velocita'.
Comunque, ribadisco: non stiamo parlando di Java.
-- 
The Follet

Fammi vedere un compilatore C++ che compila il Pascal. Avanti.
Be', in realta', il C++ Builder lo fa :)
E' in grado, infatti, di compilare unit Delphi, comunque
ammetto che e' un caso a parte :)
-- 
The Follet

 fregare! 
Per carità. Gente che inizia i manuali tecnici con pistolotti sull'open 
source, su filosofie, ideologie e merda simile non merita alcun seguito, 
almeno non da me. Chi è che cerca di abbindolare chi?

per ottenere il risultato.
bcc32 nemmeno assembla gli asm inline, ti chiede tasm32 o un qualsiasi 
altro assembler esterno. Ritenta, ma attento che sei ad un centimetro da 
un tuffo nella merda

 almeno non da me. Chi č che cerca di abbindolare chi?
Posso essere d'accordo che un manuale tecnico non deva iniziare con
discussioni filosofiche, ma se sei su questo newsgroup significa che la
"merda" la stai usando.
Non ti pare di aver esagerato o di essere nel newsgroup sbagliato?

un tuffo nella merda
Ma non ti sembra di esagerare un po' ? :)
Ho notato che c'e' un bel po' di scorbuticita' sui ng
dedicati a Linux, sara' l'effetto che fa sto sistema
operativo ? :)
-- 
The Follet

source, su filosofie, ideologie e merda simile 
Be', io l'Open Source non lo definirei "merda", anche
perche' e' cio' che ti consente, oggi, di stare qui dentro a
parlare di programmazione sotto Linux.
-- 
The Follet

 > Sě che c'č. I bounds checks sugli array, per esempio.
Ciao


Come no? L'hai tirato in ballo tu
Ti invito a rileggere il thread.
Java non l'ho tirato fuori io.
-- 
The Follet

una situazione di confronto leale, 
Pure se si confrontano due opinioni, e continuare con te no, non sarebbe
leale. 

 
Ciao

thef...@libero.it
 (The Follet) writes:

@ashland [~/tmp] $ cat HelloWorld.java 
class HelloWorld {
    public static void main(String[] args) {    
        System.out.println("Hello World!");     
    }
}
@ashland [~/tmp] $ gcj-3.0 -o HelloWorld --main=HelloWorld HelloWorld.java 
@ashland [~/tmp] $ ./HelloWorld 
Hello World!
@ashland [~/tmp] $ file HelloWorld
HelloWorld: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked (uses shared libs), not stripped


 e che classe::getX sia piu' veloce di classe.x
il binding dinamico e' una caratteristica che puo' essere usata o meno. 
Puoi benissimo scrivere un programma in C++ senza usare il binding 
dinamico, e tale programma sara' veloce almeno quanto l'equivalente C.
Inoltre, tu fai, implicitamente, questo ragionamento:
"Il binding dinamico e' piu' lento di quello statico, quindi un 
programma che lo usa deve essere per forza piu' lento di un programma 
equivalente che non lo usa".
Non e' detto che questa affermazione sia vera: per creare un programma 
equivalente occorre simulare, in un qualche modo, il meccanismo delle 
funzioni virtuali; e non e' detto che questo modo di simularle sia per 
forza piu' veloce di quello adottato dal compilatore C++ per 
implementare le funzioni virtuali.


 nel 99% delle volte, a favore del primo. 
Mah, al 99% mi sembra un po' esagerato. Io direi un 50%/50%; ma molto 
dipende da chi lo scrive.

implementare le funzioni virtuali.
Il metodo adottato dal kernel di Linux (per dire un pezzo di codice noto
a tutti) lo e' (union i cui elementi sono puntatori alle funzioni, uno
solo inizializzato a seconda del tipo dell'oggetto che possiede
quell'union). 
-- 
Cop(R)(C) la metodologia di programmazione del futuro! (forse)
http://spazioweb.inwind.it/cop

possimao passare alle email private. Vedi tu.
bah visto cosa sta capitando forse è meglio:)))
la mia mail è redbear presso tin punto it ;)
ciao
-- 
================================================================================
"...Unix, MS-DOS, and Windows NT (also known as the 
    Good, the Bad, and the Ugly)."                     (by Matt Welsh)

Non ti pare di aver esagerato o di essere nel newsgroup sbagliato?
Sbagliato? certo, se per sbagliato intendi "qui sei nella minoranza più 
assoluta, anche i sassi qui sono sotto GPL". Quanto ad esagerare, sì, 
esagero spesso

operativo ? :)
Non è il mio caso. Io sono su Windows 2000, e mi sto vedendo la terra 
sparire da sotto i piedi. Sono qui per respirare l'aria della terra in 
cui prima o poi mi esilierò, e non mi piace per niente

ammetto che e' un caso a parte :)
Ma solo perchè la VCL è scritta in Delphi. E perchè Builder è la VCL 
incollata sul C++. Ad esempio il compilatore senza extra di Borland 
nemmeno ha vcl.h, figurarsi il compilatore Delphi. Al massimo quello che 
farà Builder, poi, è usare qualche makefile, quindi si tratta di 
caratteristiche dell'ambiente di sviluppo o di make, non del compilatore

 cui prima o poi mi esilierò, e non mi piace per niente
Se permetti, sono problemi tuoi, non mi sembra il caso di insultare 
chi, al contrario di te, crede in certe cose (vedi post su "merda 
filosofica").
Se non ti piace, resta ancorato a m$, nessuno ti obbliga a passare qui, 
e anche fossi obbligato, non mi sembra corretto il tuo modo di fare, 
tanto piu' che ci rimetti in voglia di darti una mano.

 rispetto al Pascal.
un programmatore dovrebbe essere abbastanza elastico da riuscire a 
passare con naturalezza da un linguaggio all'altro senza troppo sforzo. 
Utilizzare sempre lo stesso linguaggio per tutti i corsi e', da questo 
punto di vista, controproducente.


 Non è il mio caso. Io sono su Windows 2000
[...]
?? E allora come mai usi Xnews per postare ??
-- 
Bye.
Cisco.

"Cisco" ha scritto:

c'e' un prog per win che ha questo nome. Non c'entra nulla con X

il progetto Gnome,
Non sei stato chiaro, e non ne hai azzeccata una. Il vero punto della 
questione, che sembra sfuggirti completamente, è che le librerie di 
Gnome sono sotto LGPL

talmente scorretto che i professori meriterebbero di essere gambizzati.
Drammaticamente vero, purtroppo. (Almeno, cosi' e' a Ing. Informatica
a Pisa.)
Avrei preferito 1000 volte che spiegassero il C un po' piu'
compiutamente piuttosto che del contentino di C++ che ci hanno dato.
+++
Pur preparato da mesi e mesi di lurkaggio di iclc++, poi, quando ho
preso il Lippman e' stato un tuffo al cuore... :)

 e KDE ne è la pluriennale dimostrazione
Certo che possono - se no, che azienda sarebbe?


 Gnome sono sotto LGPL.
Infatti il punto e' propio questo le librerie devono andare sotto la LGPL.
se rileggi il manifesto dell'Open Souce capirai perche' ed tutte le mie
argomentazioni.
www.gnu.org
Magari dopo capirai che il mondo Linux non fa per te e ritornerai felice da
Windows.
Ciao

 felice da Windows.
o BSD o MacOSX...


 dire delle sciocchezze (vieni a trovarci su it.comp.lang.c
ROTFL :)))
(certo che questo schildt dev'essere terribile, non ho mai sentito
una sola persona parlarne bene :))
-- 
addio, e grazie per tutto il pesce

 possiede quell'union).
hai fatto dei test?
Cmq, visto che parliamo di prestazioni, ecco qualche test (che non ho 
fatto io. Questi dati sono presi da "Programmazione nella pratica", di 
Kernghan e Pike):
Catena di Markov:
ecco un test che confronta i tempi di esecuzione di programmi che 
eseguono la catena di Markov su un testo di 42.685 parole:
Linguaggio      Tempo di esecuzione     Linee di codice
C               0.3 secondi             150
C++             1.5 secondi             70
Parsing di file CSV:
"A seconda del compilatore la versione C++ e' dal 40% a quattro volte 
piu' veloce della versione C su grandi file di input di 30.000 linee 
con circa 25 campi per linea. Il codice C++ e' circa il 20% piu' corto"
Sempre nello stesso libro c'era un altro test da cui usciva vincitore 
il C++, ma non riesco piu' a trovare il riferimento. Cmq, come puoi 
vedere, non e' affatto vero che il C++ e' piu' lento del C; anzi, nei 
progetti un po' piu' complessi (come quello del CSV) esso mostra tutte 
le sue potenzialita'.


 o BSD o MacOSX...
Non e' Linux ma e' gia' un piccolissimo miglioramento.
Ciao.


Non stavamo parlando di prograamatori ma di sintassi dei linguaggi, prendo
per esempio un ciclo contatore (for).
Pascal:
For J:="inizializzazione" to "varibile numero ripetizioni" do
    begin
     " Espressine da eseguire + incremento variabile"
    end;
C++:
for ("inizializzazione";"controllo del Ciclo";"incremento")
{
    "Espressione da eseguire"
};
Mi sembra piu' chiaro e di immediato utilizzo quello del C++ oltre ad essere
piu' versatile, poiche' si puo' smettere di contare con un espressione oltre
che per l'incremento di una variabile.
Poi potremmo discutere in eterno sull'argomento, ma credo che tu sia
affezionato al Pascal per curiosita' solo per quello hai imparato a
programmare con quello?
Ciao da B1

 desiderio di conoscere qualcosa di diverso.
Fermati un attimo a leggere le url sotto.  Non posso credere che li
hai visti e poi dici queste cose.  Il mio lavoro di consulenza si basa
sul software liberro, faccio parte dell'Apache Software Foundation (un
gruppo solo ad invito), e da diversi anni faccio il maintainer Debian.
Tutto sommato, sono a favore del software libero, e ho cercato di fare
la mia parte per migliorarlo e difonderlo:-)
Ciao,



Scusa ma da quello che scrivi non si capiva, forse i miei commenti un po'
radicali sull'uso ibrido del softwere Open Sorce mi hanno reso antipatico ai
tuoi occhi ma il fatto e che credo sia enormemente piu' vantagiosa il
diffondersi di Gnome e dei progetti similari che un proliferare di licenze
quasi Open Source.
Scusa ma Debian non si tiene lontano da KDE per via di QT? o sono rimasto
troppo indietro? e un po' che non la uso.
Scusa allora pensavo fossi contro.
Ciao.

 Scusa allora pensavo fossi contro.
Io ho fatto notare l'URL sul sito dell'FSF in risposta a qualcuno che
diceva che bisognava usare la LGPL per le librerie.  Non e` sempre il
caso.  Io personalmente credo che sia meglio, ma il business di Troll
Tech e` piu` che compatibile con il software libero in questo caso -
visto che il codice e` disponibile sotto la GPL.


fare, tanto piu' che ci rimetti in voglia di darti una mano.
In tutta franchezza:
 - non ritengo di essere io quello in debito. Sparare a zero su Windows
   è fin troppo facile, anche senza alcuna argomentazione, mentre pur
   con fatti alla mano Linux "non si tocca". Il programma X non fa
   schifo, semplicemente "non è per utonti, torna a uindous". Il
   programma Y non crasha, è colpa tua che "non hai ottimizzato il
   kernel per l'uso che devi fare del sistema". Il programma Z non è
   incompleto, se basta al 60% degli utenti significa che è completo;
   "ma il programma W, su Windows, lo faceva": "e allora tornatene a
   Windows", oppure "ma figurati quante persone usavano quella funzione,
   che pretendi?", o "è gratis, non ti basta?". Comincio a capire cosa
   intendeva GdG
 - me ne sbatto di Microsoft. IBM non sarebbe stata meglio. Ma nessuno
   dei due tira fuori la religione o la filosofia, da nessuna parte.
   Perchè, in fondo, non c'entrano un cazzo
 - la mia è una critica, accettala per quello che è, fanne quello che
   vuoi, libero di essere in disaccordo, ma non puoi (potete)
   rispondermi "non dovresti dirlo in questo newsgroup, rischi il
   linciaggio, noi ci accontentiamo e faresti bene a farlo anche tu"

o BSD o MacOSX...
E' quello che sto aspettando che il nostro amico B1 capisca. 
Evidentemente l'indottrinamento ha già fatto effetto


Che non sia "sempre" conveniente lo credo anch'io ma in linia di principio
non si puo' dire che non e' corretto da usare.
Credo che tutto il casino successo qui sia dovuto al fatto che ho
"arronzato" la mia prima risposta per farmi capire da un novizio + dati non
esatti presi da un manuale (vedi piu' in alto).
Comunque in questo NG saro' piu' specifico in futuro sperando di non essere
nuovamente assalito ;-))
Ciao

  ti basta?". Comincio a capire cosa intendeva GdG
Ok, ma critiche come "fa schifo" sono poco utili*.  Fai la figura di
uno che non ha molto da dire, o che, peggio, vuole solo provocare
visto che e`, alla fine, un newsgroup che esiste per chi vuole
sviluppare sotto Linux.  Insomma, siamo persone abbastanza
autosufficienti, e uno che arriva, si lamenta e non fornisce neanche
critiche che possono servire per migliorare le cose non fa una bella
figura.
Uffa, basta... torno ad hackerare, questo newsgroup e` uno spreco di
tempo...
-- 
David N. Welton
   Consulting: 
http://www.dedasys.com/
Free Software: 
http://people.debian.org/~davidw/
   Apache Tcl: 
http://tcl.apache.org/
     Personal: 
http://www.efn.org/~davidw/
* Con l'eccezzione di autoconf e automake, quelli fanno veramente
  cagare per un'infinita` di motivi.

 Evidentemente l'indottrinamento ha già fatto effetto
Windows non mi piace e non vi tornero' perche' con i casini che crea non mi
permette aggiustamenti.
poi la frase non e' chiara spiegati.
Ciao.

hai fatto dei test?
Venghino siorri venghino, un nuovo talento che spieghera' non a me, ma
agli sviluppatori del kernel, perche' dovrebbero usare il C++. 
-- 
Cop(R)(C) la metodologia di programmazione del futuro! (forse)
http://spazioweb.inwind.it/cop

felice da Windows.
Decisamente non fa per me, se i cervelli con cui si deve trattare sono 
tutti tarati in questa maniera. Come diceva quel famoso, "del Paradiso 
preferisco il clima, dell'Inferno la compagnia"

 In tutta franchezza:
in tutta franchezza, hai gli stessi preconcetti che dici di detestare.
Non tutti quelli che usano linux la pensano come dici tu, ma di sicuro 
se segui i flames, potrebbe sembrare.
Un buon uso del killfile ti darebbe una mano a discernere, cosi' come 
una maggiore obiettivita'

 merita attenzione? Tutto ciò mi sembra *ridicolo*
Si`, mache in questo caso, quello sempre coerente e` Stallman.  Anzi,
lo e` quasi sempre, anche se uno non e` d'accordo.
Sbagli su un altro punto.  GNU non e` contro il software comerciale -
anzi, vendono anche loro il software.  Loro sono contro il software
propretario.


 agli sviluppatori del kernel, perche' dovrebbero usare il C++.
eheheh pensa quegli idioti della Be che invece il kernel ce l'hanno 
fatto veramente...
uno spasso , sai?

uno spasso , sai?
Come comico non sei un granche'.


 Infatti il punto e' propio questo le librerie devono andare sotto la LGPL.
devono? Se vuoi che le tue librerie siano utilizzabili da chiunque,
le rilasci sotto LGPL, se vuoi che siano utilizzabili solo da
programmi GPL, le rilasci sotto GPL. Tant'e' che quelli di gnu
incoraggiano a rilasciare librerie specifiche (non quelle general
purpose tipo la libC, per intenderci) sotto GPL, proprio per
promuovere lo sviluppo di sw free. 
Non "devi" fare nulla, ognuno e' libero di scegliere la licenza che
piu' gli aggrada per il proprio software :)
-- 
addio, e grazie per tutto il pesce

agli sviluppatori del kernel, perche' dovrebbero usare il C++. 
Non che me ne freghi poi cosi' tanto di questo thread, ma Linus non ha
usato il C++ per il kernel semplicemente perche' all'epoca non era poi
cosi' un granche' (no standard - approvato nel 1998, compilatori non
performanti, ecc.). E adesso, riscrivere tutto...
Si parla adesso (2001!) di compilatori performanti, standard, ecc.
[Anzi, c'e' stato un tentativo, uno dei kernel 0.99, ma non ha avuto
un seguito, visti i risultati]
-- 
+---- | Un OS per domarli, Un OS per trovarli,             |  -o)
+---+ | Un OS per ghermirli e nel buio incatenarli         |  /\\
 O  | | Nella terra di Redmond, ove l'ombra cupa scende... | _\_V
                    raffaele punto salmaso presso libero punto it

che per l'incremento di una variabile.
Generalmente il C++ ha molti pregi, ma non quello della
leggibilita'/chiarezza (almeno nella mia _ridotta_ esperienza)
In questo specifico caso, il Pascal e' piu' vicino al parlato, e
quindi per un newbie (su campo di utilizzo) dovrebbe risultare piu'
facile.
[f/up su it.comp.programmare]

 Come comico non sei un granche'.
gia', alla pari con la tua informazione sul beos e sul C++ 

un JFS nativo... che perfomance pessime doveva avere...
Non vedo perche' continuare questa discussione, non fa per te e io non
ho tempo da perdere. Leggiti la mailing list del kernel, quando si parla
di usare C++, forse imparerai qualcosa.


 parla di usare C++, forse imparerai qualcosa.
e tu leggi 
www.be.com
, che ti fai una cultura, e la pagina di vinokur 
su C e C++ a confronto
http://alexvn.freeservers.com/s1/alexvn.html#label_Performance

  cagare per un'infinita` di motivi.
Dimmi, dimmi che questa mi suona nuova. Io credevo lo usassero e 
piacesse a tutti :)
A me personalmente piace il concetto che c'è dietro, ma il fatto che per 
"multipiattaforma" intendono unicamente "altri Unix" è sconfortante 
(questo significa anche che non l'ho mai usato :)
Ad esempio per quale balorda ragione questo programma:
http://conic.sourceforge.net/
(fico, vero?)
dovrebbe funzionare solo su Unix? oltre per il fatto che autoconf non 
supporta altri sistemi operativi? in fondo è solo un programma che fa un 
po' di matematica

espressione oltre che per l'incremento di una variabile.
Non considerando il C++, che non conosco, il Pascal in più del C ha:
Strutture dati:
 - set
 - range
 - indicizzazione degli array tramite enum o range
 - stringhe
 - un vero tipo Boolean
Sintassi:
 - namespace
 - parola chiave uses
 - sezioni di inizializzazione e finalizzazione dei moduli
 - funzioni "nidificate"
 - chiarezza:
    - nessun riciclaggio di operatori ("*" in C ha almeno quattro
      diversi significati)
    - meno livelli di precedenza degli operatori
    - l'operatore "=" è quello che sembra
    - di un typecast si capisce molto meglio dove finisce l'espressione
      da convertire
Istruzioni:
 - New e Dispose
 - Length e SetLength
 - Copy
 - High e Low
 - Succ e Pred
Questo escludendo le funzioni di libreria, perchè sarebbe un confronto 
inutile (dal momento che Pascal può tranquillamente usare qualsiasi 
funzione C, anche quelle che usano le "ellissi", cioè i ... alla fine 
della lista di argomenti), ed escludendo estensioni troppo specifiche o 
troppo recenti

ma di sicuro se segui i flames, potrebbe sembrare.
Non posso farne a meno, sono i thread più seguiti...

propretario.
La GPL, non la FSF. Alla FSF interessa solo il successo: sparano a zero 
su qualsiasi altra licenza (anche su quelle apertamente contro il 
software proprietario), si atteggiano a portavoce dell'intero mondo 
dell'open source, diffondono (non ufficialmente) credenze e leggende 
fuorvianti, in generale fanno un sacco di casino e mancano di umiltà 
(chi ha mai sentito gli sviluppatori di BSD pontificare, lamentarsi, 
lanciare proclami e anatemi?)
Vedi la pubblicizzazione esasperata di Debian come "distribuzione più 
sicura": è falso, la più sicura (o meglio: quella pensata esclusivamente 
ed esplicitamente come distribuzione sicura) è la Trustix (scommetto che 
non la conoscevi, nevvero?), in cui software e kernel vengono scelti 
unicamente in base a rigidi parametri di stabilità e sicurezza (in 
Trustix ad esempio non troverai sendmail, ma qmail. E non troverai il 
supporto per schede di rete su slot PCI, perchè è instabile). La sola 
particolarità di Debian è di essere l'unica distribuzione GNU/Linux pura
Cos'ha di buono la FSF? un esercito di avvocati. Loro non sono i 
migliori, sono solo i più forti

 piacesse a tutti :)
Non mi piacciono - sono veramente degli accrocchi allucinanti secondo
me.  Mescolare shell, m4 e perl non porta a buone cose, insomma.
Purtroppo, al momento non conosco alternativi migliori.


 migliori, sono solo i più forti
Hanno *un* avvocato, Eben Moglen, che e` anche molto bravo.
E poi se non hai notato, hanno contribuito davverto tantissimo
software alla comunita`.
Capisco un po' le tue impressioni di certi argomenti, ma stai dicendo
tante cose false.


 particolarità di Debian è di essere l'unica distribuzione GNU/Linux pura
A dire il vero non ho mai sentito "voci FSF" parlare di Debian come
distribuzione sicura (tra l'altro, a mio avviso, lo è), ma solo come
distribuzione più vicina agli ideali del progetto GNU.
ciao,
nico

 programmare con quello?
Un po' di punteggiatura non farebbe male. Cmq, agli inizi avevo 
imparato un poco di Pascal leggendo un libro di mia sorella, ma l'avevo 
lasciato perdere perche' non avevo nessun compilatore. Quando ho 
iniziato la scuola (liceo scientifico PNI) l'ho ripreso e l'ho imparato 
come si deve.
Inoltre, io *non* ho imparato a programmare con il Pascal; ho imparato 
con gw-basic prima e qbasic poi, ma per l'esperienza che mi sono fatto 
(tra basic, pascal, c e c++) IMHO il Pascal e' il piu' elegante.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 agli sviluppatori del kernel, perche' dovrebbero usare il C++.
 
1) non sono un nuovo talento.
2) non vedo il perche' fare dell'ironia che dovrebbe risultare 
"tagliente". Non agevola certo la discussione.
3) non ho mai detto "sviluppiamo il kernel in C++"
Cmq, ci sono ottimi motivi per sviluppare il kernel in C++:
1) il C++ supporta nativamente il paradigma OO. Come e' noto i maggiori 
benefici di un approccio OO si hanno in termini di manutenibilita' ed 
estendibilita': in pratica, se si prevede che un software debba vivere 
a lungo ed essere esteso (e il kernel e' senza dubbio in questa 
categoria) i benefici di un approccio OO superano di gran lunga i 
difetti dello stesso.
1.5) In ogni caso, il C++ non costringe ad usare un approccio OO. Se 
gli sviluppatori lo ritengono opportuno possono continuare a 
programmare in modo procedurale proprio come quando scrivono codice C. 
Anche in questo caso pero' possono usufruire dei vantaggi che il C++ 
offre rispetto al C.
2) Il C++ offre dei comodi meccanismi per agevolare la programmazione 
"in the large", di gruppo e "distribuita". Due su tutti: namespace ed 
overload.
3) Il C++ e' un linguaggio a piu' livelli: puo' essere usato in primo 
luogo come linguaggio a bassissimo livello (tanto quanto il C) ma 
permette anche di modellare facilmente livelli di astrazione superiori 
(e questo e' uno dei principali obiettivi di un kernel: fornire 
un'astrazione della macchina sottostante).
Per contro, ci sono anche degli ottimi motivi per utilizzare il C 
invece del C++:
1) Il C e' piu' diffuso e conosciuto, quindi e' piu' facile trovare 
programmatori.
2) Il C++ e' un linguaggio giovane, il C esiste da circa trent'anni. 
Questo significa che i compilatori C sono molto piu' maturi e testati 
dei corrispettivi C++: tra le conseguenze di questa situazione c'e' il 
fatto che un sorgente C++ non e' ancora (ma le cose stanno cambiando) 
facilmente portabile da un sistema all'altro.
3) Per la stessa ragione, i compilatori C++ *possono* anche essere meno 
performanti (ma per dimostrarlo ci vogliono dei test).
Evidentemente sino ad ora hanno prevalso le motivazioni anti-C++, ma 
non e' detto che sia cosi' per sempre.


 Non posso farne a meno, sono i thread più seguiti...
E questo non giustifica comunque la tua posizione: sei iscritto ad un 
LUG? segui alcune Mailing List? se cosi' fosse, ti renderai conto che i 
flames si hanno solo qui, in genere, e che la posizione di chi con 
linux ci lavora e' di compromesso, altro che fanatismo...
La netiquette, ad ogni modo, impone di ignorare i flames, quindi se 
appaiono i piu' seguiti, lo sono solo da coloro che non sanno/vogliono 
imparare a convivere civilmente

 molti affezionati anche dai mondi di Python
questa l'hai letta su topolino o hai dei riferimenti concreti? :)
--
saluti
f.riccardo
[sostituire 
linux.it
 al dominio nell'indirizzo]

 Il lettore è asessuato, e non è singolare nè plurale: le frasi vanno 
Sono d'accordo con te, e non sono l'unico:
http://developer.gnome.org/documents/style-guide
Per il resto, se qualcuno vuole di un OS attenersi alla filosofia,
rispetto la sua liberta` di farlo, cosi` come rispetto la liberta` di
un altro di attenersi all'uso.
Massimiliano

 questa l'hai letta su topolino o hai dei riferimenti concreti? :)
comp.lang.ruby
ruby...@ruby-lang.org
Per quanto poco testo possa fare, me stesso (che dopo piu` di una
settimana di tentativi di fare amicizia con Python, ho scoperto Ruby e
a fine giornata Python era gia` disinstallato).
(Era una domanda scherzosa o proprio un tantino provocatoria come mi
e` arrivata?)
Massimiliano

> > Nota: Col C++ rischi di brutto di avere codice più lento che col C....
B> L'obbiezione era limitata solo alle parti dei programmi che agivano
B> "dinamicamente"
Rischi. Non sicurezze. Dipende da cosa usi e cosa no. 
-- 
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )

 writes:
AV>                Access to array, vector, basic_string
The example seems truncate on  the referenced web page isn't clear how
and  where  averages are  computed.  And  why  gethrtime() instead  of
getrusage() ?


> Nota: Col C++ rischi di brutto di avere codice più lento che col C....
ZC> E' un trade off con la manutenibilita' che puo' essere conveniente o
ZC> meno. 
Non  so  se  sia  un  tradeoff  di  manutenibilità,  l'uso  di  alcune
caratteristiche  del linguaggio invece  che di  altre può  non portare
significativi incrementi  in manutenibilità, cosa che  si può ottenere
con un buono stile e progettazione attenta.
Oddio,  non ho  mai  apprezzato C++  che  per me  ha  sempre avuto  un
retrogusto  strano di  non perfetta  armonia e  quindi non  sono stato
dietro alle evoluzioni e le mie conoscenze hanno fatto la ruggine.


 nemmeno ha vcl.h, figurarsi il compilatore Delphi. Al massimo quello che
ehm, se parli di Borland C++ Compiler 5.51 per compilare compila...
--
DGP85
ICQ# 49371455
May the Force be with you!

 in grado di insegnare a programmare e di conseguenza neppure si
oddio, visto che quest'anno inizia il triennio per me questo l'ho notato, ma
non come credevo... le altre sezioni pascal, noi C++ :)
le cose stanno cambiando un po' alla volta...


case 1)
Io ho iniziato con il Basic(qualcuno lo ricorda?), forse e' l'inglese forse
e che adoro la versatilita' del C++, resto dell'idea che sia preferibile,
nulla togliendo al Pascal.
case2)
Per la frase "Gli Ingegneri non sono programmatori, sono loro che fanno i
nuovi linguaggi"
si parlava in della finalita' non della bravura di chi studia Ingegneria, e
al frase e' stata pronunciata dall'Ingegnere Stefano Russo attualmente
docente di ingegneria informatica della Federico II all'apertura del corso
!999/2000.

 e` arrivata?)
era totalmente provocatoria giusto perche' l'affermazione e` degna di
un addetto al marketing dei 166 ed estremamente poco seria, sorry, ma
mi girano ancora per le email con smenate simili che ricevo a seguito
di certi articoli ("ma conviene davvero imparare python? non e` molto
meglio ruby?")


 utilizza fattivamente python debba voler passare a ruby
E perche` non elastiC (
http://www.elasticworld.org
) ? E` anche "Made
in Italy" :-)


 in Italy" :-)
scrivici un articolo per qualche rivista, vedrai che arrivera` una marea
di gente (che probabilmente non andra` poi al di la` del copia & incolla
degli esempi, quanto ad applicazione pratica, prima di tornare a qualche
rassicurante rad commerciale) a porre domande in merito sul ng ;)
--
bau (pel cane che sono)


 em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )
--
  ===========================
  Alex Vinokur
    mailto:
ale...@bigfoot.com
    mailto:
ale...@dr.com
 
http://up.to/alexvn
 
http://go.to/alexv_math
  ===========================

> getrusage() ?
AV> From man : gethrtime(3C) :
I  logged on  my everlasting  accounts on  a Sun  cluster and  got the
manpage :), that's what originated the question :).
I  think that  getrusage() gives  a more  detailed view,  even  if the
resolution should be the same.
A couple of extra doubts. I lost my grip with C/C++ evolution (I admit
I almost barfed when I readed C98 specs on a book) but I think I heard
that gcc C library lost  efficency when updated to comply(? - language
doubt :) ) with the new standard. Is it true ?
Second doubt:  is the time  difference between C  and C++ the  same on
other CPU (i.e. Intel) ?
TIA!


 writes:
B> case 1)
B> Io ho iniziato con il Basic(qualcuno lo ricorda?), forse e' l'inglese forse
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
Io non lo direi in giro... :)
B> e che adoro la versatilita' del C++, resto dell'idea che sia preferibile,
B> nulla togliendo al Pascal.
Dipende. Se devo spiegare un algoritmo uso Pascal. Se lo devo far correre
il C. Dipende con chi devo comunicare.


 other CPU (i.e. Intel) ?
I didn't test it.
We can see that  applied analysis of time efficiency (complexity) demands special
comprehensive researches.
P.S. Sorry, unfortunately I don't know Italian.


 meglio ruby?")
Non vorrei deluderti ma, se ci tieni a provocare, temo di essere
l'interlocutore meno adatto. :-)
Non so se ti riferivi ad un altro post o se e` stato il mio a non
essere chiaro, comunque l'affermazione era questa: programmatori Perl
e programmatori Python sono passati e passano a Ruby (senza essere
pagati per questo, suppongo, ma non si sa mai ;-) ).  Si tratta solo
di fatti, siano interpretati come si desidera, sicuramente non mi stai
chiedendo di annoiarti con sterile advocacy, i riferimenti te li ho
dati, direi che il resto e` facile farlo da se' con un aiutino da
google. :-)
Massimiliano

 in Italy" :-)
Ho dato un'occhiata agli esempi.  Bellino, non c'e` che dire.
Rispetto a Ruby un po' piu` chiaccherone, e leggendo sentivo la
mancanza di qualche comodita` a cui mi sono abituato (i blocchi, gli
iteratori come in args.each {|an_arg| do_something_with(an_arg)}
invece di for...), ma grosso modo pare vadano a braccetto come
filosofia (OO pulito, scelta delle feature migliori da Smalltalk,
Python etc cercando di lasciare a casa i limiti) e probabilmente ci
sono punti forti che non venivano fuori negli esempi.  Da tener
d'occhio. :-)
Massimiliano

 pagati per questo, suppongo, ma non si sa mai ;-) ).
continuo a dire che trovo tristissima questa guerra tra poveri, troppo
lungo e di scarsi contenuti questo post, scusate ma sono un poveraccio


 lungo e di scarsi contenuti questo post, scusate ma sono un poveraccio
E cos'hai da scusarti? :-) Non sara` che hai visto cosi` tanti fan
sfegatati di linguaggi che, appena trovi qualcuno che menziona un
fatto interpretabile a favore di Ruby o di un altro linguaggio che non
sia Python, tendi a metterlo nella stessa scatoletta?  Guarda che lo
capisco, le guerre di linguaggi stancano anche me, che siano C/Pascal,
C++/Object Pascal, Ruby/Python, non ci ho mai trovato niente di
produttivo.  Se il thread ti stanca mi dispiace, mi hai fatto delle
domande e credevo volessi che ti rispondessi, se non e` cosi` dimmelo,
eh! :-)
Massimiliano

 Io non lo direi in giro... :)
Non l'ho capita? qualcosa contro chi ha iniziato col basic? Non trovo nulla
di male in questo, anzi...


> Io non lo direi in giro... :)
D> Non l'ho capita? qualcosa contro chi ha iniziato col basic? Non trovo nulla
D> di male in questo, anzi...
Ahia, mi spiace. Il pregiudizio è antico e, con le opportune eccezioni, ben
fondato:
   :BASIC: /bay'-sic/ n.   A programming language, originally designed
for Dartmouth's  experimental timesharing  system in the  early 1960s,
which  for  many  years was  the  leading  cause  of brain  damage  in
proto-hackers.  Edsger  W. Dijkstra observed in  "Selected Writings on
Computing: A Personal Perspective"  that "It is practically impossible
to  teach good  programming  style  to students  that  have had  prior
exposure  to  BASIC:  as   potential  programmers  they  are  mentally
mutilated beyond  hope of regeneration."   This is another  case (like
{Pascal})  of the  cascading {lossage}  that happens  when  a language
deliberately designed  as an educational  toy [Lessi che il  basic era
nato come versione educativa del FORTRAN del quale ha molti difetti ma
nessun pregio --Saint]  gets taken too seriously.  A  novice can write
short  BASIC programs  (on  the  order of  10-20  lines) very  easily;
writing anything  longer (a) is  very painful, and (b)  encourages bad
habits that will  make it harder to use  more powerful languages well.
This wouldn't be  so bad if historical accidents  hadn't made BASIC so
common on low-end  micros in the 1980s.  As it  is, it probably ruined
tens of thousands of potential wizards.
   [1995: Some languages called `BASIC' aren't quite this nasty any
more, having acquired Pascal- and C-like procedures and control
structures and shed their line numbers. --ESR]
Non ringrazierò mai mio padre  per avermi regalato un libro sul Pascal
:).


 Io non lo direi in giro... :)
Suvvia, mica tutti per il loro dodicesimo compleanno hanno ricevuto un
VAX. Piu` d'uno si sara` pure dovuto accontentare di una scatoletta con
l'etichetta "VIC 20", e su queste basi la scelta di quale linguaggio
studiare per primo non era troppo ampia :-)
Ciao
 David
-- 
<d.santinoli presso mi . flashnet . it>

> Io non lo direi in giro... :)
D> Non l'ho capita? qualcosa contro chi ha iniziato col basic? Non trovo nulla




Non ringrazierò mai abbastanza mio  padre per avermi regalato un libro
sul Pascal prima ancora che riuscissi a mettere le mani sulla tastiera
del mio Vic20 :).


 del mio Vic20 :).
mah, sarà che più del GW ho usato il Q, ma non ho avuto problemi simili fin ora...
certo però un'analisi critica di un programma che mi sta molto a cuore 
(un generatore di bioritmi) in basic per C64 e diverse versioni in C / 
C++ (tra cui posso aggiungere la mia) si nota come il basic impone stili 
che possono confondere, cmq devo ammettere di avere grossi pregiudizi 
verso pascal forse perché me l'han fatto odiare a scuola...
-- 
DGP85
May the Force be with You!

 VAX. Piu` d'uno si sara` pure dovuto accontentare di una scatoletta con
mah, è grave se il mio caso è un C64 a 8 anni? :P


 le cose stanno cambiando un po' alla volta...
a parte il fatto che resto della convizione che in una scuola superiore 
sia meglio imparare il pascal...
cmq, che genere di C++ vi insegnano? #include <iostream.h>?
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 cmq, che genere di C++ vi insegnano? #include <iostream.h>?
per ora più che altro includiamo una libreria del nostro professore che a sua volta include iostream.h...
cmq se intendo per uso di cout invece di printf sì, usiamo i vari cout 
cin e cerr...
-- 
DGP85
May the Force be with You!

Se non ci hai fatto caso, ci sto provando :)
Beh puoi fare di meglio ;)
-- 
  _  _ >>Now on Linux<<  _     || ICQ number.................Non lo uso
 | \| |___ _____ ___ ___|_|___ || Home-Page ................Non ce l'ho
 | .` | -_|     | -_|_ -| |_ -||| E-Mail................Non l'avrai mai
 |_|\_|___|_|_|_|___|___|_|___||| Un Nemesis che ha pochi e-contatti ;)

potrebbero non capire o addirittura sentirsi offesi
Mai letto "Computer Networks" di Andrew S. Tanenbaum, vero :) ?
-- 
 __
| _         "The Internet is slow, could you please reboot it ?"
|__|iambo   mailto:
gabr...@giambonini.com
 
www.giambonini.com

Purtroppo, al momento non conosco alternativi migliori.
"ant" (Sotto 
jakarta.apache.org
) ?


 "ant" (Sotto 
jakarta.apache.org
) ?
Si`, lo conosco (un po'), ma non mi piace dipendere da un linguaggio
che non ha implementazioni libere e buone.  Sto scrivendo qualcosa di
simile per il Tcl, ma con scopi piu` limitati.


 della lista di argomenti), 
Beh però ti manca una cosa: la portabilità ...

 confronti con cio` che non conosco.
non dimenticarti di citarmi cos'hai prodotto in ruby e con quali
mezzi allora, giusto per farmi un'idea


 mezzi allora, giusto per farmi un'idea
Non appena faro` confronti con Ruby, non manchero`. :-)
Massimiliano

 Mai letto "Computer Networks" di Andrew S. Tanenbaum, vero :) ?
Anfatti, quel libro e' stracolmo di battute, ma nonostante questo e' 
molto chiaro e completo.
-- 
  _  _  >>Now at work<<  _     || ICQ number.................Non lo uso


 Non appena faro` confronti con Ruby, non manchero`. :-)
non capisco cosa voglia dire questa frase, diciamo che l'idea che
mi sono fatto e` che in ruby non hai scritto 10 righe e visto che
insisti a postare senza un'email valida cui rispondere in privato
per me la finisco qui di fiammare (lo so, sono stronxo, amen :))


> Io non lo direi in giro... :)
DS> l'etichetta "VIC 20", e su queste basi la scelta di quale linguaggio
DS> studiare per primo non era troppo ampia :-)
La mia prima macchina č stata  un VIC20. Ma mi avevano giŕ regalato un
manuale del  Pascal (l'unico linguaggio  che impari senza  un computer
sotto le dita)
Basic,  sopratutto   quello  vecchio,  ti   faceva  prendere  _brutte_
abitudini...


> del mio Vic20 :).
D> cmq devo ammettere di avere grossi
D> pregiudizi verso pascal forse perché me l'han fatto odiare a scuola...
Pascal è bello, per spiegare gli algoritmi.
Se no C! iostream stinks! E gli operatori sono zucchero sintattico ed
abitudine! :> :> :> :>


: 
K:H> Prima regola della documentazione: usa un linguaggio appropriato
Vero. Chiamare le cose col loro nome, niente diretrici o direttori :)
K:H> Niente umorismo: qualcuno potrebbe trovare offensivo quello che ritieni 
K:H> divertente
Errore. Il miglior docente è  quello che sa divertire gli studenti non
offendendo nessuno.  Stessa cosa per la  documentazione, sopratutto se
corposa.
K:H> dovrebbe funzionare solo su Unix? oltre per il fatto che autoconf non 
K:H> supporta altri sistemi operativi? in fondo è solo un programma che fa un 
K:H> po' di matematica
Per lo stesso motivo per cui un simulatore ferroviario 3D che ho trovato
funziona solo sotto Windows 9x/2K/XP...
E lo stesso lo puoi portare con poco sforzo sotto Windows.


 writes:
G> Mai letto "Computer Networks" di Andrew S. Tanenbaum, vero :) ?
Devo  farmelo passare  dalla  mia fidanzata...  "Mai sottovalutare  la
larghezza di  banda di un furgoncino che  sfreccia lungo l'autostrada"
dovrebbe essere sua (ed è dannatamente vera).


 dovrebbe essere sua (ed è dannatamente vera).
furgoncino (station wagon, in realta`) pieno di nastri magnetici.
'Never underestimate the bandwidth of a station wagon full of tapes
hurtling down the highway.'
http://www.shorty.com/lists/geeks/96/sep/msg00001.html


 per me la finisco qui di fiammare (lo so, sono stronxo, amen :))
Curioso che quando uno si impegna a non far passare l'interlocutore
come flamer o provocatore, questi finisca per reclamare il ruolo a
gran voce.  Mondo ingiusto.  ;-D
Ah, ovviamente su comp.lang.ruby ci sono anche miei messaggi e quesiti
(argomenti: stile negli unit test, TUI, accesso diretto alle porte
hardware).  Per il mio email... come dice qualcuno, puoi chiedere al
Balrog. :-)
Comunque sono d'accordo, e` rimasto nulla da dire e niente prospettive
di farne un discorso utile, quindi mi associo e chiudo qua.
Massimiliano

 cin e cerr...
 
bene, quello che vi insegnano non e' C++ (ebbene si, questa e' la 
triste realta' della scuola italiana). Con il mio g++ 3 sotto linux 
(che, per la cronaca, e' uno dei migliori compilatori di C++ 
disponibili) non compilerebbe.


 disponibili) non compilerebbe.
ehm...
renditi conto che ora come ora sono in 3a e che quindi il prof si deve 
mettere a spiegare ad una classe di 27 persone, che non hanno (per la 
maggior parte) mai visto un linguaggio di programmazione, come funziona 
il c++...
fanno fatica a capire il for, figurati se ora come ora può spiegare gli 
include...
quelli li spiega a gennaio....


 mah, č grave se il mio caso č un C64 a 8 anni? :P
Se sei nato davvero nel 1985, direi di si` ;-)


 Se sei nato davvero nel 1985, direi di si` ;-)
sěsě, 85


 il c++...
Il fatto e` che la linea di include che ha usato il tuo professore e`
proprio sbagliata: lo standard prevede che quell' `.h' proprio non ci
sia. Non si sta parlando di `sofismi', comde dire ai principianti che
prendono in mano per la prima volta il C, di dichiarare void la main,
per spiegare in seguito che va dichiarata int; quella di mettere, nel
#include, una roba tipo <iostream.h> e` proprio un errore.
Bye,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                         GnuPG Key ID = 0xA4320FF4
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

Mai letto "Computer Networks" di Andrew S. Tanenbaum, vero :) ?
Tanenbaum è Tanenbaum :)
Ma il problema poi è questo:
"[...]Infine, una nota sulla traduzione. Il Prof. Tanenbaum ha uno stile 
colloquiale e moderno che rende la lettura del libro molto simile 
all'ascolto di una lezione. Nel rendere questo stile in italiano si sono 
incontrate grandi difficoltà perchè l'italiano poco si presta a questo 
modo di esprimersi[...]"
("Architettura dei computer - un approccio strutturato", Premessa 
all'edizione italiana)
Tutto qui. Diventa un casino da tradurre. E poi, questo è un libro, 
usato per mille scopi, come guida di riferimento, per preparare un 
esame, per semplice curiosità (altresì nota come "follia pura"), 
eccetera
Io più che altro parlavo dei manuali tecnici, delle reference. Vedi 
Microsoft, chè è la prima che mi viene in mente. Delle reference non 
vengono nemmeno citati gli autori. Sono scritte in uno stile 
impersonale, robotico, quindi con una consistenza inumana: nello stesso 
set di documentazione di Microsoft non leggerai mai la stessa cosa 
chiamata con due nomi diversi, nemmeno in due documenti differenti. Un 
termine tecnico non verrà mai tradotto in due modi diversi. Nemmeno in 
migliaia di pagine di documentazione. "Overview" sarà sempre "Cenni 
preliminari", non sarà mai un "recupero" ma un "ripristino", e così via
(piccola parentesi. Noto solo ora questa piccola perla nell'help di 
Windows 2000: "I file in formato solo testo sono importantissimi se si 
intende condividere i documenti con altri utenti che utilizzano 
piattaforme diverse, quali Macintosh o UNIX.". Ora potete togliervi la 
soddisfazione di rispondere "RTFM!!!" a chi vi spedisce le e-mail come 
allegati in formato Word)
Nota poi le sottigliezze: la prima volta che viene citato un acronimo in 
un documento (e nemmeno il glossario fa eccezione) viene riportato per 
esteso tra parentesi (e nota: sempre tra parentesi, mai in inciso); 
successivamente viene usata sempre e solo la sigla, e così per tutti gli 
acronimi, in tutti i documenti. Credo si sbilancino solo nelle 
"copertine", quelle pagine introduttive con i link alle varie sezioni, 
in cui a volte scappa qualche nota d'entusiasmo
Tutt'altro paio di maniche gli articoli di MSJ e MSDN Magazine, per non 
parlare dei libri editi da Microsoft Press. In cui un minimo di senso 
dell'umorismo da parte dell'autore è tuo diritto :) (gli articoli 
puramente tecnici sono di una noia mortale) Vedi ad esempio questo 
libro, estremamente interessante (per me :P) ma anche micidialmente 
palloso, sembra scritto da un robot:

Beh però ti manca una cosa: la portabilità ...
Portabilità? tu stai parlando di diffusione

 proprio sbagliata: lo standard prevede che quell' `.h' proprio non ci
in verità non ho idea se include di fatto il .h o no... so che include i
flussi... poi se utilizza l'uno o l'altro sinceramente non lo so ora come
ora...
--
DGP85
ICQ# 49371455
May the Force be with you!

 Questo non é pascal, ma turbo pascal ... o megli object pascal ...
No, set e' un costrutto del pascal standard.


 Mai letto "Computer Networks" di Andrew S. Tanenbaum, vero :) ?
anche "Architettura dei computer: un approccio strutturato" (stesso 
autore) non e' male dal punto di vista dell'umorismo :-)


fj.comp.lang.ruby con dei messaggi risalenti a fine 2000 e basta,
 ^^
????????????????????????????????????????
Io leggo comp.lang.ruby
...
Ok, 
news.libero.it
 non lo tiene
$grep ruby /var/spool/news/leaf.node/
news.libero.it
comp.lang.ruby 0
$grep ruby /var/spool/news/leaf.node/
news.unina.it
comp.lang.ruby 19413
$grep ruby /var/spool/news/leaf.node/
news.cis.dfn.de
comp.lang.ruby 21337
-- 
+---- | Un OS per domarli, Un OS per trovarli,             |  -o)
+---+ | Un OS per ghermirli e nel buio incatenarli         |  /\\
 O  | | Nella terra di Redmond, ove l'ombra cupa scende... | _\_V
                    raffaele punto salmaso presso libero punto it

 writes:
D> renditi conto che ora come ora sono in 3a e che quindi il prof si deve
D> mettere a spiegare ad una classe di 27 persone,
Faceva meglio ad usare Java come  linguaggio e a non inventarsi la sua
libreria  (usualmente  le lib  dei  prof sono  una...  :>  :> ci  sono
eccezioni)


 writes:
K:H> Io più che altro parlavo dei manuali tecnici, delle reference. Vedi 
K:H> Microsoft, chè è la prima che mi viene in mente.
E  che sono  pieni  di vaccate  spaventose,  come 2  pagine spese  per
parlare di una cosa che chi va a consultare un reference sa a menadito
(ovvero allocazione su  heap o stack) o di vere  e proprie fregnacce -
come molti consigli  su come ottimizzare VB. Oddio,  da una delle loro
fregnacce - e conseguenti casini - ho tirato fuori una tecnica che uso
correntemente...


 Ok, 
news.libero.it
 non lo tiene
nella mia beata ingenuita` e ignoranza del feed ho inviato un'email
affinche' sia reso disponibile quanto prima da 
news.libero.it
 ;)


 quelli li spiega a gennaio....
 
non e' questo il punto. Il fatto che <iostream.h> *non* esiste. O, 
perlomeno, non esiste se stiamo parlando di C++ standard.
Altro test per vedere se il tuo prof conosce il C++: scommetto 100k che 
avete iniziato con una a scelta tra:
  void main(void)
  void main()
  main()
Ho indovinato? :-)


   void main()
Questa la fanno all'universita`, se per quello, e parlando di C.


> void main()
EB> Questa la fanno all'universita`, se per quello, e parlando di C.
What's wrong ?
La cosa  era lecita col K&R,  su macchine come l'Amiga  ai tempi d'oro
(dove gli HD erano RARI) si usava addirittura void _main() per ridurre
le dimensioni.
Sono  le ultime  standardizzazioni a  volere int  main(int  argc, char
**argv)  perchè  un programma  che  non  ritorna  espressamente 0  non
segnala correttamente che è terminato (ma pretendere i parametri è una
mezza sega mentale). Quasi utile come l'overload degli operatori :>


 eccezioni)
Java l'anno prossimo...
cmq questa è un'eccezione... ho provato le funzioni avanzate... tenendo
conto che era stata creata prima dello standard fa molto comodo..
cmq poi ripeto che probabilmente ci spiegherà senza h...

 affinche' sia reso disponibile quanto prima da 
news.libero.it
 ;)
a che indirizzo l'hai mandata?
bisogna richiederlo a iol..
ad ogni modo l'ho chiesto ieri e da oggi è disponibile...
era stato cancellato per errore..
grande il newsmaster di iol che riesce sempre a sistemare le cose :)


autore) non e' male dal punto di vista dell'umorismo :-)
Dalla sezione 4.1:
"Poichč l'hardware usato si basa solo sui componenti di base descritti 
nel Capitolo 3, in teoria, dopo aver capito a fondo il materiale di 
questo capitolo, il lettore dovrebbe essere in grado di andare a 
comprarsi un sacchetto di transistor e costruirsi questo sottoinsieme 
della macchina JVM. Gli studenti che saranno riusciti a costruirlo con 
successo avranno qualche punto in piů (e un esame gratuito dallo 
psicanalista"

> eccezioni)
D> Java l'anno prossimo...
Non  è un approccio  che condivido.  Java si  presta meglio  a formare
programmatori principianti del C++.


 programmatori principianti del C++.
Te lo vedi un programmatore Java imparare il C++?
il passaggio è quasi impossibile..
al contrario dal c++ al java è molto semplice.
--
DGP85
ICQ# 49371455
May the Force be with you!

 Ho indovinato? :-)
quasi...
il primo che c'ha mostrato era con
    int main()
solo che quando si è reso conto che a sapere cosa vuol dire 'ritornare'
qualcosa con una funzione eravamo in 3 ha preferito aspettare ancora un po'
e ci fa "finché non riuscite a capirlo usate void main"..
tieni conto che ci tocca lavorare sotto TC3...
(e ancora gente non ha capito bene come aprire un programma)..
--
DGP85
ICQ# 49371455
May the Force be with you!

 What's wrong ?
It is not portable and not correct.
Il codice di startup che invoca main() si aspetta il ritorno di un int,
e se non e` cosi` rischi di incasinare lo stack.
Ovviamente con implementazioni stand-alone, dove non esiste altro
runtime al di fuori della main() stessa, questo rischio e`
insignificante, ma non mi sembra questo il caso.


 What's wrong ?
Bad habit.
A dei futuri ingegneri informatici si presume che si insegni almeno a
programare con decenza. Mica perche' e` in C deve essere pure brutto.
Senza contare che, se si vuole scrivere qualcosa di piu` complicato e
proficuo di `hello.c', si deve usare `int main()'.


> programmatori principianti del C++.
D> Te lo vedi un programmatore Java imparare il C++?
Si. 
D> il passaggio è quasi impossibile..
Per nulla.  Come in  ogni cosa  prima si fa  quella facile  poi quella
difficile, ma intanto hai già una certa disciplina interna.
D> al contrario dal c++ al java è molto semplice.
Beh certo Java è più semplice,  ma 10 a 1 hai un cattivo programmatore


> What's wrong ?
DS> It is not portable and not correct.
Non ho ancora trovato un sistema dove non vada.
DS> Il codice di startup che invoca main() si aspetta il ritorno di un int,
DS> e se non e` cosi` rischi di incasinare lo stack.
Idem, non ho  ancora visto un codice che gestisca male  la cosa. E poi
se non  ricordo male è il chiamante  che mette e toglie  le cose dallo
stack, noi il chiamato. E anche se lo fa il chiamato, allora il return
value  va a  cadere "al  di sotto"  del return  value -  nel  caso del
chiamante parametri  e return value sono  sotto il return  address - e
quindi il return value, dato che siamo con un programma agli inizi, ha
già almeno la  prima pagina dello stack reserved  e committed. L'unica
cosa è che il  valore che lui becca come return address  è un valore a
caso, raramente  0 ed  il programma con  elevata probabilità  viola la
regola che deve tornare 0 per dire che è andato tutto bene.


 tieni conto che ci tocca lavorare sotto TC3...
malissimo. Ora sono piu' che convinto di quello che ho detto all'inizio 
del thread: non impararete a programmare in C++. TC++ *non* e' un 
compilatore C++, a dispetto del nome; il fatto e' che da quando hanno 
scritto TC++ ad ora le cose si sono rivoluzionate e il C++ e' 
totalmente diverso.


 mezza sega mentale). Quasi utile come l'overload degli operatori :>
Sbagli: le "ultime standardizzazioni" dicono che sono valide due forme 
di main:
        int main()
        int main(int, char**)
come puoi vedere i parametri non sono indispensabili.
E, cmq, quel che conta non e' il tuo o il mio parere, ma quello che 
c'e' scritto sullo standard. Se lo standard dice che "void main" non e' 
valido allora non e' valido. Punto.


 comodo.. cmq poi ripeto che probabilmente ci spiegherà senza h...
senza il .h su TC++ non funziona. Con il .h non funziona nel resto del 
mondo ;-) (o, perlomeno, non funzionera' tra qualche anno; per ora 
funziona ancora per compatibilita').


 psicanalista"
gia' che ci siamo, dalla sezione 4.5.2 (Predizione di salto)
"... Pertanto, quello che fanno gran parte delle macchine quando si 
trovano ad un salto condizionato e' prevedere se questo verra' eseguito 
o no. Sarebbe bello poter inserire una sfera di cristallo nel PCI per 
farci aiutare con la predizione, ma per ora questo approccio non e' 
possibile. Poiche' manca una periferica di questo tipo, vi sono vari 
modi per fare una predizione".


 Non ho ancora trovato un sistema dove non vada.
Per quanto possa essere vasta, la tua esperienza non e` sufficiente ad
avallare un'abitudine sbagliata (e assurda, perche' `void' e` piu` lungo
da scrivere che `int' :-). Altrimenti e` lecito dedurre che se si usa
correntemente `i = i++;' e si ottiene sempre il risultato sperato, si
stia scrivendo buon codice.
In ogni caso il compilatore DEC su OpenVMS da` un fatal error. E gcc ha
un'opzione per emettere un warning quando main() e` dichiarata in modo
scorretto, per esempio come void.


> le dimensioni.
AC> bene, bene. In ogni caso non erano programmi C; 
No, erano in granoturco.
AC> perlomeno non erano 
AC> programmi scritti nel C del giorno d'oggi.
Ecco, meno affermazioni dogmatiche. 
AC> E, cmq, quel che conta non e' il tuo o il mio parere, ma quello che 
AC> c'e' scritto sullo standard. Se lo standard dice che "void main" non e' 
AC> valido allora non e' valido. Punto.
E se  dice che al C mettono  il tipo boolean mi  viene il voltastomaco
[,\.;\!\?]+.


 bisogna richiederlo a iol..
iol ovviamente, ma non ti dico dove perche' ti metteresti a ridere ;)
comunque ho imparato che chiedere non costa nulla e insistere spesso
ti fa ottenere qualcosa se lo fai bene ;)


 del thread: non impararete a programmare in C++. TC++ *non* e' un
certo che non impariamo i primi 3 mesi...
considera che praticamente tutti si perdono quando c'č da usare qualcosa di
piů di un for...
fagli prima capire che cavolo vuol dire programmare e poi impariamo a
programmare in C++


 senza il .h su TC++ non funziona. Con il .h non funziona nel resto del
ho detto che ORA usiamo il TC3.. da febbraio passiamo al DJGPP e allora
arriva la 'pacchia' per me e le difficoltà per il resto :P


 ti fa ottenere qualcosa se lo fai bene ;)
newsmaster (c/o) 
iol.it
è disponibilissimo (credo sia l'unico in tutta IOL / Infostrada / Wind) e
sistema i problemi in un giorno o massimo due...

         int main(int, char**)
ho sudato freddo......ho iniziato a studiare il c++ con il libro di Lippman,
comprato proprio perchè tratta il c++ standard.....dopo aver letto il post
mi sono precipitato alle prime pagine a vedere come
iniziava......fortunatamente è corretto !
Ale

 programare con decenza. Mica perche' e` in C deve essere pure brutto.
...
Credo dipenda molto dalla facolta'. Se vai in quella "giusta" prendi il
pezzo di carta senza saper fare una riga di C et similia.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.mascanc.net
        **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
 [cowo@braveheart cowo]$ make sex
    make: *** No rule to make target 'sex'.  Stop. 
        :-((((

        int main(int, char**)
Non c'era anche int main(int, char**, char**) per passare oltre ai 
parametri anche l'environment?
Ah, toglimi una curiosità: è vero che in C queste due forme:
tipo procedura()
tipo procedura(void)
hanno due significati diversi, mentre in C++ sono la stessa cosa?

a programmare in C++
Per queste cose esiste il Pascal... non li capisco questi professori che 
si incaponiscono ad insegnare versioni imbastardite del C++, o peggio 
(vedi la nostra professoressa di Algoritmi) si inventano un loro balordo 
pseudo-codice; nel caso della mia professoressa, una copia spudorata del 
Pascal (quello vero sarebbe stato molto meglio, se non altro sarebbe 
stata costretta ogni volta a mettere i tipi delle variabili e dei valori 
di ritorno delle funzioni, e si capirebbe qualcosa di quello che spiega)

 Non ho ancora trovato un sistema dove non vada.
[anto@localhost anto]$ cat prova.c
void main()
{ }
[anto@localhost anto]$ gcc -ansi prova.c
prova.c: In function `main':
prova.c:2: warning: return type of `main' is not `int'


pseudo-codice;
Che fai, Informatica alla Bicocca (Milano)?
</OT>
-- 
+---- | Un OS per domarli, Un OS per trovarli,             |  -o)
+---+ | Un OS per ghermirli e nel buio incatenarli         |  /\\
 O  | | Nella terra di Redmond, ove l'ombra cupa scende... | _\_V
                    raffaele punto salmaso presso libero punto it

 hanno due significati diversi, mentre in C++ sono la stessa cosa?
si. se in C non specifichi la lista di parametri vuol dire che puoi 
passare quanti e quali ne vuoi alla funzione e il compilatore non fara' 
una piega: li mettera' diligentemente sullo stack sperando che siano 
nel numero e del tipo giusto. Sempre in C, se la lista dei parametri e' 
"void" significa che la funzione non prende alcun parametro; quindi:
        // codice C
        int f();
        int g(void);
        f(); // compila
        f(1); // compila
        f(1.4, 6, "hello world"); // compila
        g(); // compila
        g(2); // NON compila
In C++ invece le due forme hanno lo stesso significato: funzione che 
non prende parametri.
Nota: quello che ti ho detto sul C vale sicuramente per il C89, ma non 
so se e' giusto anche per il C99.


 iniziava......fortunatamente è corretto !
vai tranquillo; non l'ho letto ma ne ho sentito parlare molto bene (su 
cpp.programmazione.it
 trovi una recensione).


 Ecco, meno affermazioni dogmatiche.
sbagli; un "dogma" e' una convinzione a cui si puo' (o, meglio, si 
deve) credere senza avere per forza una prova di correttezza. Quello 
che ho detto io non e' dogmatico: se vuoi la prova che quello che ho 
detto e' corretto basta che leggi lo standard C.


 neppure cosa sia l'environment...
e' l'estensione *NIX di main, vista l'importanza che l'environment ha 
in questi OS, l'hanno tutti i compilatori unix

> Non ho ancora trovato un sistema dove non vada.
AC> prova.c:2: warning: return type of `main' is not `int'
Warning, nemmeno errore bloccante. Ovvero "attenzione, qualcosa non mi
torna, ma tu sei il programmatore e si fa come vuoi tu". Che diamine è
C, non Java.
Tanto è vero che il programma terminerà correttamente.
L'unica  obiezione   seria  è  che   se  non  setti  il   return  code
correttamente  i  programmi  che  hanno  lanciato  il  tuo  potrebbero
interpretare male il risultato della tua esecuzione.


> No, erano in granoturco.
AC> infatti; gcc = Granoturco C compiler :-)))
 
Beh, gcc su Amiga a quei tempi non c'era...
AC> sbagli; un "dogma" e' una convinzione a cui si puo' (o, meglio, si 
AC> deve) credere senza avere per forza una prova di correttezza. Quello 
AC> che ho detto io non e' dogmatico: se vuoi la prova che quello che ho 
AC> detto e' corretto basta che leggi lo standard C.
E giù di dogmi. C'è anche  scritto che in una rete LC l'oscillazione è
continua ad libutum. Non per questo  la cosa è valida fuori dal "mondo
della lavagna".
Quanto  agli standard,  alcuni sono  ridicoli. Altre  cose  sono utili
perché non tutti sono svegli e quindi usano le chiamate che non devono
usare nel posto dove non le  devono usare. Anche se possono fare poco,
visto che non viene eliminata la chiamata pericolosa.


 visto che non viene eliminata la chiamata pericolosa.
non capisco a cosa ti riferisci. 


Che fai, Informatica alla Bicocca (Milano)?
No, Torino. Peccato, speravo di rastrellare qualche compaesano :)
-- 
Nato nel vizio, morto nel supplizio
Nato nel peccato, ad entrare sia invitato

non prende parametri.
Perfetto, allora avevo ragione. Vorrei poterti portare sottobraccio 
all'università, puntarti contro quelle teste di cacio dei miei compagni 
e fare fuoco
Approfitto ancora un po' di te: sai per caso come vengono gestite le 
funzioni con numero variabile di parametri? immagino comunque che 
questo:
tipo procedura(...)
si limiti a mettere i parametri uno alla volta sullo stack (tanto li 
passa da sinistra a destra), giusto? ma le va_list come funzionano, che 
ancora non mi è chiaro?


> visto che non viene eliminata la chiamata pericolosa.
AC> non capisco a cosa ti riferisci. 
#include<string.h>
#include<stdio.h>


> non prende parametri.
AL> Perfetto, allora avevo ragione. Vorrei poterti portare sottobraccio 
AL> all'università, puntarti contro quelle teste di cacio dei miei compagni 
AL> e fare fuoco
AL> Approfitto ancora un po' di te: sai per caso come vengono gestite le 
AL> funzioni con numero variabile di parametri? immagino comunque che 
AL> questo:
AL> tipo procedura(...)
AL> si limiti a mettere i parametri uno alla volta sullo stack (tanto li 
AL> passa da sinistra a destra), giusto? ma le va_list come funzionano, che 
AL> ancora non mi è chiaro?
Siccome non c'è  un end of parameters (usualmente,  puoi anche mettere
che se trovi uno 0 hai finito i dati) di solito c'è un parametro fisso
che  permette alla  funzione di  capire  che parametri  ci sono  sullo
stack.
Pensa a printf()


 che ancora non mi è chiaro?
non le ho mai usate.


 non č un buon segno.
stai dicendo che lo standard e' una buffonata?
mah!
anto


> non č un buon segno.
AC> stai dicendo che lo standard e' una buffonata?
Sto  dicendo  che  lo  standard   č  una  buffonata  in  alcuni  punti
(i.e. inserire il tipo booleano in C). Spero ora sia piů chiaro.


 (i.e. inserire il tipo booleano in C). Spero ora sia più chiaro.
 
IMHO un tipo booleano e' una bella cosa.
Cmq non e' questione di buffonata o no; se lo standard dice una cosa e' 
quella. Non possiamo dire "a me non piace quindi faccio il contrario"; 
o, meglio, lo puoi fare ma a tuo rischio e pericolo.
ciao Anto


non le ho mai usate.
Ri-sfiga. Peccato. Sarò costretto a riscrivermi printf (dici che sarà 
complicato? considerando non m'è mai riuscito di scrivere un parser più 
complesso di un readline?)


> (i.e. inserire il tipo booleano in C). Spero ora sia più chiaro.
 
AC> IMHO un tipo booleano e' una bella cosa.
No, dato che era già definito chiaramente "0 falso, non zero vero".
Un tipo booleano ha senso ini  Java o in Pascal dove il compilatore ti
bestemmia dietro  perché il contratto iniziale del  linguaggio era che
"si seguono le regole e i tipi sono una cosa seria da rispettare".
C   al   contrartio  è   nato   come   linguaggio  assolutamente   non
tipizzato. Volerlo tipizzare perché la maggior parte dei programmatori
fa casino ed una minoranza lo sa usare non mi pare una cosa seria.
AC> Cmq non e' questione di buffonata o no; se lo standard dice una cosa e' 
AC> quella. 
Non fare l'ovino. Se uno standard  dice una cosa dice una cosa. Quanto
a cio che è, beh ho  visto gli dei da abbastanza vicino da permettermi
di decidere io ciò che è.
AC> Non possiamo dire "a me non piace quindi faccio il contrario"; 
AC> o, meglio, lo puoi fare ma a tuo rischio e pericolo.
O se sai cosa fai.
-- 
Gian  | main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Uberto|                        David Korn, 1987 ioccc best one liner 
Lauri |-------------------------------------------------------------------
(aka saint) >>Vedere X-Nospam nell'header - See X-Nospam field in Header<<

> che ancora non mi č chiaro?
Non le  ho mai usate (l'esempio  sotto č il  primo tentativo, riuscito
per  altro, salvo  un warning  sulla macro  __builtin_next_arg  ma non
credo sia colpa mia) e non ho  il K&R sottomano, ma tutto sta ad usare
la macro  va_start che  ti rende il  puntatore al primo  argomento non
dichiarato  esplicitamente e  a sapere  quanti parametri  hai ricevuto
(cosa che fai  col primo parametro che sei  costretto a dichiarare, in
realtą  basterebbe  metterlo   nel  primo  parametro  della  funzione,
dichiarato o no).
Inisializzata una  variabile va_list con  va_start (i.e. p)  accedi ai
valori delle variabili successive con va_arg ed alla fine resetti p con
va_end
Ecco un esempio:
{paperino} 11:15:47
[87]~:cat p.c
#include<stdio.h>
/*#include<varargs.h>*/
#include<stdarg.h>
void foo(int i, ...)
{
        va_list p;
        int j, k=0;
        va_start(p,i);
        while(i)
        {
                j = va_arg(p,int);
                k+=j;
                printf("Letto %d, parziale %d\n",j,k);
                i--;
        }
        printf("-------------- Totale: %d\n",k);
        va_end(p);
}
void bar(int i, ...)
{
        va_list p;
        char *a;
        va_start(p,i);
        while(i)
        {
                a = (char *)va_arg(p,int);
                printf("%s",a);
                i--;
        }
        printf("---\n");
        va_end(p);
}
main()
{
        foo(3,4,2,1);
        foo(1,7);
        foo(0);
        bar(3,(int)"qui",(int)"quo",(int)"qua");
        bar(1,(int)"paperino");
        bar(0);
}
Nota: almeno sulla  RH 7.0 che abbiamo qui  in ufficio l'uso varargs.h
non funziona in quanto va_start ti porta, nell'esempio pubblicato, non
al primo argomento opzionale ma al primo argomento della funzione.
Nonostante le info di gcc dica :
-----------------------------------------------------------------------
   ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the
calling convention for `va_start'.  The traditional implementation
takes just one argument, which is the variable in which to store the
argument pointer.  The ANSI implementation of `va_start' takes an
additional second argument.  The user is supposed to write the last
named argument of the function here.
   However, `va_start' should not use this argument.  The way to find
the end of the named arguments is with the built-in functions described
below.
-----------------------------------------------------------------------
usando nell'esempio vararg.h e va_start con un solo parametro si aveva
un warning perché __builtin_next_arg veniva chiamata senza parametri e
il primo argomento che veniva  prelevato da va_arg era il contenuto di
i...


 più complesso di un readline?)
 
perche' devi riscriverti printf? Cmq non dovrebbe essere 
complicatissimo, ma neppure una passeggiata.


> più complesso di un readline?)
 
AC> perche' devi riscriverti printf? Cmq non dovrebbe essere 
AC> complicatissimo, ma neppure una passeggiata.
Se devo essere sincero io non l'ho trovato più difficile che ripassare
un cursore  forward-only ritornato da  un DB. L'unico problema  che ho
trovato  è stato  che nella  Red  Hat 7.0  che abbiamo  in ufficio  la
va_start() tradizionale è bacata...
Ora che sono curioso provo con GCC che abbiamo su Debian a casa :)


Cmq non dovrebbe essere complicatissimo, ma neppure una passeggiata.
L'ho fatta e funziona. Incredibilmente. Credo sia la seconda mia 
creazione a funzionare senza quasi nessun problema e a poter essere 
usata realmente. Fortunatamente la stringa di formattazione è 
semplicissima da leggere (ringrazio chiunque abbia scritto lo standard 
per l'eccellente design delle chiamate della famiglia format)
Difettucci della mia implementazione:
 - niente float. Ma non saprei da dove partire
 - niente interi lunghi, nè stringhe Unicode. Ancora no
 - alcune sotto-procedure fanno veramente cacare. Ad esempio quella per
   il formato numerico esadecimale. Praticamente faccio un sacco di
   inserimenti in testa ad una stringa temporanea, il che è già
   lentissimo, che poi appiccico in coda al buffer di ritorno: uno
   schifo. Progetto di risolvere costruendo la stringa al rovescio e
   concatenandola dall'ultimo carattere al primo
 - lo standard prevede l'uso di "*" al posto dei parametri larghezza e
   precisione, per specificare che il valore va letto dall'argomento
   successivo? o è un'estensione della Borland? perchè se è standard, mi
   manca anche questa
 - la procedura di formattazione di argomenti stringa è orribile.
   D'accordo che grazie ai TVarRec è ragionevolmente type-safe, ma dover
   supportare ben tre tipi stringa differenti è una bella rottura. Più
   che un bug della mia Format() è un bug di Delphi


 O se sai cosa fai.
salvo che poi dopo qualche anno devi fare il porting del tuo programma 
sotto un altro compilatore e/o O.S. e allora ti metti a piangere.
ciao anto


> O se sai cosa fai.
AC> salvo che poi dopo qualche anno devi fare il porting del tuo programma 
AC> sotto un altro compilatore e/o O.S. e allora ti metti a piangere.
Dipende.  Tanto  per cominciare  il cambio di  O.S. può  farti dannare
anche se hai seguito gli standard (i.e. il nuovo S.O. ha uno scheduler
del menga  che ti manda a  puttane il multithreading,  oppure, come mi
capitò tanti anni fa portanto talk sotto HP-UX, c'è una magagna in una
chiamata al  sistema...).  
E poi il cambio di S.O.   l'ho visto fare così raramente, salvo che in
ambiente  universitario...  Oggi  preferiscono  rimanere sullo  stesso
S.O.  e  pagare un assicurazione per  i danni che  possono accadere se
questo S.O. lascia la porta aperta a schifezze assortite.
BTW, a 19 anni la pensavo più  o meno come te.  Pensavo anche che fare
l'overload degli operatori  fosse una figata. Poi ho  sbattuto il naso
sul mondo  reale e  mi sono accorto  che l'overload degli  operatori è
solo una questione di cultura. 


 solo una questione di cultura.
a leggere questa frase mi sembra di intravedere un atteggiamento del 
tipo "Io ho piu' esperienza di te, fidati che ho ragione"; puo' essere. 
Ma io non mi fido se non mi si danno delle valide ragioni. Tanto per 
fare un esempio, l'overload degli operatori e' *fondamentale* per poter 
applicare il paradigma della programmazione generica; e la 
programmazione generica non e' solo questione di cultura: e' un nuovo 
campo di ricerca in cui si stanno facendo molti progressi.


> solo una questione di cultura.
AC> a leggere questa frase mi sembra di intravedere un atteggiamento del 
AC> tipo "Io ho piu' esperienza di te, fidati che ho ragione"; puo' essere. 
Sacrosanto diritto di farti la _tua_ esperienza.
AC> Ma io non mi fido se non mi si danno delle valide ragioni.
Oh, vedo che  ragioni con la tua testa e che  certe tue posizioni sono
frutto di una scelta ragionata.
Buono.  
Io  uso  la stessa  risposta  a quelli  che  si  buttano a  scimitarra
sguainata urlando  "é sbagliato perché  non è standard" su  chi scrive
void main().  Dammi un buon motivo  per agire da talebano  :). Dire "è
standard" è  come dire  "Io ho  piu' esperienza di  te, fidati  che ho
ragione". Dire "O.K. void main() non è previsto dallo standard e anche
se funziona su tutti i sistemi che conosci occhio! Ti può capitare una
volta  su  un milione  un  sistema  in cui  il  programma  va in  core
"misteriosamente" è  c'è una buona probabilità che  sbatterai la testa
per un pezzo prima di ricordarti  che main() per lo standard è di tipo
int"  è  meno  talebano  è   (IMHO)  più  utile  perché  richiama  nel
programmatore il panico de "ma dove cazzo è il bug!!!"  :).
AC> Tanto  per   fare  un  esempio,  l'overload   degli  operatori  e'
AC> *fondamentale*   per   poter    applicare   il   paradigma   della
AC> programmazione generica; e la  programmazione generica non e' solo
AC> questione  di cultura:  e' un  nuovo campo  di ricerca  in  cui si
AC> stanno facendo molti progressi.
Dalle elementari ci insegnano a  usare gli operatori per le operazioni
su N.   Alle medie ti  fanno usare  gli operatori su  Z e su  R.  Alle
superiori  ti fanno  usare  gli  operatori su  C.  Gli operatori  sono
naturali  perché  hai  usato  sempre  quelli  e  sempre  la  notazione
algebrica.  Perciò  quando ci si  trova davanti ad un  linguaggio che,
creando un tipo non previsto  dal linguagio (i.e. i complessi), non ti
permette di scrivere a = b + c ti senti limitato.
D'altro canto mi sono reso conto  che non è così.  Anni fa comprai una
HP28, poi  passai ad una 48, oramai  non riesco quasi più  ad usare le
calcolatrici col tasto  "=", non ci sono più  abituato. Nelle macchine
RPN ho  abbandonato la notazione algebrica  ma ancora non  mi ero reso
conto di una  cosa che ho visto chiaramente solo  passando al LISP (lo
uso per programmarmi  Emacs). In lisp + _è_una_funzione_  così come lo
era nello  RPN. Che tu scriva  '1 + 1' o  '(+ 1 1)'  o 'somma(1,1)' la
semantica non cambia,  e se sei culturalmente abituato  a scrivere. E'
un discorso analogo alla musica.  Avete mai ascoltato l'opera cinese ?
Eppure per loro è celestiale, ci sono abituati, è nella loro cultura.
(Naturalmente devi poter avere il polimorfismo in modo che (+ arg arg)
accetti argomenti di tipi diversi  che ammettono l'operazione +. In un
linguaggio compilato sarà il compilatore a scegliere l'implementazione
della funzione +  da utilizzare, in un linguaggio  interpretato si può
utilizzare il lookup basato sulla  firma o, in mancanza di questo come
dovrebbe essere il caso di Emacs Lisp, l'uso di predicati sul tipo per
selezionare quale 'signifcato dare' alla funzione in esame)


 programmatore il panico de "ma dove cazzo è il bug!!!"  :).
su questo ti posso dare ragione; forse avrei dovuto esplicitare meglio 
il mio pensiero; certo e' che chiunque avrebbe potuto trarre le 
conseguenze una volta che ha capito cosa e' (e a cosa serve) lo 
standard.


> piano di  Java a  quanto pare :)  :) :).  
AC> prima di fare certe affermazioni dovresti esserne sicuro. Hai mai fatto 
AC> dei test che dimostrino senza dubbio che "certe caratteristiche" del 
AC> C++ siano molto lente?
Di nuovo ho detto  a quanto pare ed ho messo 3  smile, non posso avere
alcuna pretesa  di serieta`  in quanto  ho dati di  prima mano,  ma si
parlava di usare le classi virtuali in C++.
AC> su questo  ti posso dare  ragione; forse avrei  dovuto esplicitare
AC> meglio il mio pensiero;
Non credere che sia banale :).  Il "Calculemus" di Leibnitz (era lui ?
- i miei  studi liceali di  filosofia sono di  tanto tempo fa :)  ) si
riferiva appunto all'uso di  un ipotetico linguaggio formale sul quale
si potesse "ragionare" per operazioni  ben definite in modo da esporre
il proprio pensiero in maniera  univoca e poter arrivare a dirimere le
discussioni in modo esauriente.
AC> certo e' che chiunque avrebbe potuto trarre le 
AC> conseguenze una volta che ha capito cosa e' (e a cosa serve) lo 
AC> standard.
Ho visto troppi standard pilotati da interessi di parte.


Gian Uberto Lauri ha scritto:
[...]
cambiare l'oggetto a un certo punto sarebbe stata una bella idea :))
--
saluti
f.riccardo
[sostituire 
linux.it
 al dominio nell'indirizzo]

>>>>> "fr" == f riccardo <fr...@fuckthespammers.see> writes:
fr> Gian Uberto Lauri ha scritto:
fr> [...]
fr> cambiare l'oggetto a un certo punto sarebbe stata una bella idea :))
Rischi di perdere il threading. E poi e` una cosa comune che i thread
deviino...
