Newsgroup: it.comp.os.dibattiti
Titolo: ecco xkè linux non decolla

Salve a tutti
premetto che ormai uso il linuzzo dalla redhat 5, anche come desktop, e 
che di mestiere faccio lo Sviluppatore (con la S maiuscola in quanto 
lavoro C++ e sviluppo sofware di basso livello, mica ciappettini di 
connessione ai db). Uno degli esami che ho dato in università riguarda 
il cosidetto componentware design, e dal quale ho capito(per sommi 
punti) che se le le librerie sono la base della programmazione, i 
componenti è l'unico modo per fare in modo che aggiungere nuove feauture 
senza inserire nuovi bug nel passato. Se in ambiente M$ lo standard è 
COM, per linux troviamo CORBA, ed i vari derivati, bonobo, DCOP, MCOP 
etc.... morale della favola in ambiente linux manca un vero standard dei 
componenti, e quindi ad esempio copia ed incolla non funziona mai dello 
stesso modo, le interfaccie (dialoghi) nonostante le skin sono 
differenti per funzionalità etc. Se allo stato attuale delle cose circa 
il 75% degli utenti desktop usano kde ed il restante 25% usano qualcosa 
gnomizzato, ci aggiungiamo mozilla con il suo sistema, morale della 
favola ci troviamo con un ambiente disordinato e disomogeneo, scritto 
ancora in buona parte in C e non in C++ (ma da che mestiere fanno quelli 
che lavorano su gtk, mah). L'unco che non tradisce mai è openoffice, 
forse perchè su ambiente win hanndo dovuto supportare COM, si sono 
prosti il problema di come riprodurre le stesse funzionalità su linux. 
Quindi o la situazione cambia e si sviluppano i vari bridge os i passa 
tutti allo steso sitema di componenti, o mi sa che ci toccherà passare 
tutti a longhorn, con mia somma tristezza perdendo il treno
PS scusate l'ignoranza ma in ambiente mac come funziona il discorso 
componenti?

 connessione ai db).
Quindi tu sei uno Sviluppatore di alto livello che sviluppa software
di basso livello... ?
Ma se un software e' di basso livello, vale poco quindi, altrimenti
sarebbe di alto livello, giusto ? Ah no no, e' di basso livello quindi
il livello e' indubbiamente alto.
In pratica quel che proponi e' una specie di passaggio a livello, in
modo che il livello del sistema si livelli con quelli gia' in essere.
Ecco perche' Linux non decolla.
Azz, ci vorrebbe un sistema diverso, chesso' magari a finestre.

 PS scusate l'ignoranza
Lasciando perdere il fatto che meta' delle cose che dici e' sbagliata,
mentre l'altra meta' semplicemente falsa, lasciando perdere
l'autoproclama iniziale, il topic e' stato abbondantemente dibattuto,
quindi puoi usare il buon Google e trovare risposta a 3/4 delle
inesattezze che poni, e abbondanti spiegazioni (con la S maiuscola).
Lanciare un dibattito da basi completamente errate secondo me non e' il
massimo della vita :)
Hint: prova un copia incolla tra una applicazione X e l'altra usando il
tasto centrale del mouse.
HTH, HAND,
-- 
                                                __Nicholas Wieland
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
                                                __The Zen of Python

connessione ai db). 
Sei sopratutto Modesto (con la M maiuscola). 
Poi mi devi spiegare perchè il c++ è indubbiamente migliore del c. il
fatto che ci siano due plus davanti non significa necessariamente che
sia migliore, ma solo che sia diverso, non pensi? :-)
Ciao

 fatto che ci siano due plus davanti non significa necessariamente che
Be adesso c'e' anche la versione musicale il c#
-- 
MAX
http://www.birreonline.net
Chi beve birra campa cent'anni


rotfl
-- 
Meglio un culo piatto, che un piatto nel culo. (Confucio)

 di basso livello quindi il livello e' indubbiamente alto.
Fatti spiegare il concetto, o lasciati dire
che come umorista sei messo male ;)
    Vilco


un umorista di basso livello, in sostanza.
O forse di livello basso.
;-)


f u cn rd ths u r usng unx

 ha più infrastrutture, C o C++?
Diciamo (anche) che se il "C" e' un casino il "C++" e' un casino++ :-)
 
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 O forse di livello basso.
Aggiornati a Umorista++
-- 
il *Vide* - ICQ #5301833
Powered by Gentoo
http://www.heavy-metal.it

 Diciamo (anche) che se il "C" e' un casino il "C++" e' un casino++ :-)
Ma il C non è un casino, è il programmatore medio che lo è.
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)

 HTH, HAND,
[1] anche in CORBA 3 verrano definiti i componenti, adesso sono in beta, 
spero che presto decidano anche come defire/mantenere la binary  tra 
differenti release dei componenti


mai sentito parlare del concetto di information hiding? prova a 
mantenere in programma di 500.000 linee di codice in C e lo stesso 
programma in C++ poi mi dici dove fai meno fatica

 
mmm hai visto su che newsreader sto usando? secondo te passo a longhorn?

 programma in C++ poi mi dici dove fai meno fatica
Con il numero di linee ci fai poco... Prendi un linguaggio che in una
linea comprime 6 linee di c++ e per lo stesso software ho un rapporto
to 1/6 sulle linee.
Conta come e` organizzato il codice e non le linee... Io ho lavorato
(da solo) su un software per un televisore da oltre 12.000 linee di
codice e non l'ho fatto in c++, ma neanche in c a dir la verita`,
pero` non ho incontrato il minimo problema, neanche un pochetto.
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Gentoo Proud User

 pero` non ho incontrato il minimo problema, neanche un pochetto.
Ah, ecco perche il mio televisore non vuole sintonizzare Rete 4.....:-)
Saluti.

 Ah, ecco perche il mio televisore non vuole sintonizzare Rete 4.....:-)
ROTFL :), per quello usavamo un software esterno eh eh, io ho fatto il
collante di tutto e aggiunto roba in piu` tipo un encoder mp3 e via
dicendo roba di simile fattura (image viewer con zoom).
Oppure la televisione e` comunista e non visualizza certa roba.
Oppure l'ho fatta talmente bene che ti vuole aiutare :P.


 to 1/6 sulle linee.
In c++ si suppone ci sia una progettazione ad oggetti, e se c'è un 
vantaggio nel programmare ad oggetti è quello della gestione del codice di 
grosse dimensioni. 

 grosse dimensioni. 
Perche` secondo te non esistono due linguaggi ad oggetti che hanno
diversi rapporti di righe di codice?
Non ho voglia di tirare fuori i soliti linguaggi che si ricomincia a
guerreggiare, eppero` le differenze restano e ci sono effettivamente.


 to 1/6 sulle linee.
Mi potresti fare un esempio per cortesia, perché non riesco proprio ad
immaginarmi come sia possibile un rapporto 1/6 se escludiamo
limitatissimi casi particolari.
Grazie, ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 Ah, ecco perche il mio televisore non vuole sintonizzare Rete 4.....:-)
Hai provato con il decoder. Pare che Rete 4 occupi abusivamente quelle
frequenze, agari sono riusciti a schiodare Emilio Fido.


 Ah, ecco perche il mio televisore non vuole sintonizzare Rete 4.....:-)
Mi dici la marca, che lo compro ? 


 e per fortuna, se c'è più di uno standard mi spighi che standard è?
Il bello degli standard e' che ce ne sono tanti fra cui scegliere :-)
Scherzi a parte, quando gli standard sono imposti con metodi poco chiari o
che nulla hanno a che vedere con l'utilita' o l'efficienza tecnica non
vedo come possano essere desiderati.
La liberta' di scelta del desktop sotto linux e' IMHO una ricchezza che ha
portato a interrogarsi  su come farla fruttare. Ci si sta lavorando. Io,
pur usando kde, non vorrei mai essere obbligato ad usare *solo* quello
perche' e' diventato uno standard de facto.
ciao!

Aggiornati a Umorista++
Oppure a Umorista#, con tecnologia DotNot

 release che succede? incrociamo le dita?
Deduco quindi che se prendo un documento da MS Project e provo ad
incollarlo in DreamWeaver il documento viene convertito ?
Il formato e' ininfluente, naturalmente, tra l'altro XML e' come dire
tutto e niente, anche se ultimamente e' di moda definire i formati piu'
strambi "XML".


 limitatissimi casi particolari.
Sia python che, probabilmente, ruby permettono di arrivare a un tale
livello di 'compressione' delle linee.
Non e` una novita` ed e` una cosa abbastanza risaputa. Mi stupisce che
gli stimatori di python non si siano accorti di questo vantaggio.
Ovviamente e` una media, ci sono volte in cui arriverai a 1/15 delle
linee e alcuni casi dove magari ne scrivi il doppio.
Sempre ovviamente e` una media sull'esperienza di chi ha oltre 25 anni
sulle spalle nel settore e ha programmato in vari linguaggi.
Se vuoi scriviamo un nntp client che si connette a un newsserver,
scarica gli ultimi post e li salva, ognuno in un file, in una
directory del tipo it/comp/os/dibattiti.
Toh... ce l'ho :)
Circa 190 linee di codice in python. E per scaricare 1100 post circa,
sulla mia connessione, ci mette 40 secondi circa.
190 linee compresi commenti, linee bianche e funzioni commentate.
L'ho programmato utilizzando un framework a eventi per evitare di
usare i thread, pur ottenendo un risultato simile.


 usare i thread, pur ottenendo un risultato simile.
Benche` tu abbia ragione ho idea che HPL possa obiettare il fatto
che tu abbia usato il framework esterno... nel senso che:
- poniamo che esista un framework per C++ che espone un semplice metodo
getPost("nntpserver", "it.comp.os.dibattiti", 1000) e in questo modo
scaricasse gli ultimi 1000 post di questo NG... 
in questo modo in c++ basterebbero si e no 5 linee di codice...
Anche se... a dirla tutta se esistesse qualcosa del genere in python le righe
da 5 diverrebbero 2 :)
-- 
Lawrence

 mmm hai visto su che newsreader sto usando? secondo te passo a longhorn?
Può darsi, non si sa mai nella vita!


 ``server'' grafico: il futuro non sarà malaccio se si ragiona un po').
Parlamene diffusamente.
(sono serio: sono abbastanza ignorante ed è un discorso che mi 
interesserebbe conoscere, almeno a livello "infarinatura")
Grazie :)
-- 
il Vide - ICQ# 5301833
IAMM - it.arti.musica.metal 
http://www.heavy-metal.it
"There is no stronger drug than reality"

 CORBA/COM e di tutti i paradigmi a componenti[1]? [...]
Hai la bocca piena di ``componenti'', ma alla fine? Vuoi dire cosa? Che si
deve programmare in C++ o Java a seconda dei casi? Che si deve scrivere
uno standard solo perchč cosě ho deciso sia meglio? No grazie. Non sento
il bisogno di fare un cut&paste da qtdesigner a gedit... cosa obbrobbriosa
tra l'altro. Che č che ti affligge tanto? Che cosa non puoi fare che ti
sta rodendo il cervello piano piano? Non si capisce assolutamente dai tuoi
discorsi. Che č, usi parasolid e non riesci a fare un drag and drop su
catia? Problemi, grossi e gravi, di sicuro!
Spiega meglio ed i componenti lasciali a casa che č un discorso senza
sostanza fin'ora ``non fanno i componenti!!'' e lasciamo stare battute
tristissime su Jeeg :)


 Salve a tutti
[...]
Se tu chiedi a tutti in giro, ti diranno che il
problema non e` il decollo, ma l'atterraggio.
bye,
-- 
   Piergiorgio Sartor

 Grazie :)
Il problema è creare una infrastruttura che sostituisca X e che dia le
primitive per la creazione di librerie grafiche. Ovvero una infrastruttura
``virtuale'' (leggi per capirci classi virtuali pure) la cui
implementazione sia lasciata libera di evolversi: se questo verrà fatto,
gnome, kde & co implementano le funzionalità base dettate
dall'infrastruttura, ipc e menate varie, come gli pare, sarebbero
compatibili a livello base, dipendente da quanto l'infrastruttura ha
dentro, e con tante cose in più che scelgono loro. Fino ad ora, X non ha
proprio una grande varietà di funzionalità, se si prende ciò che fanno
gnome con gtk, kde con qt ed dcop/mcop, si crea un sostrato comune, non ci
saranno grossi problemi di dialogo, tranne magari riscrivere parte di gtk,
qt e *cop. Non è un wrapper... sarebbe troppo lento, ma una
prototipizzazione delle librerie. Il minimo sindacale da implementare (c,
c++, ada, cobol, uncolpochegliprede... non importa): uno standard
minimo... magari con qualcosa di più performante che X. E *nessuno* dica
``non serve la comunicazione tcp'' che gli sparo! :)


Cioč una roba tipo le DirectX???
Se ho detto una stronzata dimmelo, non ho mai capito cosa faccia X e perchč
ci sia bisogno di altri strati di librerie per pilotare le periferiche...

 snip
Non ho provato e non lo so, ma secondo me con la normale nntplib si puo'
arrivare ad un risultato simile.
Il vantaggio di Twisted in questo caso non e' la compattezza del codice,
IMHO, ma l'eliminazione dei thread.
-- 
                                                __Nicholas Wieland
Flat is better than nested.
                                                __The Zen of Python

 IMHO, ma l'eliminazione dei thread.
Certo, l'asynchronous networking e` figo ;-)
-- 
Lawrence

 decollo, ma l'atterraggio.
Pilotare sì, atterrare... no!
(cit.)
See you,
	Silver Drake
-- 
http://www.silverdrakenet.it

  (cit.)
Indiana Jones e l'ultima crociata, in risposta a "Junior, ma tu
sai pilotare un'areoplano?!?"
Puo` darsi?
-- 
Francesco Romani - Ikitt   (signature under [re]construction)
'A geek is someone who spends time being "social" on a computer.'

 Puo` darsi?
<carogna>
Piu` probabile uno dei tipi che stava su quegli aerei in volo sopra NY, un 
tre annetti fa, mese piu`, mese meno...
</carogna>
Vh
-- 
                          | Mi sto arrabbiando...
\|/ ____ \|/   \ ||_|     | ...non vi piacerebbe vedermi
"@'/ ,. \`@"    \|| |     |    arrabbiato...
/_| \__/ |_\ Vax Headroom |
   \__U_/                 |       Dr. David Bruce Banner

 tutti a longhorn, con mia somma tristezza perdendo il treno
Agli utenti Linux, questo S.O. piace così com'è...
Tu installati quello che ti pare.

 periferiche...
No... Quello che ho detto č questo:
Server
  |
  v
Librerie
  |
  v
 GUI
Le librerie implementano ciň che ``č scritto'' nel server --- e piů se
vogliono, ma il *minimo* č nel server. Le GUI usano le librerie (qt č
una libreria, KDE usa le qt).


 diversi rapporti di righe di codice?
Non ho capito la domanda, davvero.

 Non ho capito la domanda, davvero.
Posso fare le stesse cose in 2 linguaggi diversi ma scrivendo un
diverso numero di linee.
Non mi sembra una novita` questa d'altra parte...


 usare i thread, pur ottenendo un risultato simile.
Perdonami, ma con un minimo di obiettività dovresti riconoscere che
quello che hai scritto: "Prendi un linguaggio che in una linea 
comprime 6 linee di c++ e per lo stesso software ho un rapporto
1/6 sulle linee" non è molto veritiero.
Il fatto che il Python (come altri linguaggi) abbia un'ottima libreria 
(che possiamo pure considerare parte integrante del linguaggio) è un 
punto di forza innegabile, ed è sicuramente vero che *spesso* sarà
possibile scrivere un programma in Python molto più corto di uno
corrispondente in C++, ma è altrettanto vero che non è "il linguaggio" 
a comprimere in una linea sei righe di codice C++.
Ciao.


 a comprimere in una linea sei righe di codice C++.
E perche` no? Io prima ho preso un esempio di un software in cui uso
un framework esterno e quindi posso capirti.
Prendiamo la standard library allora, contiene la nntplib gia` di suo
e probabilmente avrei realizzato la stessa cosa in meno di 190 linee,
forse un centinaio ma avrei avuto il problema del thread, facilmente
risolvibile in altri modi (meno belli magari) comunque.
Il fatto che un linguaggio sia di alto livello gia` di per se fa
capire che dovrai smenarci meno rispetto a uno di piu` basso livello
come il c++ o il C.
Anche qua... Fatti un giro su clp che non sara` obbiettivissimo, ma
li` dentro di gente che sa il c++ e tanto altro ce n'e` parecchia e li
usano tranquillamente per integrare in python cose in cui e`
necessaria una certa velocita`.


 risolvibile in altri modi (meno belli magari) comunque.
OK, però, stringendo, riesci a farmi un esempio concreto di codice
Python che richieda un numero 6 volte maggior di righe di codice C++?
Dove questa "compressione" sia dovuta alle caratteristiche del
linguaggio e non all'ottima libreria del Python...
Perché sono perfettamente conscio dell'alto livello del Python, della
sua semplicità, ecc... ma fatico a capire come sia possibile ottenere
una tale differenza di righe di codice (se non, ripeto, per la
libreria).


 libreria).
Non so se e` sei volte meno ma qualcosa in meno e` sicuramente:
fd = file('myBook.txt','r')
lines = fd.readlines()
fd.close()
lines.sort()
fd = file('myBookSorted.txt','w')
for line in lines: fd.write(line)
fd.close()
Questo 'programma' prende un file ne riordina alfabeticamente le righe
e poi le riscrive ordinate in un nuovo file.  Il tutto in 7 linee. E
qua ci scommetto davvero qualche soldo, sono piu` veloce di un
qualsiasi (nel senso di scritto cosi` per fare) programma di qualsiasi
altro linguaggio (ovviamente comparando la difficolta` di scrittura).
Non sto a scriverlo in C perche` finisco tra 2 orette credo e non
sarei comunque piu` veloce di questo.
class mySorter(object):
    def __init__(self, fileName):
        self.fileName = fileName
        self.fd = file(fileName,'r')
    def readIt(self):
        self.lines = self.fd.readlines()
    def sortIt(self): 
        self.lines.sort()
    def writeIt(self, where):
        fdN = file(where,'w')
        for line in self.lines: fdN.write(line)
        fdN.close()
sorter = mySorter('myBook.txt')
sorter.readIt()
sorter.sortIt()
sorter.writeIt('mySortedBook.txt')
Questo e` un po` piu` lungo perche` e` tutto incapsulato in una
classe.
Non li ho testati entrambi, ma sono abbastanza confidente che
funzionino (ma non certo).
Anche qua valgono le stesse cose di prima.
Notare che non ho usato nessun import quindi solo i built-in.
Potrei cambiarlo facendo il sorting di ogni parola invece che di ogni
linea senza aggiungere neanche una linea ma usando le comprehension
list.


 altro linguaggio (ovviamente comparando la difficolta` di scrittura).
   Hmmm
open( INPUT, "<myBook.txt" );
my @Lines = sort <INPUT>;
close( INPUT );
open( OUTPUT, ">myBookSorted.txt" );
print OUTPUT @Lines;
close( OUTPUT );
   Sono solo 6 righe !!!! ;-DDDDDDDDDDDDDD
Volendo si poteva scrivere ancora piu` compatto... Pero' sarebbe venuto meno 
la caratteristica della "difficolta' di scrittura" ;-)
Vh
-- 
                          |
\|/ ____ \|/   \ ||_|     |   Un corpo immerso in un liquido
"@'/ ,. \`@"    \|| |     |   e` quello di un subacqueo.


altro linguaggio (ovviamente comparando la difficolta` di scrittura).
in ruby copiando:
fd=File.new('tmp.txt')
lines=fd.readlines
fd.close
lines.sort!
fd = File.new('tmp2.txt')
for line in lines
 fd.write(line)
end
fd.close
che in effetti č piů lungo di una riga :)
in ruby idiomatico:
open('tmp2.txt','w+') do |fd|
 fd.puts open('tmp.txt').readlines.sort
end

 la caratteristica della "difficolta' di scrittura" ;-)
Anche il mio e` sicuramente accorciabile, ma non volevo proprio
pensare, ho la testa altrove in questo momento...


 pensare, ho la testa altrove in questo momento...
   Immagino... Vai a nanna, te lo consiglio per il tuo bene...
Vh
PS - In bocca al lupo...
-- 
                          | universi dissidenti, 
\|/ ____ \|/   \ ||_|     | ognuno con legislazione
"@'/ ,. \`@"    \|| |     | fisica autonoma.


 end
Giochiamo a "chi ce l'ha piu` corto" ??? Senza chiudere gli stream, come fai 
tu:
open( INPUT, "<inputfile.txt" );
open( OUTPUT, ">outputfile.txt" );
print OUTPUT sort <INPUT>;
Minchia, non sono riuscito a farlo piu` piccolo !!!! ;-DDDD
Vh
PS - Tengo a precisare che sto giocando, non c'e` intento polemico alcuno in 
questi miei post...
-- 
                          |   Comm'e` triste e comm'e` amaro
\|/ ____ \|/   \ ||_|     |   sta assettato a gguarda`,
"@'/ ,. \`@"    \|| |     |   tutt''e cose, tutt''e parole
/_| \__/ |_\ Vax Headroom |   ca niente ponno fa`...
   \__U_/                 |                   Pino Daniele

 Giochiamo a "chi ce l'ha piu` corto" ??? 
[cut]
Continuando a giocare, e usando un trucco un po' sporco, lo indovino con una 
riga sola !!!
perl -e "print STDOUT sort <STDIN>" < inputfile.txt > outputfile.txt
Battete questa, adesso ;-DDDDDDDDDDDDDDDDD
Vh
PS - Vabbe`, vado a nanna pure io, per stanotte ;-)))))))
-- 
                          | civilta` molecolari, gang
\|/ ____ \|/   \ ||_|     | di gas sovraeccitati
"@'/ ,. \`@"    \|| |     | seminavano il panico, le
/_| \__/ |_\ Vax Headroom | galassie fuggivano
   \__U_/                 | 

questi miei post...
ah, beh pure da parte mia, solo intento cazzeggiatorio, attendo che
venga presentata *la* soluzione, che imo, dovrebbe essere quella in C,
di soli sei caratteri, ma nn vi dico quale ;)

 quasi) a vicenda... E mi chiedo ogni volta il perche`...
Ma va la, chissenefrega.
Certo che definirti "perlaro" non ti aiuta :DDD
Non e' meglio "perlista" ? :D
HAND,
-- 
                                                __Nicholas Wieland
In the face of ambiguity, refuse the temptation to guess.
                                                __The Zen of Python

 di soli sei caratteri, ma nn vi dico quale ;)
Sei caratteri?? Non e` che intendevi 6 righe vero?
-- 
Lawrence

a comprimere in una linea sei righe di codice C++.
Concordo. Alla stessa stregua in ambiente Win32 usando le librerie MFC si
risparmiano migliaia di righe di codice, se confrontiamo un programma
C++/MFC con lo stesso scritto in puro C++.
-- 
-angelo-
www.geminisoft.com

perl -e "print STDOUT sort <STDIN>" < inputfile.txt > outputfile.txt
sort < inputfile.txt > outputfile.txt
in comandi DOS :-)
-- 
-angelo-
www.geminisoft.com

 Non mi sembra una novita` questa d'altra parte...
Forse, infatti, bisognerebbe valutare la dimensione
del binario linkato staticamente...
bye,
-- 
   Piergiorgio Sartor

 altro linguaggio (ovviamente comparando la difficolta` di scrittura).
Non credo piu` veloce dello shell script di cui sopra :-P
Pero` lo shell script richiede: una shell e "sort", che non
saprei quanto "grossi" siano complessivamente...
bye,
-- 
   Piergiorgio Sartor


ha scritto::

errore mio. otto caratteri, in C.

 errore mio. otto caratteri, in C.
let us see...
-- 
Lawrence

 writes:

il file contiene semplicemente:
__FILE__
il resto della soluzione è lasciato al lettore ;) 

 saprei quanto "grossi" siano complessivamente...
Ma non sono cosi` veloci come il python. Facciamo una prova allora.
Scarico un file qualsiasi e lo riordiniamo dai:
Ho preso i promessi sposi di Manzoni da 
liberliber.it
http://www.liberliber.it/biblioteca/m/manzoni/i_promessi_sposi/i_promes.zip
Dopodiche` ho rivisto il programma (cosi` diminuivo ancora le linee
:P):
import time
tmp = time.time()
fd = file('i_promes.txt','r')
words = [word for line in fd for word in line.split()]
words.sort()
file('i_promes.sorted', 'w').write('\n'.join(words))
print time.time()-tmp
Ora sono 7 linee comprese le 3 che mi servono solo per misurare il
tempo.
Ho riordinato tutte le parole del testo e il risultato sul mio pc e`
stato questo:
2.14994287491 secondi per riordinare: 220167 parole
Il mio portatile e` un Athlon 1600+ con 256Mb di ram e un hdd
abbastanza lentuccio (credo da 4200 giri).
Python 2.3.3 compilato con gcc3.2.3.
Vediamo cosa sanno fare gli altri :P.  Il gc si prende cura del fd una
volta che il programma e` terminato e quindi non ne ho bisogno,
altrimenti dovrei aggiungere una linea.
Potrei evitare una linea eliminando la dichiarazione di fd comunque
per inglobarla nella list comprehension.


 tutto: è *troppo* lento. Per un kernel il meglio è il C.
Capisco cosa vuoi dire ma non sono completamente d'accordo. Un uso assennato
del C++ nei kernel potrebbe solo fare bene.
Saluti.
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)

 del C++ nei kernel potrebbe solo fare bene.
Mmh... non proprio nel kernel. Deve essere veloce e di basso livello...
non può contenere tutto quanto, soprattutto cose inutili come le
infrastrutture del c++.
Ma sono questioni di visioni. Se vuoi puoi scrivere anche in scheme, cobol
o modula2... ma è la scelta migliore? Tenendo fuori dal discorso le lisp
machines :) naturalmente!


 Se vuoi puoi scrivere anche in scheme,
BRRRRRRR...
in scheme ho imparato a programmare e quindi non posso insultarlo, ma è
comunque meglio che stia alla larga da me :P


 fd.close()
Però il fatto che siano builtin non significa che non siano sempre
classi/funzioni/ecc... di libreria.
Cerco di spiegarmi meglio:
il fatto che io in C++ debba dichiarare le veriabili ed in Python no *è*
una differenza del linguaggio (che porta ad un *vero* per quanto ridotto
"risparmio" di codice -tralasciando i veri vantaggi e svantaggi di
questa scelta-).
Il fatto che io possa scrivere fd.readlines() ed in C++ no è una
differenza di libreria, non di linguaggio. 
Pertanto il codice che scrivi è sì più corto del corrispondente in C++,
ma sempre per via della libreria del Python.


 HTH, HAND,

 ciao!
in my hopinion, sia qt che gtk hanno i loro vantaggi/svantaggi, come 
dcop e o CROBA, quello che importa č che alla fine se ne scelga uno, e 
TUTTI usino quello.

 altrimenti dovrei aggiungere una linea.
OK, questo in 4 righe di codice. In situazioni più complesse ho idea che
la cosa sarebbe ben diversa...


 Può darsi, non si sa mai nella vita!
mmmm forse per lavoro, ma a casa mia no

 
certo però poi non lamentiamoci se zio bill con super long horn, con 
intenet explore 87, supporta solo un html bastardo,che in mozilla non si 
vede, e che visto che M$ ha il 90% del mercato tutti supportano e noi 
con il ns pinguino non riusciamo più a veder un pagina html, ok?

 Non mi sembra una novita` questa d'altra parte...
Ah, sicuramente. Comunque esistono anche i framework, le librerie e la 
riusabilità del codice per risparmiare linee di codice in qualsiasi 
linguaggio.

 ma sempre per via della libreria del Python.
E allora? C++ non ha una STL? Il vantaggio e` ovviamente quello ma a
questo si aggiungono tutte le operazioni con i puntatori piu` altre
cose che sinceramente non mi vengono in mente ora.
Non puoi separare il linguaggio dalla sua libreria, e` semplicemente
assurdo. Sarebbe come dire che la ferrari e la 500 sono uguali perche`
se le spingi invece di usare il motore vanno alla stessa velocita`...
Ci sono dei vantaggi e quindi vanno usati, altrimenti tutti a
programmare in asm, lui non ha libreria e fa tutto da se... Volendo
potrei dire che il C++ ha dei vantaggi sul C solo perche` molte delle
funzionalita` sono state rese piu` semplici, le puoi fare anche in C
ovviamente ma ti ci devi sbattere 20 volte tanto...
Non ho mai capito sti discorsi del separare la libreria dal
linguaggio...


 la cosa sarebbe ben diversa...
Certo, in situazioni piu` complesse non starei a spaccarmi la testa su
come comprimere il piu` possibile 7 righe di codice... Scrivo e poi
guardo, tanto solitamente i colli di bottiglia stanno altrove.


 Ma non sono cosi` veloci come il python. Facciamo una prova allora.
Non e` possibile che non sia veloce almeno quanto
python, dato che "sort" potrebbe essere esattamente
la stessa precisa identica implementazione della
versione python, anzi potrebbe benissimo essere il
tuo programma, come lo hai scritto.
In questo caso "sort" sara` sempre veloce, quanto il
piu` veloce sort possibile.
Potrebbe essere scritto in assembly ultraottimizzato, etc.
Il problema, in questo caso, e` che il linguaggio,
per la sua natura, puo` comprimere quanto vuoi, dato
che ogni "funzione" puo` essere realizzata con un
programma apposito, che risultera`, nel linguaggio,
come un singolo comando...
Dove sta l'inghippo?
bye,
-- 
piergiorgio

 linguaggio.
Si ma un linguaggio resta comunque intrinsecamente piu` verboso di un
altro. Non c'e` nulla da fare...
In python:
print "hello world!"
In C:
#include <stdio.h>
int main() {
    puts("Hello world!");
    return 0;
}
Ovvero 5 linee contro 1, solo per scrivere hello world....


 Dove sta l'inghippo?
Che inghippo? Un linguaggio non e` tale solo perche` si scrive in un
certo modo, ma e` tale perche` ha un suo vocabolario e delle strutture
lessicali. Un linguaggio di alto livello (altissimo nel caso di
python) avra` compresso in ogni istruzione tantissime istruzioni
scritte in C. 
Ovvio che posso riscriverle in C, ma perche` farlo se tanto c'e` gia`
python? Magari infilandoci strani errori...
La shell e` lenta purtroppo, alcune cose molto semplici si fanno
veramente molto velocemente (operazioni su stringhe, file e roba
simile), ma altre invece diventano veramente lente.
Ma non e` questo cio` di cui sto discutendo io... Quello che dicevo e`
che ci sono linguaggi che sono piu` verbosi di altri (sia usando
librerie sia non usandole). C e python confrontati ad esempio sul
semplice hello world mostrano un rapporto 1/5 sulle linee. Su cose
piu` complesse come un newsreader poi il rapporto diventa da risate...
Ho qua xpn-0.1.8 che e` ancora in alpha. Lo puoi scaricare su
xpn.altervista.org
, E` scritto in python e usa le GTK2, in totale sono
3642 linee (e` un reader online ancora).
Non oso pensare pan o Knode quante linee possano essere...


 linguaggio...
Non esserne fiero...


 guardo, tanto solitamente i colli di bottiglia stanno altrove.
Non è questo il problema...


 librerie.
NO COMMENT!!


 Non esserne fiero...
Che c'entra? Sai bene cosa non capisco visto che stiamo discutendo...


 Ma chi te lo dice? Vedi sopra.
Fallo tu allora :).


 NO COMMENT!!
Esatto, cosa devi commentare? 
Prendo dal software che ho fatto:
216 linee per un convertitore cd->mp3 con tanto di scaricamento tracce
da cddb, taggatura e nome secondo cddb, se il cddb non e` disponibile
si fa il file facendo in modo che sia unico.
Dagli import:
import swiglame as sl
import swigpara as sp
import os
import cdaudio
import ID3
import time
185 linee per un 'proxy' locale del cddb (che viene usato per il
convertitore cd->mp3).
Dall'import:
import CDDB as cddb   # cddb-py scaricabile da sourceforge
import DiscID    # compreso in cddb-py
import string    
import cPickle   
import os
import config    # file di configurazione del programma generale (il 99.9% non e` usato)
import time      
import threading 
200 linee per un image viewer con tanto di zoom
dall'import:
import pygame, pygame.surfarray, pygame.transform
from pygame.locals import *
import aspect_scale    # scaricabile da code PCR di pygame
import copy            # standard
import Numeric         # scaricabile da sourceforge credo
import config          # solita configurazione generale
import utils           # library del software generale per incorporare la grafica
                       # non necessario per il funzionamento dello zoomer in pratica
Cosi` ti ho mostrato 3 esempi con le librerie che ho usato, se vuoi,
ripeto, ti mando tutto il software e te lo guardi, possibilmente fai
meglio :)
Mi vien da ridere... Ora il C++ e` meno verboso del python. E non
capisco neache perche` ti arrabbi.
Ma io l'avevo detto che non avevo voglia di parlare delle solite cose...


 non ricordo) usando IronPython.
A parte che IronPython non l'ha visto praticamente nessuno... cmq stai parlando
di Python.NET da cui posso usare leclassi .NET da Python. IronPython porterebbe
python su .NET
ciao!
-- 
Lawrence

 python su .NET
Si, scusa l'errore, il concetto e` quello comunque.


 comunque meglio che stia alla larga da me :P
A me Scheme piace veramente molto, a dir la verita' ...
Non ci farei nulla di grosso, ma come linguaggio nulla da dire.
HAND,
-- 
                                                __Nicholas Wieland
Explicit is better than implicit.
                                                __The Zen of Python

 Non oso pensare pan o Knode quante linee possano essere...
Ma quanto sono grandi le GTK2, per esempio?
bye,
-- 
   Piergiorgio Sartor

 con il ns pinguino non riusciamo più a veder un pagina html, ok?
Patetico FUD.
Ogni tanto spuntano, su ICOD.
-- 
                                                __Nicholas Wieland
Complex is better than complicated.
                                                __The Zen of Python

 piace comunque :P.
Vedi sopra.


 aver introdotto 2 volte i bachi (potenzialmente).
A parte che non è vero in generale, non è ancora venuto fuori questo
rapporto 1/6 (ma neppure 1/2).


 A me Scheme piace veramente molto, a dir la 
E' illeggibile. Quando passi una parte considerevole del tempo a contare
il numero di parentesi, vuol dire che la sintassi di un linguaggio di
programmazione non va.
Saluti.
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)

 capisco neache perche` ti arrabbi.
Non ho mai detto questo, comprendi l'italiano?
E mi arrabbio perché noon riesco a capire se la tua č semplicemente
propaganda "commerciale" o se veramente credi a quello che dici.
Io sono piů propenso a credere che ti sia fatto "intortare" dal tuo 
guru di riferimento, che č un abile venditore...


 programmazione non va.
E' forse per quello che a Nicholas Wieland piace tanto python? :-)

 parte integrante del linguaggio shell script.
Parte integrante ? Non e' un eseguibile ? (quantomeno, io ce l'ho in
/usr/bin).
Ad ogni modo, concordo sul fatto che sia un utilizzo assolutamente
lecito di bash, e che in effetti senza i piccoli eseguibili e tutto il
resto sarebbe piuttosto inutile.
In realta' il punto credo che sia che Dialtone ha scelto un esempio
infelice: aprire uno stream, ordinarlo, chiudere lo stream sono tre
operazioni atomiche, non vedo come sia possibile avere grosse
ottimizzazioni a livello di linee di codice ...
Trovare un esempio significativo e' piuttosto difficile per piccole
operazioni, secondo me, e ad esempio, da quel che so (molto poco), Perl
e' piu' adatto per questo genere di cose.
Pero', se Zope (tiro fuori sempre quello, perche' su quello lavoro :)),
e' in cosi' poche linee di codice un motivo ci sara', dato che in
effetti funziona ...
Zope 3, ad esempio, che e' *veramente* grosso, non pesa nemmeno 4 mega
(il tar.gz), e mi pare che sia piu' o meno il peso di Apache.
Solamente a livello di server, Zope 3 ha http, ftp, xml-rpc, un db a
oggetti, fermo restando che il fulcro di Zope sono i servizi che offre,
gestione degli utenti, gestione dei contenuti, motore per i template ecc.
A me sembra una prova abbastanza decisiva, dato che comunque Zope non
richiede altro che Python, nessun modulo esterno, e contiene anche un
po' di C.
HAND,
-- 
                                                __Nicholas Wieland
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
                                                __The Zen of Python

 /usr/bin).
Hai perfettamente ragione, proprio questa e` l'ambiguita`,
cioe` come distinguere tra il "linguaggio" in senso puro e
le "aggiunte", al fine di misurare la dimensione.
Se vogliamo valutare la compattezza del "linguaggio",
possiamo considerare solo quello, in quanto "grammatica",
oppure considerare anche le "librerie".
La misura andrebbe fatta, quantomeno, considerando la
dimensione del sorgente delle librerie usate.
bye,
-- 
   Piergiorgio Sartor

 non ricordo) usando IronPython.
Beh lasciando stare il fatto che da Python grazie a qualche signore che
si e` sbattuto puoi andare in molti altri ambienti... .NET e` piu` grossa
della libreria di Python.
ciao
-- 
Lawrence

(il tar.gz), e mi pare che sia piu' o meno il peso di Apache.
premesso che concordo su tutto il resto, credo che, seguendo il
ragionamento di HPL la dimensione da considerare non sarebbe quella do
zope, ma quella di zope+python+librerie usate.
Nella mia (inutile) opinione dividere il linguaggio dalle librerie non
ha molto senso,
Ma si stava discutendo di compattezza del linguaggio, e quindi
andrebbe considerata solo la sintassi, cercando di mantenersi lontani
da qualsiasi altra cosa.
La compattezza di python, ruby o perl non č data solo
dall'integrazione di hash, regex e array nel linguaggio, ma anche da
cose come la reflection o l'esistenza delle metaclassi etc etc
L'implementazione di qualche design pattern potrebe essere utile. Ad
esempio il pattern borg/mente alveare (per non rimanere sempre sul
singleton :)
class Borg:
    _shared_state = {}
    def __init__(self):
        self.__dict__ = self._shared_state
*credo* che sarebbe piuttosto complesso da imitare in C++. 
(plausibilmente, in C++ non se ne sentirebbe il bispogno)

 import utils         
SDL esiste anche per C e C++ mi sembra... siamo ancora al discorso di
prima.  Non vale misurare la "brevita`" di un linguaggio grazie alle
tonnellate di librerie che qualcuno ha scritto.
ciao!
-- 
Lawrence

 E' forse per quello che a Nicholas Wieland piace tanto python? :-)
No, programmerei in Perl, altrimenti.
Oh, non che i programmatori Perl mi diano fastidio, ma che facciano le
battute sulla leggibilita' e' un po' come Cicciolina che da della porca
a una suora ^^
-- 
                                                __Nicholas Wieland
Explicit is better than implicit.
                                                __The Zen of Python

 a una suora ^^
non penso ti riferissi a me (che il perl non lo conosco granche'), ma
comunque concordo.


f u cn rd ths u r usng unx

 abitare in Cina
Vedremo tra un annetto... forse le cose si metteranno meglio...


 Ma quanto sono grandi le GTK2, per esempio?
In questo caso e` lecito farmi una domanda simile perche` le GTK2 non
fanno parte della distribuzione standard pero` in caso contrario e`
una domanda sbagliata IMHO.
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Gentoo Proud User

 Manc' p'u cazz! E' la piů grande farsa!
Ma lo slogan di Java non era "compile once debug everywhere"?
E il fatto che lo stesso bytecode giri su piu' di un browser
su piu' di una piattaforma non depone a favore dell'affermazione
di mirco?
In caso contrario, mi piacerebbe conoscere il tuo parere.
C:\>iao Angelo
P.S. I bug delle virtual machine e la loro incapacita' ad eseguire
     un certo bytecode, non credo inficino l'affermazione che Java
     e' multipiattaforma (indipendentemente da altri giudizi che si
     possono dare sul linguaggio/implemetazione/blobbosita/lentezza
     del codice).
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 al C.
Ma guarda che ti sbagli... In python fai tutto, SOLO se in alcuni
punti hai bisogno di prestazioni molto elevati puoi darti al C (con
pyrex magari, o swig, o a psyco e via dicendo).
Non sono comunque d'accordo con quello che scrivi. Probabilmente
quello e` l'approcio che si segue nel C++, in python un'aggiunta alle
funzionalita` del linguaggio richiede anche che per quello sia pensata
una sintassi (per poter usare la funzionalita` in modo piu` veloce e
utile), e con questo viene a modificarsi il linguaggio (si aggiunge
una cosa nuova).
E` un po` esagerato da dire, ma python non ha limiti se non di
velocita` :).
Che sia un valore aggiunto comunque e` vero, ma comunque qualcosa vale
e qualcosa va considerato.


 velocita` :).
Non direi visto quello che affermi sopra...
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 guru di riferimento, che è un abile venditore...
Qualche cagata l'ho detta (la storia che anche con la libreria resta
il rapporto... Non so perche` l'ho scritta visto che piu` d'una volta
avevo scritto il contrario, dovevo essere stanco)...
Pero` ora ho postato esempi che spero ti soddisfino.


 rapporto 1/6 (ma neppure 1/2).
E neanche mi interessa troppo che tu ci creda... 
Aggiungo un metodo a runtime quindi:
def funcToMethod(func, clas, method_name=None):
    setattr(clas, method_name or func.__name__, func)
Creo un Multiplexer per degli oggetti, cosi` li comando tutti da un
unico punto:
import operator
class Multiplex(dict):
    def __init__(self, objs=[]):
        super(Multiplex, self).__init__()
        for alias, obj in objs: self[alias] = obj
 
    def __call__(self, *args, **kwargs):
        return self.__class__( [ (alias, obj(*args, **kwargs)) \
                               for alias, obj in self.items() ] )
 
    def __nonzero__(self):
        return reduce(operator.and_, self.values(), 1)
    def __getattr__(self, name):
        try: return dict.__getattr__(self, name)
        except:
            return self.__class__( [ (alias, obj(*args, **kwargs)) \
                                   for alias, obj in self.items() ] )
if __name__=="__main__":
    import StringIO
 
    file1 = StringIO.StringIO()
    file2 = StringIO.StringIO()
    delegate = Multiplex()
    delegate[id(file1)] = file1
    delegate[id(file2)] = file2
    delegate.write("Testing")
    assert file1.getvalue() == file2.getvalue() == "Testing"
    delegate.close()
    assert delegate.closed


 Python.  Quindi mi stai ancora parlando di libreria.
A me e` stato detto che anche i built-ins non possono essere
usati... E allora con cosa programmo che 'qualsiasi' cosa sono dei
built-in in python.
Sono stato poco chiaro ieri, decisamente... MA libreria standard e
linguaggio, almeno in python, non si separano.


 </code>
Notavo comunque or ora... Questo codice non e` usabile, non viene
compilato. Se vuoi far confronti devi scrivere qualcosa che compili :P
(ora mi esplodi).


 In caso contrario, mi piacerebbe conoscere il tuo parere.
Molti miei amici & colleghi hanno sviluppato delle cose in Java e al 90% 
sui widget grafici funziona in un modo su una piattaforma e diversamente 
su un'altra (da sun a windows a linux a AIX). Ora io ho abolito java 
anche per i progetti dei ragazzi... è più portabile un C/C++ (in 
standard ISO) da console che un bytecode java. Il frontend poi è 
tutt'altra storia.
Una portabilità fantastica l'ho trovata con le qt. Fantastico. La vera 
portabilità è sul codice, non sul binario... o pseudo-binario nel caso 
di java.
Non metto nemmeno mano sulla lentezza... è sparare sulla croce rossa...


 dimensione del sorgente delle librerie usate.
Non direi, Dialtone non ha usato moduli esterni, ma librerie all'interno
della distribuzione base di Python.
Se considerassimo solo il linguaggio in se con Python avremmo diversi
problemi, ad esempio i dizionari sono parte del linguaggio o moduli
esterni ? Potrebbero non essere parti del linguaggio in quanto
sostanzialmente moduli, potrebbero esserlo in quanto moduli importati
come built-in.
Ora, considerando che i "tipi" di alto livello, come i suddetti
dizionari, o se preferisci le liste o le tuple, sono chiare
facilitazioni e parte integrante della semantica del linguaggio: e' 
impensabile un python senza queste feature.
Altrimenti non ti faccio includere stdio, e vediamo che fai ^^
Per dire, il "for" in Python senza range () e xrange () non so quanto
sia utile: giusto se cicli su un container toh. Non fosse che il
container non c'e', perche' e' un modulo :p
Inoltre C++ ha sicuramente il vantaggio su C della libreria (almeno, i
programmatori C++ dicono che ...), se lo togli ...
Per Python e' ancora piu' critico, da qui il "detto" batteries included.
In realta' bash *ha* delle funzionalita' interne ed e' utilizzabile a
prescindere dagli eseguibili sul sistema. Semplicemente non ha una
libreria perche' non c'e' tutta questa convenienza ad averla ...
Cmq anche a livello di linguaggio in se, direi che non dichiarare le
variabili sia un vantaggio, e direi che non avere graffe e end varie sia
un'altro vantaggio.
Poi boh, non uso Python per le linee di codice, mai contate in vita mia,
e non credo di iniziare ora :)
HAND,
-- 
                                                __Nicholas Wieland
Simple is better than complex.
                                                __The Zen of Python

 Ma lo slogan di Java non era "compile once debug everywhere"?
Se mi trovi l'ultima versione *stabile* per FreeBSD... il punto e'
sempre quello. 
-- 
                                                __Nicholas Wieland
Namespaces are one honking great idea -- let's do more of those!
                                                __The Zen of Python

 comunque concordo.
Avro' sbagliato nickname ... capita, ad esser rincoglioniti.


 Non direi visto quello che affermi sopra...
E` esagerato perche` non curi la fame nel mondo programmando in
python, pero` risolvi tutti i problemi di programmazione esistenti.


 della distribuzione base di Python.
Ma queste librerie come sono scritte?
Perche` seguendo questo ragionamento, posso sempre
avere un linguaggio X, che svolge un compito in una
sola linea del suo codice.
bye,
-- 
   Piergiorgio Sartor

 detto almeno una volta.
Vabbe`, questo e` ovvio, la discussione e` su come
misuri la cosa.
A mio avviso devi contare le linee di codice delle
librerie nel computo totale del codice.
Anche perche`, tra le altre cose, quelle librerie
potrebbe avere dei bug, che vanno oltre i possibili
errori del compilatore/interprete.
bye,
-- 
   Piergiorgio Sartor

 modo), occupa spazio, etc.
In python libreria e linguaggio non sono separabili, se non altro i
built-ins e il linguaggio sono assolutamente inseparabili, altrimenti
non avresti accesso ad alcune funzionalita` basi. Appunto come dice
Nicholas.


 zope, ma quella di zope+python+librerie usate.
Non arriviamo a 15 mega credo, Zope non usa altro oltre che Python.
Pero' a C aggiungi anche compilatore e librerie.
A questo punto qualcuno obbiettera' che dovrai pur compilare Python, e
senza compilatore e' dura.
Quindi io sosterro' essendo di parte di usare da sempre i binari
(falsissimo, sempre compilato), e partendo da un thread che parlava di
A, a cui io ho risposto B e qualcun'altro C, si arrivera' ad uno
sviluppo D-E-F-G-H-I, che si concludera' al 500esimo post con qualche
insulto, qualche denuncia, qualche PLONK e un gran malditesta a Stallman
(in qualunque modo si scriva).
Benvenuto all'OP su it.comp.os.dibattiti (io continuo a sostenere che
dovremmo chiamarlo it.comp.rotfl.dibattiti pero' :D)
:D
HAND


 Nicholas.
Forse non mi sono spiegato.
Non e` questione si separare o separabile, ma di
mettere in conto.
Se il mio linguaggio si basa su di una libreria,
senza la quale il linguaggio non funziona, di
un GB, non posso comunque dire che il linguaggio
e` compatto, perche` faccio un server http con
una sola linea di codice...
Allora, quello che devo fare, e` prendere i
sorgenti della libreria o, meglio, delle funzioni
che uso, e contarli insieme alla mia linea di
codice, cosi` ho un'idea di quanto effettivamente
quel linguaggio compatti.
Ovviamente, ammesso che la libreria sia scritta
nello stesso linguaggio, altrimenti hai ancora
un altro problema...
bye,
-- 
   Piergiorgio Sartor

 quel linguaggio compatti.
Ma neanche per idea, altrimenti dovrei considerare le linee di codice
del compilatore e poi la lunghezza dell'asm generato...
Io uso quello che mi danno assieme al linguaggio e basta.
Per voi no? Pazienza... Avrete tempo per capire che vi sbagliate :P.
PS: A scanso di equivoci la rimetto:   :P 


 python, pero` risolvi tutti i problemi di programmazione esistenti.
Evidentemente hai un concetto molto limitato di "tutti i problemi di
programmazione esistenti".
Ciao.

 python, pero` risolvi tutti i problemi di programmazione esistenti.
Vabbe` qua stai un po` esagerando tu ora :)
-- 
Lawrence

 linguaggio, almeno in python, non si separano.
Si si mi sta bene, era solo che nel nostro specifico caso
si parlava di linguaggio e non di libreria... quindi il paragone tra
Python e C++ non e` dei migliori
-- 
Lawrence

 PS: A scanso di equivoci la rimetto:   :P 
Lei non sa chi sono io!!!! :-)
bye,
-- 
   Piergiorgio Sartor

 sola linea del suo codice.
mbe ? Python ha due vantaggi su suddetto linguaggio.
1) Esiste
2) E' full purpose
Comunque si, volendo potresti farlo. Sarebbe un esercizio inutile,
pero'.


 (e non in Python stesso) ne è un'indiscutibile ed inconfutabile prova.
Che dici, chiedo direttamente a Koenig?
Ne deduco che l'asm sia molto meglio del C visto che il compilatore C
traduce qualcosa in asm. Stupidi noi che usiamo linguaggio di piu`
alto livello.
Io direi (e si capisce da 1000 considerazioni sbagliate che fai
pensando a python, come il fatto che non contenga la GUI nella sua
standard library) che sei uno stimatore di python, ma che non lo
conosci affatto, accecato dal fatto che per te esiste solo il c++ e
per qualche script python.
Come dice il mio, ormai ex, docente di Automatica, questo non fa
guerra a nessuno, preferisci il C++, puoi anche andare in giro a dire
che il C++ e` meno verboso e migliore di tutti gli altri, ma io ho il
diritto di dire che non e` vero (specialmente quando le persone da cui
prendo la mia particolare opinione, sono le stesse che vengono citate
in articoli dai quali tu prendi ispirazione)...


 pero'.
...di come si puo` misurare quanto un linguaggio
sia compatto rispetto ad un altro.
La regola di misurazione non deve poter essere
"aggirata", deve essere "assoluta", almeno nel
insieme dello spazio di misura.
Quindi, l'esempio di cui sopra, serve a sottolineare
che se non si opera una distinzione tra le librerie
ed il linguaggio stesso, si puo` arrivare a situazioni
limite, in cui la misura e` sempre uno.
bye,
-- 
   Piergiorgio Sartor

 insieme dello spazio di misura.
Ma tu quando programmi non usi librerie? I confronti vanno fatti
tenendo conto del mondo reale, non del mondo delle favole.


 tenendo conto del mondo reale, non del mondo delle favole.
Allora, per tornare al mondo reale, invece di
dirmi quante linee di codice il programma occupa,
dimmi quanta memoria flash devo comprare per
farcelo stare tutto.
Il problema e` simile, se preferisci, a quanti floppy
servono per farci stare tutto il sistema di sviluppo.
Se scrivo "printf()" in C, devo ben conscio che
quella cosa si trova altrove e _non_ dipende dal
compilatore quanto spazio occupa.
Mentre, sempre a livello di compilatore, posso
decidere se voglio codice compatto od altro.
Perche` allora il linguaggio piu` compatto e` sempra
lo scripting shell, che comunque usa 2 linee di codice
per fare qualunque cosa... Dato che tutto il SO che ci
sta attorno lo posso considerare parte del linguaggio,
al pari di librerie esterne.
Infatti nessun shell script funziona, si solito, senza
il supporto di "gawk", "cat", "sort", "grep", etc.
bye,
-- 
   Piergiorgio Sartor

 librerie si.
Oddio, se metti in conto le librerie c, o ancora peggio c++, non so che
impressione ne possa uscire.
Anche per quanto riguarda bash, mi devi mettere in conto binutils e
coreutils, e anche cosi' tante cose restano fuori ...
'nsomma ...
HAND,


 'nsomma ...
E` proprio questo il problema...
Se in bash considero lo script puro e semplice,
ho un linguaggio ultra compatto, ma se prendo
dentro tutti gli ammennicoli esterni, allora
sicuramente risulta ultra wide.
bye,
-- 
   Piergiorgio Sartor

 Non metto nemmeno mano sulla lentezza... è sparare sulla croce rossa...
La lentezza di Java e' una leggenda metropolitana, portata avanti da chi
non lo conosce.
Java e' un framework, alcune cose le fa bene, altre meno.
Come piattaforma per programmare applicazioni web lato server e' fantastico,
se fai un motore di rendering allora e' lento.
Una riflessione :
quelli della apache software fondation stanno portando avanti una miriade
di progetti su java, l'IBM e l'Oracle hanno fatto i loro Application servers,
perche' tutto questo interesse per un linguaggio cosi' lento ?
Ciao

 perche' tutto questo interesse per un linguaggio cosi' lento ?
Perchè su qualcosa si deve investire. Il C++ è stabile ormai. Java no.
Tant'è che alcune cose mi richiedono la 1.1.1 e non girano sulla 1.3.1.
Molto portabile (nel tempo): neanche una major release.
Le scelte non sono dettate dalla tecnica moltissime volte. IBM investe in
java e XML un po' --- per *moda* --- ma il suo mercato è il middleware
in C e fortran... alcune volte devono usare persino il cobol.


 Ovvero 5 linee contro 1, solo per scrivere hello world....
Non cinque, due:
#include <stdio.h> 
int main(){puts("Hello world!");return 0;}
 
E comunque nell'esempio semplice ci sta il semplice :) Il C ha pochi rivali 
sulla compressione del codice, si potrebbero fare infiniti esempi. Da 
questo punto di vista i linguaggi ad alto livello (come python) racchiudono 
n-istruzioni a basso livello in una singola istruzione, il che equivale ad 
usare delle librerie in qualsiasi altro linguaggio (compreso il C). 
Ovviamente non è questo il vantaggio di usare un linguaggio ad alto livello 
invece del C.

 GUI) ma questo non ha nulla a che vedere con il linguaggio.
mm non ne sono sicuro, ma semplicemnte, perchč non ci sono standard per 
queste cose, c'č posix ok, ma su quanti microcontrollori lo trovi? e se 
non hanno la rete come fai a mettere le socket? in generale hanno messo 
insieme il minimo, ovvero stanard input, output, algoritmi, e file. per 
il resto HW troppo diverso, anche se mi piacerebbe vedere prima o poi un 
ansi C++ 2004, o ansi C++ 200quel che vuoi che si comporto come SQL, nel 
quale vengono inserite altre feauture per ogni edizione, se uno non le 
vuole supportare implemnta una versione "vecchia" del 
linguaggio/librerie. prendi access, ad esempio lui supporta SQL89, ed č 
rimasto fermo li.

 Ogni tanto spuntano, su ICOD.
sarà fud, intanto per il multimedia si usa flash e non sistemi aperti. 
se con mozilla ho il 95% di compatibilità, rimane un 5% dei siti che mi 
danno dei problemi, o per javascript o per mille altre pistolatine. se 
apro la stessa pagina con IE(dopo aver chiuso gli 87426 finestre di 
pop-up) non da problemi. fino a quendo rimane così mi sta bene, ma se 
dal 5% dovessi passare al 20%, faccio fatica a dire alle persone passate 
al pinguino, è figo è bello ma vedete solo 80% di internet; oppure con 
"passate ad open office è figo è bello, costa poco",.... ah come dici? 
su word il font è in alto dx con altezzo 14 e so openoffice è in alto a 
SX con altezza 28, da una piccola stima abbiamo qualche migliaia di 
documenti e dovendo perdere 2 secondi per sistemare il font arriviamo ad 
un tempo uomo che fa in modo che se anche word costa, a noi costa di + 
usare open office a causa del tempo impiegato a risistemare il 
documento, quindi ci dispiace non possimao passare ad open office e 
quindi nemmeno a linux.

 insieme il minimo, ovvero stanard input, output, algoritmi, e file. per 
Beh, ma un microcontrollore potrebbe non avere file e
standard I/O, che sono comunque SO dipendenti od almeno
device driver dipendenti...
bye,
-- 
piergiorgio

 e C++ non fornisce buona parte delle funzionalita'
GTK e GTK+ per quanto ne so sono la stessa cosa. GTK e` una libreria
ad oggetti scritta in C (nessuno ha mai detto che ci vuole un linguaggio
ad oggetti per programmare ad oggetti... e` solo piu` comodo).
-- 
Lawrence

 in articoli dai quali tu prendi ispirazione)...
Ora mi pare che oltre a non aver capito l'articolo tu non abbia neppure
capito quello che ti ho detto in vari post...
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 Aggiungo un metodo a runtime quindi:
[cut]
Ahh!! Due esempi finalmente coerenti ed interessanti. Da chi te li sei
fatti suggerire o da dove li hai copiati?


 ad oggetti per programmare ad oggetti... e` solo piu` comodo).
Sante parole.


 rimasto fermo li.
Non saprei. Avevo visto un libro (ora non mi sovviene il titolo) che
spiegava proprio i perché che stanno dietro alla libreria del C++, ma
non l'ho preso perché non avrei avuto il tempo di leggerlo in questo
momento. Ma un giorno lo farň...


 ad oggetti per programmare ad oggetti... e` solo piu` comodo).
Non è solo più comodo. Programmare ad oggetti in un linguaggio senza il
supporto per la OOP (come il C) non è solo scomodo ma è anche privo di
molti dei vantaggi (quasi tutti) che la OOP offre.


 molti dei vantaggi (quasi tutti) che la OOP offre.
Si si certo... infatti io non ho mai programmato ad oggetti con
C... piuttosto uso un linguaggio con certi servizi :D
-- 
Lawrence

 fatti suggerire o da dove li hai copiati?
Hai una rosa di 3 risposte a tua disposizione dopo questo post. Non te
le elenco pero`, facciamo che le indovini tu.
Piuttosto noto che non hai postato un controesempio.


 Piuttosto noto che non hai postato un controesempio.
Infatti. Sono piuttosto stanco e non ne avevo voglia. 
Per quanto riguarda il primo esempio al momento non saprei come fare
(dubito che si possa), anche perché devo prima riuscire a 
comprenderne l'utilità. Per quanto riguarda il secondo è troppo lungo...


 server i dati pronti da inserire.
Per la portabilità e l'elaborazione distribuita peggior esempio dell'applet 
non lo potevi fare.

 fatti suggerire o da dove li hai copiati?
Comunque mi sto ancora ingegnando a imparare la metaprogrammazione,
con quella si possono fare sicurament molte altre belle cose.
L'esempio functomethod e` mio, l'altro invece l'ho preso dal cookbook
del python, l'autore e` Alex Martelli.


 cobol. 
Ma per piacere, smettiamola... :) che c'entrano quelle "robe" lì che hai 
citato con il mercato che copre la tecnologia di java?

 comprenderne l'utilità. Per quanto riguarda il secondo è troppo lungo...
Ottimo. Il problema e` che ho comunque usato la libreria in entrambi
gli esempi.
setattr fa parte della standard library, e` una funzione built-in.
super() e` anche lei una funzione built-in, per non parlare poi del
modulo che importo nel secondo esempio e che contiene gli operatori.


 una classe conosciuta a runtime in C++? Hai il reflection in C++? Puoi 
A proposito di reflection in C++.. stavo parlando con un ragazzo l'altro
giorno che mi spiegava che ci sono paper (con annessi ricercatori) che
spiegano come fare reflection a compile time in C++, grazie ai traits.  Se
vuoi appena lo ribecco mi faccio dare info piu` specifiche... se ti
interessa.
ciao!
-- 
Lawrence

 specifiche... se ti interessa.
E' interessante.

 in C e fortran... alcune volte devono usare persino il cobol.
Anche quelli di Apache seguono la moda ?
Persino Oracle...mannaggia... maledetta moda... :)
Ciao

 citato con il mercato che copre la tecnologia di java?
Sono 2 mercati diversi, vero... ma quello che dico, è che non è con java
che fanno i soldi! E' un investimento per ``pararsi il culo''... un ``sai,
non vale ma non si sa mai...'' :)


 che sperando di mantenere la binary compatibility.
L'OO non risolve i problemi. Ne crea altri, come qualunque cosa su questa
terra. Per alcuni compiti ripeto il c++ va bene, per altri mai.


 che sono meglio note come GTK.
GTK+  è l'insieme di { GTK, pango, ATK, GDK, Glib}
-- 
Best Regards,
Maurizio Colucci
Please remove the uppercase letters "S,P,A,M":
seSgPuAsM...@tin.it

 Persino Oracle...mannaggia... maledetta moda... :)
Anche loro.


 un ``sai, non vale ma non si sa mai...'' :)
Ma si... "Facciamo ad avanzatempo una piattaforma server in java con 
(tanto per passare il tempo) dei servizi web, non si sa mai di questi 
tempi servisse..." :)

 GTK+  è l'insieme di { GTK, pango, ATK, GDK, Glib}
Non ci avevo mai fatto caso, installandole sempre e per forza tutte
insieme pensavo fossero tutte parte delle GTK+.


 megahz per gestire la maggio pesantezza delle C++ rispetto al C
La pesantezza di un S.O. sia come prestazioni che, soprattutto come
occupazione di memoria è una grave e pregiudizievole condizione!
Inoltre c'è chi non può sempre comprare certi mostri e conosco tanti che
usano ancora un Pentium o un K6.
La tua voglia di C++ fortunatamente non dilaga tra i produttori di S.O.
anche se Windows riesce sempre ad essere pesante e richiede spesso
aggiornamenti hardware.

 (qt 3.x).
Intanto restringi alle 3.x... :) Poi mi piacerebbe vedere quali 
incompatibilità hai trovato in un programma scritto per java 1.1 su 1.4 
(che ci sono senz'altro, ma vorrei vederle...), poi eventualmente vedere la 
timeline delle qt 3.x (jdk 1.1 è uscito nel 97). Dulcis in fundo andiamo a 
vedere che Qt enterprise (quella che contiene i citati moduli database, 
opengl, XML, etc...) costa la bellezza di 2500$, sempre che non voglia 
compilare su due piattaforme (3700) o su tre (5000). 
Ah ti prego di non citare la versione GPL :) primo, perchè si parla di 
software commerciale e con la GPL non si può fare; secondo, perchè se 
scrivo un sw multipiattaforma mi sento un po' cretino se escludo Windows :)

 modulo che importo nel secondo esempio e che contiene gli operatori.
Chiarisco la mia risposta perché era piuttosto ambigua. Giovedě ho un
esame (sě, nonostante la mia etŕ ho deciso di ritornare a studiare) e
quindi non ho il tempo (e neppure la voglia in questo momento) di
rispondere a post che richiedano piů di 30 secondi per la scrittura...
Ci ritornerň in seguito.


 meglio usare il C o l'assembly (che non è OOP, come mai lo usano?).
http://www.eptacom.net/formazione/ppeff.html


 Ci ritornerò in seguito.
Ok, in bocca al lupo allora :). 
Io non starei troppo a preoccuparmi di questo thread comunque :).


 Ok, in bocca al lupo allora :). 
Crepi!!!


 
http://www.eptacom.net/formazione/ppeff.html
Tu spesso riporti questo "eptacom", che pero`,
evidentemente, non ha mai realizzato, chesso`,
un filtro real-time per immagini...
bye,
-- 
piergiorgio

 
http://www.eptacom.net/formazione/ppeff.html
Ma non intendeva mica questo... 


 un filtro real-time per immagini...
No, ha solo realizzato numerose applicazioni in campo medico che, come
tutti sanno, non necessitano di particolari attenzioni...


 Ma non intendeva mica questo... 
A me pare proprio di sě...


 tutti sanno, non necessitano di particolari attenzioni...
Non necessariamente real-time e comunque sicuramente
non cost-effective, cioe` dove mettere 1MB o 2MB o
16MB di memoria e` un problema.
Le "particolari attenzioni", non sono quelle il cui
post di sopra si riferiva ed il fatto che tu le
menzioni, significa solo che non le conosci.
Queste "affermazioni" sono solo marketing, di chi
vuole vendere un prodotto ed ovviamente non puo`
certo dire che vi sono limitazioni.
E` una vecchia storia, che ogni markettaro che
viene dalle mie parti ripropone: si usa C/C++,
c'e` Java...
Poi pero`, alla fine, uno deve smazzarsi C ed
assembly, altrimenti non funziona niente oppure
non ci sta in memoria...
bye,
-- 
piergiorgio

 perciò avere i beans...
Ecco, mi allaccio a questo per ribadire la mia posizione.
Oggi Java e' ottimo per la programmazione web, insomma il mondo j2ee,
e qui non e' lento.
Per applicazione stand-alone non e' il massimo, ci sono alternative
ugualmente produttive (python) o piu' efficienti (c++).
Ma il supporto c'e', e presto java sara' maturo per essere utilizzato in modo
produttivo anche in questo ambito.
Ciao

 tempi servisse..." :)
LOL

 
http://www.eptacom.net/formazione/ppeff.html
Sempre confutato in pratica... se n'è discusso su parecchi NG.
Il documento che citi lo conoscevo gìà, mi sembra che ci siano anche esempi
con dei sort realizzati che avvalorino la tesi... nella pratica ti sfido a
scrivere due programmi equivalenti (che non sia un esempietto di poche
linee) in C e in C++ (non C++ like C, con contenitori e via discorrendo) e
verificare!
Evidentemente nei programmi che scrivi non c'è la criticità di ricorrere a C
o assembly, fidati... è così!
Non basta dire di scrivere programmi per la medicina... ogni programma ha
proprie criticità che guidano sulla scelta del linguaggio e sul metodo di
programmazione... Penso d'avere sufficiente esperienza per affermare ciò!

 insieme pensavo fossero tutte parte delle GTK+.
Infatti č cosě :-)


 programmazione... Penso d'avere sufficiente esperienza per affermare ciò!
Io non metto in dubbio la tua esperienza, per carità, non ho alcun
motivo per farlo, però permettimi di dare più credito ad una persona
come Pescio.


 non ci sta in memoria...
Direi proprio che qusto non è il caso. Mi pare ovvio che non conosi la
persona di cui si sta parlando.


Scusami, ma io non conosco costui.
Comunque non devi darmi credito, non lo pretendo, era un modo di dire...
prova tu stesso comunque non dare crediti !
Scrivi codice e compila... io lo faccio spesso!

 Scrivi codice e compila... io lo faccio spesso!
Credi forse che io non lo faccia?


 ed inoltre non me lo ricordo bene. Dovrei ritrovarlo.
Nelle applicazioni mediche, in generale, quello
che conta e` la robustezza e l'affidabilita`.
Il dispositivo deve funzionare, dato che uno stop
potrebbe portare a risultati catastrofici.
Pero` il costo non e` un problema, basta vedere a
quanto questi macchinari sono venduti.
Se serve un raid 5 in flash, si fa, non c'e` problema.
In questo senso, gia` mi preoccuperei di sapere
quanto affidabile sia il compilatore...
Comunque, quello e` un caso, ve ne sono altri in cui,
nonostante la volonta`, non si puo` _ancora_ usare
linguaggio di livello piu` alto del C.
Certo, puo` essere che, come si e` passati (quasi
completamente) dall'assembly al C, un giorno si
passera` dal C al C++ (in questi casi specifici).
bye,
-- 
piergiorgio

 parzialmente in C++.
buondì! mi trovavo a passare di qua. Il solo problema del C++ è che è 
enorme. Basta fare una scelta assennata del subset che se ne intende 
usare (sì per la STL se l'implementazione mantiene certi contratti non 
scritti ma dettati dal buon senso; sì per le funzioni stateless della 
runtime C; secco no a tutto il resto: i problemi di rientranza in un 
ambiente a memoria condivisa, free-threaded e che condivide il contesto 
con gli interrupt handler sono da perderci la lucidità), e non ci sono 
problemi. Chi dice altrimenti <juliet>non capisce un cazzo</juliet>
C++, in fondo. è solo C poco prima della digestione (stessa sostanza, 
parti semanticamente distinte ancora distinguibili fisicamente, aspetto 
non rivoltante)... più certe, anzi, una feature altamente discutibile: 
le eccezioni. Che più che feature sono un requisito. E più che 
requisito un albatross morto da portarsi appeso al collo. Il bello del 
C++ è che non richiede infrastruttura, ci siamo? a parte un allocatore 
e la costruzione degli oggetti static prima che main() venga chiamata, 
non serve altro. Niente cose strane che dipendono da funzioni magiche o 
da database relazionali o da file di configurazione o dalla fase lunare 
attuale. Codice puro. Non è fantastico? no, ho mentito spudoratamente. 
Ci sono le eccezioni. Il signor Hejlsberg, nel progettare C#, ha 
inquadrato il problema perfettamente - ha "colpito il chiodo proprio 
sulla testa", come dicono in America. Leggete cosa dice sulle 
eccezioni:
"[...]
It is funny how people think that the important thing about exceptions 
is handling them. That is not the important thing about exceptions. 
[...]  In the finally, you protect yourself against the exceptions, but 
you don't actually handle them. Error handling you put somewhere else. 
Surely in any kind of event-driven application like any kind of modern 
UI, you typically put an exception handler around your main message 
pump, and you just handle exceptions as they fall out that way. But you 
make sure you protect yourself all the way out by deallocating any 
resources you've grabbed, and so forth. You clean up after yourself, so 
you're always in a consistent state. You don't want a program where in 
100 different places you handle exceptions and pop up error dialogs. 
[...] The exception handling should be centralized, and you should just 
protect yourself as the exceptions propagate out to the handler.
[...]"
Ha ragione lui. Non negatelo: il vostro codice C++ fa schifo. E' pieno 
di rethrow e inutili specifiche throw nei prototipi delle funzioni, e 
la sua vicinanza prolungata fa abbaiare i cani e piangere i bambini
Non che le eccezioni siano un concetto malvagio in sè. E' che con C++ 
non han niente a che fare. Un linguaggio così aggressivamente teso a 
sbilanciare il carico di lavoro sulla fase di compilazione, l'unico 
linguaggio che possa implementare il polimorfismo statico, si ritrova a 
dipendere da un meccanismo per la determinazione a run-time del tipo di 
un oggetto. Che schifo. Non che ce la si possa cavare con un valore 
magico che faccia da identificatore: le eccezioni vanno copiate, quindi 
servono la dimensione dell'istanza e puntatori a costruttore e 
distruttore (che quindi non possono più essere inlineati), quindi il 
compilatore deve generare tonnellate di spazzatura per descrivere ogni 
singola classe abbia la sciagura di finire in un throw o in un catch. 
Per non parlare della quantità e della complessità delle funzioni 
magiche necessarie, ovviamente incompatibili tra compilatori e quindi 
non raccoglibili in un'unica libreria. Insomma, è un casino. Da un lato 
fanno comodo, dall'altro appesantiscono (sotto tutti i punti di vista: 
aggiungono indirezione, aggiungono metadati probabilmente inutili, si 
tirano dietro più libreria di runtime, ecc.). Si potrebbe limitare il 
tipo di eccezioni sollevabili ad uno solo, intrinseco al compilatore, 
magari con associato un limitato allocatore, tanto per assegnare dati 
arbitrari all'eccezione, e (se serve) fare polimorfismo alla maniera 
povera, con switch o simili (sì, sto pensando ad un wrapper *molto* 
sottile per SEH e i suoi EXCEPTION_RECORD - ma mi viene difficile 
immaginare un altro modo per implementare le eccezioni). Ma dovrebbe 
avere, sintatticamente, lo stesso aspetto delle normali eccezioni, 
oppure no?
Questo è quanto, per quel che mi riguarda. L'unica, vera differenza a 
livello binario tra codice C++ e C è nelle eccezioni. Non usandole, la 
differenza è zero. Beh, C++ distrugge automaticamente gli oggetti 
allocati sullo stack, e quindi, tanto per dirne una, costruisce un 
frame SEH molto diverso, gestito (parlo di Microsoft C++, che è il più 
documentato dei non documentati) da _CxxFrameHandler, funzione molto 
più complicata di _except_handler3; ma, se conosciamo la forma del 
frame SEH usato - e la conosciamo - non è difficile sostituirla con 
un'implementazione che faccia solo l'unwinding (se è lo snellimento 
dell'infrastruttura ad interessarci - e ci interessa, perchè il punto è 
un kernel in C++, o comunque codice embedded, e l'infrastruttura ci 
piacerebbe vederla perire tra atroci sofferenze). Dite che i metodi 
virtuali aggiungono indirezione e disattivano l'inlining delle chiamate 
a funzione? beh, ma è lo stesso per il C. In C, se possibile, è più 
grave, perchè il tutto è type-unsafe e il compilatore è all'oscuro 
della semantica che avete in mente
In generale, l'indiscutibile superiorità del C++ sta nella sua maggiore 
espressività come linguaggio: se il C ci permette solo di dire *come* 
fare, il C++ ha un discreto vocabolario per spiegare al compilatore 
*cosa* fare (vedere anche: C# contro Java), *senza* rinunciare alla 
fondamentale purezza che tanto viene apprezzata del C
PS: consiglio a tutti di dare, prima o poi, una passata di disassembler 
al codice C o C++ che credevate efficiente e time critical. Vedere 
quanto il compilatore ha capito delle vostre intenzioni e quanto è in 
grado di esaudirne - perchè il compilatore, e non il capo progetto, o 
la "comunità", è lo spettatore da conquistare - è sempre istruttivo

 linguaggio di livello piu` alto del C.
Questo non lo metto in dubbio.
Comunque, tanto per tornare al discorso efficienza, d'accordo che le
applicazioni per i telefoni cellulari non devono essere real-time, però
in questo campo sta prendendo (purtroppo) campo Java, che per quanto
riguarda l'efficienza non è certo il massimo, anzi...
Eppure anche i tel. cellulari hanno risorse ben limitate...


 Eppure anche i tel. cellulari hanno risorse ben limitate...
Occorre valutare il problema per capire la soluzione. L'obiettivo era avere 
sui cellulari un sistema programmabile e grafico. Tieni conto che (per 
quanto ne so) la jvm sui cellulari *costituisce* il sottosistema API, a 
differenza dei personal computer dove in molti casi (grafica, in 
particolare) č un overhead.  Francamente non vedo perchč una jvm calata in 
questa situazione debba essere considerata cosě inefficiente (naturalmente 
nel contesto sottituisci "java" con qualsiasi altra tecnologia analoga).


f u cn rd ths u r usng unx

 produttivo anche in questo ambito.
Spero di no :) Un linguaggio senza pointer mi sa di aberrazione... :)


 Infatti non mi pare che l'ibm stia facendo avanzare la piattaforma.
Ah no? Stai dicendo che "ti pare" che IBM sta abbandonando le soluzioni 
web services? O forse che sta puntando su altre tecnologie? 
Prego, sei entrato nel ginepraio... ora ci esci da solo con le tue parole 
:)
 

 Credi forse che io non lo faccia?
Perfetto! Allora dovresti spiegarmi come fa il codice C++
#include <iostream>
#include <string>
using namespace std;
int main(int argc, char* argv[])
{
        string p("PROVA CODICE IN C E IN C++");
        string::iterator it;
        int n=0;
        for (it=p.begin();it!=p.end();it++)
                if (*it=='C') ++n;
        /* ALTERNATIVA
        const char* s=p.c_str();
        int n=count(s,s+p.size(),'C'); // inserire #include <algorithm>
        */
        cout << "Nella stringa : " << p << ", ci sono " << n << " lettere
C\n";
        return 0;
}
ad essere più efficiente del codice C
#include <stdio.h>
int main(int argc, char* argv[])
{
        char *p="PROVA CODICE IN C E IN C++";
        char c;
        int n=0;
        printf("Nella stringa : %s, ",p);
        while ((c=*p++)!=0)
        {
                if (c=='C') ++n;
        }
        printf(" ci sono %d lettere C\n",n);
        return 0;
}
Il codice C compilato con il mingW / gcc è 15Kb, mentre il primo, C++,
sempre con mingW / g++ è oltre 400Kb.
Se guardi il codice C è il massimo dell'efficienza... Niente è inutile (è un
piccolo capolavoro il C, ma non il mio esempio che fa schifo, ma il fatto
che in un buon programma scritto in C non c'è un'operazione in più di quella
che deve essere compiuta per il raggiungimento del risultato)!
Guarda: p è un puntatore ad un'area di memoria che contiene un testo ed
accede direttamente in quell'area di memoria, un programma in assembly
farebbe lo stesso! La memoria viene scandita e incremente un numero.
Generalmente accade lo stesso con le strutture tipo C dove basta passare un
puntatore e non ti porti dietro ingombranti metodi.
Attenzione: non sto discutendo i vantaggi del C++, che è comunque il mio
linguaggio di programmazione preferito, né i contro dei programmi in C! Io
ti parlo solo di efficienza (cioè intendo, stesso risultato, meno memoria
occupata e minor numero di operazioni per arrivare al risultato).
Il programma in C++ deve istanziare una classe! Vuol dire che si copia
l'array di caratti in una zona protetta (operazione in più non richiesta, a
noi non serve). Al di la della mia discutibile scelta di utilizzare gli
iteratori (avresti potuto ottenere un char* col metodo c_str() e fare la
scansione proprio come in C per ottenere prestazioni migliori), ma che però
è una delle più preziose features del C++ o magari gli algoritmi standard
del C++ come presentato nell'alternativa come ad esempio std::count!
Quindi, quello che ti voglio dire io, e mi sembra che anche altri hanno
tentato di spiegarti, è che in un PC e per applicazioni non real-time o per
il software engineering, frega niente! Ma ci sono sistemi embedded con poca
memoria e non certo con un P4 da 3 Ghz, applicazioni che sono a corto di
velocità e non possono permettersi sprechi, dove il C è preso in
considerazione COME UNICA ALTERNATIVA ALL'ASSEMBLY (che notoriamente non è
in concorrenza con il C++).
Poi, tu e Pescio rimanete con le vostre convinzioni... ma le cose nella
realtà vanno in modo differente!
Saluti.

 
il C++ va bene per qualsiasi cosa, il problema è che il debug è talmente 
costoso per certi applicativi che non viene fatto in modo serio, magari 
per motivi di budget

 per motivi di budget
Beh, il debugging si fa, si deve fare... manco in java puoi NON fare il
debug. In nessun linguaggio può esistere 'sto lusso.



allora mi permetto di precisare qualcosa, visto che nel 2002 ho fatto la 
tesi di laurea sulle performance dei sistemi j2me, ovvero java per 
cellulari pda etc, sviluppando un applicativo grafico/matematico.
Java di per se non è un mostro di velocità, ma non è particolarmnte 
lento, il problema di java è che occupa un sacco di memoria, 
specialmente per quanto il JIT. quello che succede è che oggi quasi 
tutti i produttori usano ARM come microprocessore, che invecie di 
implementare una FPU (in quel mercato i calcoli per interi vanno + che 
bene) utilizza una milionata di transistor per fare il JIT via hardware, 
morale della favola, un programma in C/C++/JAVA va alla stessa velocità 
in quanto viene tradotto tutto in linguaggio macchina; in C lo fa il 
compilatore sw, in java dal JIT hw. il vantaggio che java avendo una 
serie di librerie standard, ed essendo molto ad OO, a runtime alla fine, 
gli applicativi tendono ad occupare meno memoria di quelli C++. per 
quanto riguarda le performance grafiche tenete presnte che non si usano 
ne awt ne swing, ma una serie di api ottimizzate per andare in bassa 
risoluzione, per qunto riguarda i widget standard. mentre come nel mio 
caso, se ti vuoi fare cose strane di grafica, ti dannno l'equivalente 
dei canvas e poi ti dicono disegna tu con line, circle, bit blit etc, 
quello che ti fa bestemmiare è che secondo speicifca il canvas si 
comporta in modo all'atto pratico a senconda del cellulare ci sono 
enormi differenze. morale della favola writre once, test everywhere, and 
  ajdust 10% of the code according to the device.

 nel contesto sottituisci "java" con qualsiasi altra tecnologia analoga).
Perché Java è "disegnato" in modo da essere inefficiente.
Non so come sia l'hw di un cellulare e se anche qui, come in un PC,
influisce il fatto che tutti gli oggetti siano allocati sull'heap, ma il
fatto che il linguaggio obblighi ad avere un elevato numero di cast (a
runtime) è sicuramente un peso non indifferente anche su hw dedicato.


 :)
No, vorrei sapere perchè sui servizi basati su http si può solo parlare
di java. Che ha di tanto speciale? Solo che non devi ricompilare? Non mi
pare un incremento enorme... è un tempo speso ``una tantum'', non
ripetutamente...


 ad essere più efficiente del codice C
[cut]
Da quello che affermi direi che o non sei mai andato avanti nella
lettura di un articolo che spiegava come il C++ può essere più
efficiente del C, fermandoti al titolo, o se l'hai letto, lo hai fatto
con superficialità e poca attenzione.
Nessuno ha mai affermato e né (salvo future e miracolose evoluzioni dei
compilatori C++) affermerà mai che il codice C++ che hai scritto possa
essere più efficiente (più veloce potrebbe anche esserlo) del codice C
che hai scritto.
I discorsi sono *ovviamente* riferiti ad un applicativo complesso nella
sua interezza, dove l'utilizzo di adeguate astrazioni può risultare (e
spesso lo è) più efficace della scrittura di codice solo a "basso 
livello".


 lento, il problema di java è che occupa un sacco di memoria, 
Il problema di Java è il linguaggio stesso che obbliga a effettuare un
numero spropositato di cast a runtime...


 livello".
Questa è una bufala! Non è nulla che puoi dimostrare e nella pratica viene
smentita!
L'efficienza di un codice è la somma delle efficienze della varie parti del
programma.
Se poi uno è un cane a programmare in C allora questo è un altro paio di
maniche!
Secondo me si stai tentando di paragonare un pessimo programma in C con un
ottimo programma in C++ !!!
Il C++ NON AGGIUNGE NIENTE che con un programma in C non si possa fare!
Pensa che i primi compilatori di C++ riscrivevano il codice in C! Il
problema è che lo riscrivevano in modo inefficiente! Ecco perché ora sono
migliorati sensibilmente!
E' troppo facile dire che quello è un esempio stupido e non fa testo... In
realtà anche negli algoritmi più complessi ci sono una serie di operazioni
più semplici.
Prova a lavorare con grossi contenitori vector, list e stack: prova a
incapsularli es vector<vector<int> > oppure a non avere sempre e solo due o
tre contenitori ma centomila? Prova ad averne un'esagerazione...
Prova a vedere cosa succede al tuo codice C++? Prova a vedere con il task
manager cosa succede alla tua memoria run-time!?!?
Quasi sempre va bene ma quando cominci ad avere tabelle con migliaia e
migliaia di dati allora o sei disposto a sprecare megabytes di memoria
oppure ritorni ai puntatori C !! Ho provato ma non posso postarti il codice
di centinaia di linee.
Gli esempi devono per forza essere "stupidi" ma la tua obiezione non è
corretta!!
Sarebbe come dire che C è inadatto a gesire progetti di grandi dimensioni
perché diventa inefficiente!?
Ci scrivono S.O. in C (con larghe integrazioni di assembly e non C++), e non
sono proprio stupidi come il mio esempio! Sono scritti in C ad oggi perché
non c'è tempo e memoria da perdere (e quindi serve EFFICIENZA, che non è il
numero di linee che devi scrivere, è un'altra cosa) !! Forse domani saranno
scritti in C++ ma non perché sarà il C++ più veloce ma forse perché memoria
e tempo potrebbero non essere più delle criticità!
Ma prova anche a listare le classi (c'è il codice), prova a dimostrare che
la classe è più efficiente di una struttura tipo C dove scrivi direttamente
nei membri il valore con un semplice accesso diretto alla memoria.
Dire che il progetto diviene difficile da portare avanti in C e quindi in
C++ diviene più veloce vuol dire che il programmatore C compie degli errori
o non è preparato, altrimenti se fa le cose fatte bene come gli sviluppatori
di S.O. come UNIX (e in parte anche Windows) hanno fatto non ci sono proprio
c***i ! Windows e Unix NON SAREBBERO PIU' VELOCI SE RISCRITTI IN C++!
Sostenere questo vuol dire essere blasfemi.
L'ultima parte che hai scritto è poi un'aberrazione!
Un'astrazione ad alto livello NON PUO' essere più veloce di un programma
ASSEMBLY per il semplice motivo che quando hai compilato il C++ diventa
basso livello e quindi assembly. E' chiaro questo?
Se questo è chiaro, procediamo: il programma in C è molto più vicino di un
programma assembly di quanto (per definizione) lo sia un programma in C++.
Ne consegue che un buon programma C non può IN NESSUN MODO girare più
lentamente di uno scritto in C++ ! Guarda che questo non lo ha ancora
dimostrato nessuno!
Accetta il fatto che C++ è adatto per tantissime cose ma non per tutto!
Tra l'altro ho anche avuto l'impressione che ci sia un conflitto d'interesse
in quel Pescio (secondo me quella è una posizione che deve difendere a tutti
i costi)! Non può essere imparziale. Tanti sviluppatori invece sono
imparziali.
Quello che si può dire è che nel 99.99% dei casi si potrebbe dire: - "E chi
se ne frega?".
Ma ce ne freghiamo solo se non hai applicazioni CRITICHE per velocità e
occupazione di memoria!
Ri-saluti!

 imparziali.
ROTFL. Ma se non sai neppure chi è Pescio...


 sempre con mingW / g++ č oltre 400Kb.
Due appunti il linea e l'osservazione che con gcc il codice C č 4,6K ed
il corrispondente C++ č 7,3K. 
Non vale usare compilatori penosi...


 ROTFL. Ma se non sai neppure chi è Pescio...
Discutere va bene ma non mi prendere in giro...ho cercato con google... e un
certo interesse nel dire quel che dice ce lo trovo!
"Eptacom Consulting è uno studio professionale specializzato nella
progettazione di sistemi con tecnologie object-oriented. Lo studio, nato nel
1991, è di proprietà di Carlo Pescio (noto per le sue pubblicazioni su
object technology, C++ e software engineering, e membro dell'ACM, dell'IEEE,
e dell'IEEE Technical Council on Software Engineering), che cura in prima
persona gran parte delle attività di consulenza, formazione, progettazione e
mentoring."
E' chiaramente uno che ha interesse a dire che il vino che produce è buono!
Io non ho nessuno studio professionale e non devo difendere niente e
nessuno.
E' tutto marketing... ROTFL!!

 Non vale usare compilatori penosi...
Con cosa lo compileresti sotto Windows?
Pescio non programma con Windows cosa usa compiler Intel?
Il MingW32 è un porting del gcc e gode di un'ottima critica per tua
conoscenza!

 E' tutto marketing... ROTFL!!
Già, se ti fermi alle prime righe...
Guarda un po' gli articoli che ha scritto per alcune tra le riviste più
prestigiose negli USA, o per le riviste Infomedia prima che il loro livello 
qualitativo si abbassasse (casualmente proprio con la dipartita di Pescio...). 
È un esperto riconosciuto a livello internazionale. Però per te è solo 
marketing...


 Ciao.
Scusa ma se mi provochi dandomi dello scarso...
Niente di personale, sei molto caparbio... ma non mi convinci!

 Con cosa lo compileresti sotto Windows?
VC++?


 più alto del C!
Ti sfugge che lo stai linkando ad una libreria sviluppata per i PC?


 Ciao.
Da un certo punto di vista provo quasi stima per te e la tua capa tosta,
tralasciando la tua totale incompetenza informatica.
So che in altri casi hai convenuto che non c'è posto sempre per linguaggi di
un livello più alto del C (e si parlava di real-time) !
Poco cordialmente,
F.P.

 Ti sfugge che lo stai linkando ad una libreria sviluppata per i PC?
Questo avrebbe dovuto farti capire come un programma C++ può diventare
pesante senza che tu te ne accorga!
Ascolta tu avevi detto che il tuo compiler fenomeno lo fa in 9 Kb, anche il
mio se lo linko dinamicamete, ma sembre eseguirai quel codice in più, anche
se non te lo vedi nell'eseguibile!
Viene linkato tutto quello che serve con -static, no? Quindi questo dimostra
che, almeno, su di un PC un programma in C++ occupa molte più risorse!
Quel codice in più verrà eseguito o sta lì per l'anima del c***o ??
Bene, sappi che con il C tutta quella roba non la esegui!!

 Oppure c'è la scuola fai da te/lo chiedo a Pescio!
Veramente che Gnome manchi di reattività è un problema che fanno notare
in molti (e se vuoi essere sicuro che non siano commenti di gente di parte
puoi guardare i commenti su 
gnomedesktop.org
 ogni volta che si parla di
aggiornamenti alle GTK+) e su cui da utente Gnome sono pienamente
d'accordo. KDE è decisamente più reattivo (anche se più lento a
caricare, e c'è da dire che Gnome 2.4 non è proprio un fulmine nemmeno
sul caricamento iniziale).
See you,
	Silver Drake
-- 
http://www.silverdrakenet.it

 un livello più alto del C (e si parlava di real-time) !
??? 
Non riesco a capire se sei un troll o se sei semplicemnete ignorante.


 Bene, sappi che con il C tutta quella roba non la esegui!!
Informati su cosa sia il linking dinamico e poi, magari, ne
riparleremo...


 molti dei vantaggi (quasi tutti) che la OOP offre.
Strano, Mark Thomas individua diversi problemi nell'utilizzo di C++ per
il suo Y.
<cite>
[...]
First, in order to provide remote access over simple communication
channels, such as those based on message passing, it will be necessary
for each class to provide a virtual table of method-name to function
pointer mappings, for example:
canvasTable = {
    {"drawLine", addr_of_canvas_Drawline_function},
    {"drawRectangle",, addr_of_canvas_DrawRectangle_function},
    ...
};
To invoke a method, the interprocess-communication layer will search
this table (if the table is kept sorted, then a binary search can be
employed for O(log2 n) lookup time), find the appropriate function
pointer, and call it on the object that the call pertains to.
Unfortunately, this is not possible to express whithin the constraints
of the C++ type system; pointers to members cannot be subsumed under the
type of their receiver, that is a member pointer '&Canvas::drawLine'
which is of type 'void Canvas::* (...)' cannot be safely converted to a
pointer of type 'void Object::* (...)' even though Canvas inherits from
Object. This restriction only applies to receiver types; function
pointers can be subsumed under the basis of their return or argument
types.
Second, interfacing modules to C++ is difficult. This is due to how C++
is based on C. C++ identifiers are 'mangled' into C identifiers in order
for classes to have the same functions, and to allow polimorphism. For
example, a method with the C++ signature 'void Canvas::drawLine (int,
int, int, int)' might be mangled to '_ZN6Canvas8drawLineEiiii'. This is
not helped by the fact that the mangling format depends on which version
of which compiler the module is compiled with.
Third, C++ does not provide some of the object orientation features that
are desirable for the implementation of a window system. It does not
provide get and set modifiers on fields, and it does not provide a
loosely coupled event signalling system. Both of these can be
implemented using large numbers of template classes, but this causes
code bloat as new versions of the same class definition have to be
created for each concrete type that the template is used for.
For these reasons, it is better to implement the desired features
directly. [...]
</cite>
Il pdf e' sul suo sito, semplicemente non lo trovo piu' ...
HAND,
-- 
                                                __Nicholas Wieland
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
                                                __The Zen of Python

 Silver Drake
Ciao Drake!
Veramente io sono rimasto alla vecchia Gnome, non la 2.
Mi fido di quello che dici, non ho ragione di dubitarne.
Mi pare, però, se non erro che le versioni 1.x sembravano invece più veloci
(ma anche più essenziali, con meno fronzoli) di KDE. Così anche le
impressioni di altri utenti che avevo registrato risalgono a tal livello
d'aggiornamento.
Comunque mi fido a tal punto che non aggiornerò Gnome.

 Comunque mi fido a tal punto che non aggiornerò Gnome.
Secondo me non ci fai un gran affare. 
Gnome ora è sicuramente più lento di prima (ovviamente a parità di
hardware, c'è da dire che con la dovuta lentezza l'ho usato anche su un
P200 con, se ben ricordo, neanche 128 MB di RAM), ma è anche vero che ha
diverse cose positive: l'usabilità dell'interfaccia è elevatissima, la
pulizia e l'ordine sia dal punto di vista grafico che di
organizzazione/opzioni/ecc decisamente maggiore di KDE e in generale anche
le applicazioni hanno un look più "leggibile". Certo, se vuoi una
maggiore reattività e più opzioni "visibili subito" KDE ora è meglio,
ma personalmente non mi pento affatto di essere passato a Gnome 2 (e quasi
tutte le applicazioni che uso sono non solo GTK ma anche direttamente
legate a questo DE).


 Comunque mi fido a tal punto che non aggiornerň Gnome.
(bravo <g>)
-- 
il Vide - ICQ# 5301833
IAMM - it.arti.musica.metal 
http://www.heavy-metal.it
"There is no stronger drug than reality"

 Comunque mi fido a tal punto che non aggiornerò Gnome.
Male. Io usavo Xfce4 qualche giorno fa. Per ridere/esperimento ho
installato GNOME 2.5.3 e direi che non torno a xfce4.
Hanno aumentato parecchio la velocita`, questo almeno sul mio
portatile.
E` ancora una beta release ma ho 2 giorni di uptime senza il minimo
errore. Mi sembra anche parecchio veloce.
E` anche parecchio responsivo, veramente.
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Gentoo Proud User

 E` anche parecchio responsivo, veramente.
Bella notizia, io sono ancora all'ultima sottoversione della 2.4 e non
vedo l'ora (per non parlare del file selector...)


 errore. Mi sembra anche parecchio veloce.
Io, piuttosto, credo da 2.4, ho un problema con "gnome-panel"
ed i workspace.
Quando clicco su di un workspace, questo viene si selezionato,
ma le finestre al suo interno vengono "spostate", in funzione
di dove clicco, cioe` il centro del WS non e` fisso.
Cosa parecchio fastidiosa, tocca usare ctrl-Fx per cambiare WS.
Ho chiesto in giro e mi hanno detto che e` un bug, ma c'e` da
qualche versione, possibile che non vi sia un fix?
Oppure e` una feature e non so come "spegnerla"...
Any hints?
bye,
-- 
   Piergiorgio Sartor

HPL,
francamente non andrò oltre in quella che non è più una discussione.
Non è nemmeno il fatto che hai molte lacune a suggerirmi di finirla, quanto
il fatto che a differenza dei miei argomenti e delle motivazioni con le
quali mi supporto, le tue risposte sono diventate da qualche post a questa
parte sempre prive di qualsiasi motivazione e unicamente "contro". Sei
agnostico!
Le tue gravi lacune sono poi legate dall'enorme filo di supponenza che ti
ritrovi.
Non è possibile discutere così.
Non contesto Pescio che ha il diritto di scrivere (e ne avrà pure titolo,
non lo metto in dubbio) quello che scrive e in parte lo posso pure
condividere: io contesto te e le cose che fingi di sapere ma che non dici o
che quando provi a dirle toppi clamorosamente!
Dai da intendere d'essere un fenomeno ma non sai cose troppo elementari
(guarda caso di natura pratica)  per uno che afferma d'essere tale.
Non posso saperle io che sono un umile programmatore e tu che sei un
fenomeno non averne mai sentito parlare o fingere di sapere tutt'altra
realtà!
Siccome io non risponderò più a provocazioni sterili del tipo "Informati",
"Sei tu che non sei capace" oppure "Sbagli perché non conosci il C++" ed
altre cose (e premesso che io continuo sempre ad informarmi e non vedo la
cosa vergognosa affatto, forse è per questo che sono più aggiornato) mi
limito solamente a dimostrare che ti sei sbagliato più volte.
Prima stupidaggine: hai affermato (testuali parole) - "No, affatto. Perché
ti sfugge una cosa. A parte che il C++ (od il C) compilato non diviene
assembly, ti ricordo che le astrazioni servono
all'uomo, non alla macchina.".
Il C e il C++ compilati divengono programmi in ottimo assembly, come di vede
utilizzando un qualsiasi debugger. Ti avevo anche suggerito d'informarti
vedendo alcuni esempi al sito
http://www.azillionmonkeys.com/qed/asmexample.html
 ma chiaramente su questo
hai glissato.
Seconda stupidaggine: la questione dell'iteratore e del suo incremento nel
ciclo for.
Affermi che
for (string::iterator it=p.begin(); it!=p.end(); ++it) è diverso da
for (string::iterator it=p.begin(); it!=p.end(); it++)
(ometto per ora il codice dentro l'iterazione, l'avevo già scritto
precedentemente)
Anche questa è una toppata favolosa!
Questa distinzione non esiste più con i moderni compilatori.
La dimostrazione è questa.
I due cicli for di sopra sono esattamente equivalenti, rispettivamente a
questi.
for (string::iterator it=p.begin();it!=p.end();)
{
                if (*it=='C') ++n;
                ++it;
}
e
for (string::iterator it=p.begin();it!=p.end();)
{
                if (*it=='C') ++n;
                it++;
}
Secondo te la prima forma sarebbe quindi da preferire, ma al di la della
scelta stilistica non c'è motivo per farlo.
In effetti l'iteratore del comando for viene sempre eseguito dopo l'
istruzione (o il gruppo d'istruzioni se c'è la graffa).
Il compilatore, rendendosi conto che il valore temporaneo NON GLI SERVE A
NULLA per quello che deve fare nel codice iterato, incrementa l'iteratore
come meglio può fare (quindi sempre e comunque nello stesso modo).
L'ho scritto nei due modi e ho ricompilato l'esempio che avevo fatto e ti
faccio vedere il codice che si vede utilizzando un debugger. E' lo stesso
identico nei due casi!
Quindi tutti i tuoi voli pindarici sugli iteratori mostrano che hai nel
cervello un insalatone di teoria ma non hai assolutamente pratica sulle cose
che dici. E' l'insalatone è pure insipido!
main.cpp.14 it++;
004012D2 FF45B8           inc dword ptr [ebp-0x48]
004012D5 8D4DE8           lea ecx,[ebp-0x18]
004012D9 E82A010000       call _STL::basic_string<char,
_STL::char_traits<char>, _STL::allocator<char> >::end()
004012DE 59               pop ecx
004012DF 3B45B8           cmp eax,[ebp-0x48]
004012E2 75E0             jnz -0x20
Come si vede c'è anche incluso il confronto dell'istruzione for, che itera
ancora se non si è raggiunto p.end().
Intanto, non ho dovuto dire niente al compilatore, ha fatto tutto lui!
Inoltre se anche gli andasse espressamente richiesto di ottimizzare il
codice, qualunque persona di buon senso che si trovasse con problemi di
velocità, dopo il debugging di un progetto compilerebbe la versione finale
con uno swith -O2 o -O3 o qualcosa di simile per il proprio compilatore.
Il caso dove ++it e it++ o in generale quando qualsiasi tipo fa differenza
se auto incrementato prima o dopo il suo uso, è solo quando il suo valore
prima dell'incremento serve da qualche parte e quindi il compilatore è
costretto a crearsi una copia temporanea.
Ma perché so questo, perché io le cose le provo! Non c'è differenza se il
container contiene int, char o una classe qualsiasi se il compilatore è in
grado (come oggi fanno tutti) di inserire queste semplici ottimizzazioni!
L'ultima stupidaggine è la storia del link statico e del link dinamico.
Hai detto che un compilatore che crea un file di 400 Kb con l'esempio che ho
scritto in C++ fa schifo perché tu lo hai compilato in 9Kb.
Ma ti rendi conto delle cazzate che spari? Il file da 400Kb è così perché le
librerie sono state linkate staticamente. Il fatto poi di dover generare con
linking dinamico o statico dipende da altri fattori.
Comunque quelle librerie o le includi nell'eseguibile oppure l'eseguibile
avrà necessità di trovarle da qualche parte, ma sempre ci devono essere. E'
così anche per un programma in C, solo che si dimostra che le dimensioni (o
del file eseguibile intero linkato staticamente) o della libreria richiamata
run-time, è di gran lunga inferiore.
Basta, ora per me l'argomento è chiuso dato che non m'insegni mai nulla ma
pretendi di sapere tutto e sono sempre io quello che non sa niente,
certamente la tua prossima e-mail non farà altro che confutare tutto quello
che ho scritto, fortunatamente ognuno potrà farsi un'idea.

  (per non parlare del file selector...)
speriamo :D
-- 
Lawrence

 for (string::iterator it=p.begin(); it!=p.end(); it++)
[cut]
   Rispondo solo a questo, e mi astengo sul resto...
Il fatto che il codice compilato ti sia venuto identico nei due casi e`, 
scusa il gioco di parole, un caso, per l'appunto... Questo perche` gcc (e 
mingw che altro non e` che un porting, mi par di ricordare) utilizzano come 
iteratore dentro alla stringa null'altro che un char *: essendo questo un 
tipo "di base", il compilatore riesce ad eliminare l'oggetto temporaneo che 
si viene a creare con l'operatore postfisso... Questo, pero`, dipende 
dall'implementazione scelta da gcc/mingw, quella cioe` di utilizzare come 
std::string::iterator proprio un char *... 
   Pero` lo standard non dice nulla su come questi iteratori debbano essere 
implementati (cioe` non devono _necessariamente_ essere char *), ma ogni 
compilatore e` libero di fare quel che vuole. Probabile e` che nel caso 
delle std::string questa sia la scelta piu` ovvia e che sia utilizzata da 
_molti_ (se non tutti) compilatori, ma nessuno te lo garantisce... In 
generale, quando si utilizza un iteratore, e` bene non fare assunzioni sul 
suo comportamento, a meno che non sappiamo che quel codice verra` compilato 
solo con un certo compilatore di cui conosciamo l'implementazione.
   Per inciso questa cosa vale anche per lo std::vector<T> il cui iteratore, 
con gcc, e` proprio un T *, quindi, anche in questo caso, ti verrebbe 
"garantita" la cosa che dici tu. Gia` una std::list<T> non ha piu` questa 
caratteristica, visto che il suo iteratore *non* e` piu` un puntatore, ma 
un oggetto piu` complesso in cui la differenza tra postfisso e prefisso si 
sente (viene generato un oggetto temporaneo non utilizzato). 
   I miei 2 eurocents...
Vh
-- 
                          | rombando dal loro luogo
\|/ ____ \|/   \ ||_|     | d'origine, i buchi neri 
"@'/ ,. \`@"    \|| |     | tracannavano energia e da
/_| \__/ |_\ Vax Headroom | bolle frattali nascevano
   \__U_/                 | 

 Oppure e` una feature e non so come "spegnerla"...
Boh, io c'ho provato ma non mi ha fatto nulla di male.


 Boh, io c'ho provato ma non mi ha fatto nulla di male.
Che WM usi? Sawfish? Metacity?
In pratica, dovrebbe essere Sawfish, il punto del WS in
cui si clicca diventa l'angolo in alto a sinistra...
bye,
-- 
   Piergiorgio Sartor

 Any hints?
Non ho capito... quando sposti il workspace si spostano anche le
finestre ? Dovrebbe essere il comportamento di alt+shift, non quello di
default.
-- 
                                                __Nicholas Wieland
Flat is better than nested.
                                                __The Zen of Python

 default.
Quando clicco con il mouse in un punto del WS (sul pannel),
quel punto diventa l'angolo in alto a sinistra e tutto si
sposta di conseguenza...
Per ripristinare le cose, devo andare a cercare l'angolo
(cosa non facile) nel WS e ri-cliccarci sopra...
Oppure cambiare WS con crtl-F1...F4
Il WM dovrebbe essere Sawfish, che forse e` in parte
responsabile della cosa, anche se la cosa e` successa ad
un aggiornamento di gnome-panel...
Dimmi 'sta cosa di alt+shift, che controllo, magari qualche
setting e` saltato, e` configurabile? Dove?
bye,
-- 
   Piergiorgio Sartor

 Cosa parecchio fastidiosa, tocca usare ctrl-Fx per cambiare WS.
Window manager usato? Sawfish?
Mi chiedo perché la gente lo usi ancora. Sarà anche customizzabile, ma
in quanto all'essere compliant (e bug free) ce ne corre.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 cui si clicca diventa l'angolo in alto a sinistra...
Io uso Metacity, e` quello predefinito e quello che verra` sicuramente
sviluppato in futuro per GNOME e con quello non da problemi infatti.


 in quanto all'essere compliant (e bug free) ce ne corre.
Cosa raccomandi? Metacity?
Dopo provo a cambiare... Piuttosto come si fa?
bye,
-- 
   Piergiorgio Sartor

    I miei 2 eurocents...
No, questi purtroppo non gli avrai... Sai, c'è la Parmalat, il caro-euro...
è meglio risparmiare ma se passi da Modena e hai sete, un bicchier d'acqua
non sarò certo io a negartelo... Non si sa mai, un giorno potresti avere
sete e trovarti in zona, è meglio che niente!
Al momento ti dovrai accontentare di un sentito grazie!

 Dopo provo a cambiare... Piuttosto come si fa?
Ci sono due opzioni:
	1. cambiare la voce corrispondente in GConf
 
	   /desktop/gnome/applications/window_manager/default
 
	   usando gconftool-2 o l'editor della configurazione;
 
	2. fermare il window manager in funzione, lanciare il window
	   manager voluto e uscire, salvando la sessione.
C'era anche la possibilità di usare la variabile d'ambiente
$WINDOW_MANAGER, usando $HOME/.xinitrc o $HOME/.xsessione, ma la usai
solo durante la fase di beta testing di GNOME 2.0.


 	   manager voluto e uscire, salvando la sessione.
Questa ha funzionato!!!
Ho solo un'altra domanda, che sono quasi sicuro non ha
soluzione, in "sawfish" tra le 100.000 configurazioni
possibili, c'e` quella su come si devono disporre le
finestre, quando le apri, cioe` a partire, per esempio,
da alto-sx verso dx, oppure da alto-sx verso basso, etc.
C'e` una qualche simile possibilita` "metacity"?
bye,
-- 
piergiorgio

 ricompilare? Non mi pare un incremento enorme... 
Non ha nulla di speciale. E' solo un ambiente managed con un linguaggio 
ricco di API interessanti, un buon orientamento alla programmazione sulla 
rete, specifiche (e implementazioni) interessanti per applicazioni 
distribuite, orientato ad oggetti, una buona reflection, un parco di 
librerie non indifferente, strumenti di sviuppo interessanti.  
Il confronto è aperto con soluzioni analoghe. Prego...

 Il programma in C++ deve istanziare una classe!
no, non deve

 correttamente?
il C++, grazie ai traits o all'uso ricorsivo dei template (entrambe 
tecniche impossibili in C), può implementare il polimorfismo statico: 
senza funzioni virtual, risolto interamente in fase di compilazione e 
comunque type-safe. Il C no (e nessun altro linguaggio che io conosca, 
se è per questo)

 [...] ++it e it++ non fa differenza [...]
/me nitrisce

 debugger. E' lo stesso identico nei due casi!
tipico ragionamento da programmatore C. C++ richiede un'altra forma 
mentis, pena secche nasate su muri di mattoni, che non potrai evadere 
in eterno con la formula "C è più meglio, e LO SANNO TUTTI!"

 Per alcuni compiti ripeto il c++ va bene, per altri mai. 
leggende metropolitane. Non c'è compito per cui il C++ non sia almeno 
equivalente al C

 
Ogni volta che fai una scelta, migliori qualcosa e ne peggiori un altra, 
evidentemente avranno valutato che tutti questi cast sono tollerabili

 Al momento ti dovrai accontentare di un sentito grazie!
Scusa una cosa, io sono a reggio emilia, e di richieste per programmi 
seri(C, C++ meglio se in linu) ce ne sono pochissime, diciamo nulla. 
anche a modena è così? Te lo chiedo perchè è 2 mesi che mi butta 
veramente male
grazie

 sempre quello. 
Dire che un qualcosa NON e' multipiattaforma solo perche' manca su
FreeBSD/Linux/OS390 e' un po' riduttivo.
Java "funziona" su almeno 3 piattaforme software diverse e su almeno due
tipi di processori diversi: dal mio punto di vista e' multipiattaforma.
C:\>iao Angelo

 tutt'altra storia.
Su questo punto ne e' uscita una bella discussione qualche tempo fa:
non credo proprio che sia cosi. :-)
C:\>iao Angelo

 wrote in message
news:Xns948BC51B...@193.70.192.192
Il numero di folli in libera circolazione nel NG, aumenta... :-)
Era un po' che nion ti facevi vivo.
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 cagare, non stupirti se poi fa cagare"
Maledetta quella volta che ho postato quel codice.
C'erano due listati, uno in C e l'altro in C++ (che fa cagare) ma era lì
solo per far vedere che per quel compito nel caso del C veniva eseguito nel
modo teoricamente più diretto, efficiente. E far vedere, che se è vero
questo, qualsiasi altra cosa in più potrebbe essere controproducente.
Lo so anche io che string p("sono una nullità"); andrebbe definito come
array di caratteri però volevo farlo differente dal listato in C, e l'ho
fatto volutamente differente. Era un tentativo di fare un esempio e
stimolare una discussione, non intendevo stimolare la tua defecazio.
Se dovessi fare quella cosa in C++ realmente, e non per far chiacchiere
dovrei scrivere un codice che non esegue mezza istruzione di più, e nemmeno
che sia il doppio come dimensioni quando viene eseguito in memoria,
altrimenti a mio avviso non sarebbe un risultato esaltante.
Penso d'aver sbagliato esempio, però non mi sento di essere uno che scrive
codice che fa cagare, poi son tutti bravi invece secondo me con un pà
d'umiltà ognuno dovrebbe pensare alle cacchine sue (e sai che non produrne è
altrettanto grave)
Scusa per il codice che fa cagare, non era mia intenzione provocarti questo.
ciao, non voglio litigare. quello che hai scritto non è sbagliato.

 se è per questo)
E nel caso dinamico come fa?

 Maledetta quella volta che ho postato quel codice.
Avresti fatto meglio a portare un esempio automobilistico... :-P
bye,
-- 
   Piergiorgio Sartor

 tipi di processori diversi: dal mio punto di vista e' multipiattaforma.
Lo slogan era "compile once run everywhere" quindi o hai un concetto di
everywhere personale o lo slogan e' una marchetta.
-- 
                                                __Nicholas Wieland
Simple is better than complex.
                                                __The Zen of Python


f u cn rd ths u r usng unx

 form viene formattato il disco.
Visualizzati in modo differente. La formattazione magari può avvenire su 
windows... non in altri os... se non si è stupidi e si esegure da root...


 equivalente al C
Il codice eseguibile generato dal C++ è uguale al C? Ma quando?


 Il codice eseguibile generato dal C++ è uguale al C? Ma quando?
Meglio: equivalente in velocità e dimensione.


 everywhere personale o lo slogan e' una marchetta.
<Ginopilotino mode>
MS detiene il 90%, Mac il 5%, Linux il 3%,  Sun l' 1%
Se non e' everywhere, poco ci manca...
</Ginopilotino mode>


 windows... non in altri os... se non si è stupidi e si esegure da root...
L'ho detto che era un esempio estremizzato....


 
"nemmeno l'html standard e' multipiattaforma".


 link? Sarebbe interessante.
ISO/IEC 9899:1999 pag. 245
7.14 Signal handling <signal.h>
1 The header <signal.h> declares  a type and two functions and defines
  several macros, for handling various signals (conditions that may be
  reported during program execution).
2 The type defined is sig_atomic_t which is the (possibly
volatile-qualified)
  integer type of an object that can be accessed as an atomic entity,
even in
  the presence of asynchronous interrupts.
3 The macros defined are
     SIG_DFL
     SIG_ERR
     SIG_IGN
which expand  to constant expressions  with distinct values  that have
type compatible with the second  argument to, and the return value of,
the signal function,  and whose values compare unequal  to the address
of  any  declarable  function;  and  the following,  which  expand  to
positive  integer  constant expressions  with  type  int and  distinct
values  that  are  the  signal  numbers,  each  corresponding  to  the
specified condition:
SIGABRT abnormal termination, such as is initiated by the abort function
SIGFPE an  erroneous arithmetic operation,  such as zero divide  or an
       operation resulting in overflow
SIGILL  detection of an invalid function image, such as an invalid
        instruction
SIGINT  receipt of an interactive attention signal
SIGSEGV an invalid access to storage
SIGTERM a termination request sent to the program
ecc. ecc.
signal.h era definita anche dal vecchio standard. In giro dovrebbe
esserci un draft-quasi-standard.


 Avresti fatto meglio a portare un esempio automobilistico... :-P
Poi a Modena abbiamo la Ferrari2004-64 (dato lo sponsor!).
O un esempio ippico! Date le stroncature penso sarà una delle mie prossime
primarie attività!
Ciao!

 C'e` una qualche simile possibilita` "metacity"?
Non che io sappia. La disposizione delle finestre 'toplevel' è sempre
dall'alto-sx verso il basso-dx (a meno di preferenze specifiche
dell'applicazione).
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 E nel caso dinamico come fa?
come tutti: con una v-table

 Il codice eseguibile generato dal C++ è uguale al C? Ma quando?
a parità di algoritmo. Non c'è nessun overhead intrinseco nel C++

 Ma ripeto è ``tutto'' in java. E' del tutto insensato.
"tutto java" *sarebbe* ovviamente insensato.

 Si scrive in java perchè è più comodo, non perchè è meglio.
forse è meglio proprio perchè è più comodo. in fondo vb è orrendo per 
me, ma molta gente che lo usa deve solo fare dei prgettini con 4 righe 
di codice, e quindi va benissimo per loro. vedi la stessa cosa per java. 
è abbstanza multiplatforma, sviluppo su win ma quando devi fare hosting 
con poca fatica vai su linux, db neutral, puoi fare delle semplice jsp, 
o ci puoi mettere un application server da jboss gratuito o commerciale, 
  se uno commerciale non ti va bene ad esempio bea passi ad un altro sun 
per esempio, per me questi sono tutte ragioni per dire che è una gran 
bella comodità. prendi ad esempio PHP, è praticamente gratuito, ma è 
molto mysql oriented, se per un qualche motivo mysql non ti sta bene, 
metà degli applicativi che trovi in giro non funzionano più. Ora se 6 
convinto che mysql e php, per quello che devi fare siano ok no problem, 
ma certamente fai delle scelte impegnative all'inizio di progetto che 
con java ti puoi permettere di fare dopo. Stesso discorso vale per asp e 
access ovviamente.

access ovviamente.
Lo stesso in che senso? Che sono legati tra di loro?
-- 
-antonio-
www.geminisoft.com
(do not use this email address)

 Lo stesso in che senso? Che sono legati tra di loro?
E' vero esattamente quanto PhP e' legato a mySQL. Ovvero falso, in
entrambi i casi.
-- 
                                                __Nicholas Wieland
Beautiful is better than ugly.
                                                __The Zen of Python

entrambi i casi.
Ah, ecco, tutto chiaro.


 "tutto java" *sarebbe* ovviamente insensato.
Era chiaramente una iperbole. Ma la sua diffusione mi ``spaventa''...


 a parità di algoritmo. Non c'è nessun overhead intrinseco nel C++
Non credo però siano tempo-equivalente. Bisognerebbe guardare, ma un uso 
delle stringhe con char* in C ed uno con std::string credo abbiano tempi 
di esecuzione differenti a parità di algoritmo.
Ma bisognerebbe guardare meglio...


 kerberos, ma fa figo dare un nome nuovo...)
Non credo che il fatto che tu non conosca un termine indichi che questo
termine sia inutile oppure una invenzione commerciale, soprattutto se
porti come esempio Active Directory, che da come sono rimasto non e'
solamente ldap e kerberos.
Zope e' un application server, ovvero un server http, un server ftp, un
server xml-rpc, un framework per scrivere applicazioni web, con una
buona quantita' di servizi gia' implementati, come autenticazione, page
templates, un OODB, e chi piu' ne ha piu' ne metta, tutti integrati tra 
di loro.
PhP non e' una valida alternativa, e a dir la verita' lo trovo adatto
solo ad applicazioni sensibilmente piu' piccole che le applicazioni
medie di Zope.
Se devi lavorare in grossi gruppi, ad esempio, un application server e'
una alternativa sensibilmente migliore.
Naturalmente puoi scrivere tutto tu, ma a questo punto perche' PhP e non
una bella CGI in C ?
HAND,
-- 
                                                __Nicholas Wieland
If the implementation is hard to explain, it's a bad idea.
                                                __The Zen of Python

 come tutti: con una v-table
Vero!
Il meccanismo VTBL e VPTR utilizzato, come dici giustamente, da tutti i
linguaggi che risolvono il comportamento polimorfico a binding dinamico,
run-time, crea e gestisce per ogni classe che contiene una funzione
virtuale, una tabella delle funzioni virtuali.
La VTBL è un array di puntatori, ognuno dei quali punta all'implementazione
di ciascuna funzione virtuale dichiarata nella classe (può anche essere una
lista concatenata, dipende dall'implementazione, per la precisione). Esiste
solo per le classi che contengono funzioni virtuali.
Il puntatore VPTR è nascosto e presente in ciascuna classe che necessita di
una VTBL. Esso punta alla corrispondente VTBL.
Guarda questo semplice esempio:
class Base
{
    public:
        virtual void primo() { };
        virtual void secon() { };
        virtual void terzo () { };
    private:
        int valore;
};
class Deriv : public Base
{
    public:
        virtual void primo() { };
        virtual void secon() { };
        // non fa differenza che terzo() non venga specializzata
    private:
        int valore;
};
Ci sono 2 VTBL (una per Base e una per Deriv).
Le due tabelle allocano lo spazio per tre puntatori ciascuno (12 bytes),
quindi in totale un puntatore per ogni funzione virtuale e per ogni VTBL.
Se il nostro programma istanzia due oggetti run-time, uno Base e l'altro
Deriv utilizziamo ancora 8 bytes (2 VPTR).
Il consumo di spazio può divenire significativo se, ad esempio, si sta
realizzando un sistema completo o un'applicazione che deve funzionare in
sistemi con memoria risicata, quando c'è necessità di allocare run-time
numerose istanze.
In conclusione è necessario che i vantaggi derivanti dal meccanismo della
virtualità devono superare di gran lunga gli svantaggi dovuti alla maggior
occupazione in termini di spazio.
Il codice prodotto deve farsi carico della gestione di questo meccanismo.
Per questo molti affermano che il C++ e i linguaggi ad oggetti in generale
non sempre sono la soluzione più efficiente per determinati, rari, critici
compiti, ma questo non me lo sono inventato io...
Può sembrare assurdo perdere un centinaio di bytes per ogni classe e il
puntatori per l'allocazione run-time di n classi, ma se n diviene molto
grande forse bisogna cominciare a dedicare attenzione a questo fatto.
Su un PC questo non è mai un problema, ma al codice non interessa dove
questo girerà... Il sistema sul quale il nostro codice dovrà girare potrebbe
essere anche un processore da 20-25-33Mhz dotato di poche decine (se va bene
qualche centinaio) di kilobyte.
Io non biasimo chi per questi compiti preferisce programmare in semplice C,
non potendo contare quindi sui vantaggi della buona programmazione ad
oggetti, si faranno un mazzo così, però è sempre meglio che scriversi il
programma in assembly come si faceva in quei sistemi solo pochi anni fa (e
io l'ho fatto, ti assicuro che è una goduria).
Tutti i miei interventi puntavano a dimostrare questo... poi la situazione
mi è un pò sfuggita dalle mani, però anche nel caso del miglior codice C++
si ha comunque un costo da pagare!
E' tanto? E' poco? Ma chi lo sa? Ognuno sa come (potresti anche non usare
classi con funzioni virtuali) e dove deve programmare!
Quasi sempre il costo è praticamente nullo e vale la pena usufruire degli
innumerevoli vantaggi della programmazione ad oggetti, in rari casi anche il
minimo consumo di risorse va considerato.
Ciao, scusa se mi sono dilungato se cose che sicuramente conoscevi (forse
anche meglio di me), ma magari a qualcuno poteva interessare la questione,
così l'ho ripresa come meglio ho potuto.
Paolo Ferraresi.

 di codice, e quindi va benissimo per loro. vedi la stessa cosa per java. 
Beh... come al solito fa molto figo prendere le distanze da VB quando
questo è comunque uno strumento usabilissimo per sviluppare programmi
windows nativi generici, in particolare di una certa dimensione (da
buon linguaggio ad alto livello, ti toglie una bella quantità di
rogne).
In ogni modo mi lascia molto perplesso questa visione. Java sarebbe
"più comodo" per "molta gente che lo usa deve solo fare dei progettini
con 4 righe di codice"? Quando hai tempo ti suggerisco di fare un giro
sul website di jboss (visto che lo citi) e scaricarti lo snapshot dei
sorgenti, una quarantina di mega compressi gz (immagino che una volta
scompattati siano qualche centinaio). E di seguito ti suggerisco un
tour sullo sviluppo enterprise in java, in particolare gli ejb; vedrai
che il tuo giudizio sul "comodo per piccoli progetti" cambierà una
volta che ci hai sbattuto il naso e il tuo primo pensiero sarà "ma chi
me lo fa fare per 4 righe di codice?".
Poi la gente che scrive softwarini da 4 righe ad avanzatempo ci sono
ovunque, non fanno testo.

 una bella CGI in C ?
Si, certo... ma qualcuno l'ha fatto già, messo in un bel pacco regalo ed 
è nato zope :) --- non so come sia scritto zope...


 è nato zope :) --- non so come sia scritto zope...
Cosa intendi ? Zope e' scritto praticamente tutto in Python, http/ftp
server inclusi. Solo alcune parti di ZODB sono in C.
Zope si scrive Zope... Z Object Publishing Environment, credo.


pacchetto, sarebbe un ``application server'', o no?
imo, esattamente.

 programmi che fanno pena.
Vuol dire che questa persona non sa programmare in C, niente di male,
non sta scritto da nessuna parte che uno debba sapere programmare in
C. Un programmatore che si possa definire tale non si "dimentica" di
deallocare la memoria per abitudine ad altri linguaggi. Peraltro chi
scrive programmi usando più linguaggi si trova praticamente con solo
C/C++ che non gestiscono la memoria in automatico, basterebbe usare un
qualsiasi altro linguaggio per perdere l'abitudine.

 Zope si scrive Zope... Z Object Publishing Environment, credo.
In che linguaggi è scritto :) non certo come si scrive!


 'libreria' ;)
Si e tutti escono con idee malsane da questi corsi! Conoscendo un po' i
docenti...
L'aspra discussione è più che altro sul nome. Libreria è un termine che
puoi usare genericamente, mica è uno shared object per definizione. Ad
esempio, puoi usare alcuni componenti che effettuano che ne
so, triangolazioni di delaunay, e chiamarle librerie... in effetti molte
sono applicazioni che prendono in stdin i dati geometrici e li
restituiscono in stdout. Queste sono appellate librerie. D'altra parte, la
differenza sta nell'uso diverso di gcc... nulla di particolare.


 modello relazionale.
Non credo tu abbia capito molto, se confondi il concetto di "application 
server" e quello di "libreria".  

 server" e quello di "libreria".
Questione di nomi: un application server nudo e crudo non credo serva a
molto, un po' come qhull. Ti fornisce tutto quanto, può anche magari fare
qualcosa senza nulla di tuo ma alla fine è un pacchetto che riunisce
alcune funzionalità utili.
Come vuoi che lo chiami? Libreria non ti sta bene. Ok, anch'io credo non
renda l'idea. Framework di più. E' solo che non vedo la differenza tra
apache + php + java + oracle + postgresql + quellochetepare, con un
framework/applicazione che li riunisce in modo semplice ed un fiocco
regalo con un nome sopra.
Quello che analizzo non è l'uso finale ma cosa è in effetti. Un esempio?
IBM Directory Server. Che è? Magolamagamagia! E' semplicemente ldap che
risiede su db2 impacchettato con un fiocchetto. Non penso a db2, ci pensa
lui, con configurazione via web se ti piace, cli o X, tutto pronto.


 regalo con un nome sopra.
Mai sentito parlare di integrazione vero? Perche` pensi che Java piu` o
meno funzioni? Perche` pensi che la MS abbia sfornato .NET?
-- 
Lawrence

 si ha comunque un costo da pagare!
Mi reinserisco in questo punto perché la nostra precedente discussione
era ormai (per colpa di entrambi) degenerata in un litigio...
Spero che in futuro si possa discutere in modo sensato (anche se l'aria
di questo NG ispira discussioni "violente").
In ogni caso si è visto chi aveva ragione :-P
Per quanto riguarda quello che hai scritto in questo post ci sono alcune 
cose delle quali non tiene conto chi afferma che il C++ è meno efficiente 
del C.
Scrivere codice C++ (e codice OO in generale) non significa utilizzare a 
più non posso ereditarietà e polimorfismo per inclusione (quello che hai 
chiamato dinamico). Significa utilizzarli quando ce n'è un reale bisogno.
E se c'è un reale bisogno di utilizzare ereditarietà e polimorfismo in C++ 
questo ci sarà anche scrivendo lo stesso codice in C, solo che bisognerà
implementare a mano un meccanismo simile (guarda caso si useranno array
di puntatori a funzioni).
È piuttosto palese che se confronti buon codice C++, scritto in modo da
essere leggibile, di facile modifica, manutenzione ed estensione con
codice C superstraottimizzato, ma per questo illeggibile ed intoccabile 
(nel senso che se ci metti le mani non sai cosa può succedere) il 
confronto non è molto equo...
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 evidentemente avranno valutato che tutti questi cast sono tollerabili
Bah, io non conosco molto Java (ne sto il più possibile alla larga), ma 
vista la quantità di persone che si lamentano della sua lentezza, e vista 
comunque la povertà del linguaggio... faccio fatica a vedere cosa questo 
possa avere migliorato.


 cli o X, tutto pronto. 
E quindi, cosa c'entra? Ne il Directory Server, ne ldap server, ne db2 
sono un application server. E nemmeno tutti impacchetti insieme lo 
diventano. Ti conviene dare un occhiata alla definizione.
Comunque l'application server, il middleware e i tre livelli sono 
concetti che risalgono ai primi anni 90, una rapida ricerca su internet e 
vedrai che trovi abbondante materiale. 
 

Vincent Vega wrote:
no no ferma un attimo c'è un fraintendimento. Java lo si può usare in 
modo basilare, che è un po come lo utilizzatore VB ASP, ovvero come 
sistema ad alto livello fregandosene delle performance in quanto c'è il 
GC e scrivendo paginette jsp, oppure lo si può utilizzare in modo 
pesante, quindi facendo anche attenzione alle performance utilizzando 
bene i distruttori, utilizzando EJB etc, in quanto il progetto è di 
notevole dimensioni. Sincermante non ho mai visto grossi programmi in 
VB, mentre per java (es jboss) ci sono.
Ovvero da la possibilità di avre un ROI molto elevato, parto in piccolo 
e se mi va bene posso migrare a qualcosa di pesnate riclando 
completamente il mio know how. questo ad esempio non accade con altri 
sistemi.

 
si esatto sono molto legati

 
ok ammetto che non ero aggiornato ma fino a php3 non c'era un layer di 
astrazione sui db, mentre lo hanno introdotto dopo ok bene. Per quanto 
riguarda python e php come siamo messi con connessioni corba, load 
balancing, integrazioni con directory service, transazioni etc? ovvero 
caratteristiche di un progetto di grandi dimensioni?

 caratteristiche di un progetto di grandi dimensioni?
Zope e` scritto in python e ha tutto quello che vuoi...  Nel caso tu
abbia voglia di riscrivere uno Zope da capo puoi anche affidarti a
Twisted Matrix (che pero` e` un framework per applicazioni distribuite
con cui puoi fare tutto ma tutto quello che vuoi e che ha a che vedere
con la rete).
CORBA in python c'e` attraverso uno di questi:
omniORBpy
orbit-python
pyorbit
A seconda della versione di orbit che interessa bindare o della scelta
personale.
Non so la situazione per quanto riguarda il load balancing ma ho letto
almeno un talk su questo in cui il linguaggio usato era python e da
quanto leggo su Oreilly Network direi che non vedo particolari
difficolta` nell'implementare in python un DNS che fa round robin tra
N macchine per la gestione delle risposte e via dicendo. Tant'e` che
cherrypy supporta il load-balancing. Sicuramente e` possibile farlo
con pochissimi problemi usando Twisted ed e` probabile che Zope gia`
lo integri ma non saprei.
Per sistemi ldap invece esistono almeno (perche` sono inclusi in
gentoo):
ldaptor 
python-ldap
Mi sa che faresti bene a conoscere lo stato attuale delle cose _prima_
di esprimere giudizi in merito... Per quanto io apprezzi poco PHP,
ormai siamo alla 5 e tu esprimi giudizi pensando alla 3, un po`
scorretto non trovi?
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Gentoo Proud User

si esatto sono molto legati
Mi dispiace contraddirti ma non č assolutamente vero. ASP accede ai
database attraverso ADO (ActiveX Data Objects) con i quali puoi andare
tranquillamente verso Sql Server, Oracle, Access e tutti i database che
hanno provider OLEDB. Se non ne hai uno puoi usare il provider fornito che
ti fa passare attraverso ODBC e cosě puoi andare verso tutti i database che
hanno almeno un driver ODBC.


ok ammetto che non ero aggiornato
Beh, non lo sei neanche su ASP e Access e qui non è questione di essere
aggiornati perchè ASP è così da sempre (vedi mio altro post).
Forse hai detto una cosa della quale non potevi essere sicuro?


 distintivo, cmq.
E' distintivo di Zope :)
In linea teorica ZODB puo' avere diversi backend, cioe' ad esempio puoi
mapparlo in un RDBMS, in linea pratica non e' ancora stato fatto, e IMHO
non e' cosi' utile (troppo overhead per qualcosa di superfluo).
Si usano degli adapter per quasi tutti gli RDBMS, e si usano nudi e
crudi, con le dbapi normali, proprio come faresti in un programma
normale.
HAND,
-- 
                                                __Nicholas Wieland
Readability counts.
                                                __The Zen of Python

 meno funzioni? Perche` pensi che la MS abbia sfornato .NET?
Per non avere 14 milioni di pacchetti diversi? Perchè secondo te? In 
questo modo possiamo ottenere le funzionalità ricercate senza fatica. 
Stanno già li per chi le usa.
Dico cretinate? Perchè allora? Poi... perchè dici ``Perche` pensi che 
Java piu` o meno funzioni?'' --- che vuol dire?


 vedrai che trovi abbondante materiale. 
Di middleware l'ibm mi ha fatto venire il latte alle ginocchia... :) 
Abbasta! Forse ``IDE'' è più vicino al concetto di application server...


 qualsiasi altro linguaggio per perdere l'abitudine.
Se esce fuori da qui si, deve saper programmare in c, c++, java, ocaml, 
un po' di scheme. Deve avere le basi della buona creanza: deallocare la 
memoria allocata. Non per tutto puoi usare java e non ovunque hai 
garbage collectors.


 ma ho letto almeno un talk
RI-ARGH!
-- 
il Vide - ICQ# 5301833
IAMM - it.arti.musica.metal 
http://www.heavy-metal.it
"There is no stronger drug than reality"

 ed ai tra c/c++ e ocaml... :)
Benche` neanche a me piaccia java, le tue motivazioni sono risibili...
Valuti un linguaggio dal riuscire a scriverci un OS? E per spegnere la
luce in casa tua rompi le lampadine? Ogni linguaggio ha il suo
compito, ci sono quelli che l'hanno piu` vasto e quelli che l'hanno
meno.
Java per colpa del fatto che supporta solo il paradigma a oggetti
avra` uno scope decisamente piu` ristretto di C++ o Python che sono
invece multi-paradigma. Ma le ragioni che puoi portare sono queste
pero`, non che non ci scrivi un Os e quindi e` merda, perche` tu non
scrivi Os dalla mattina alla sera.


 RI-ARGH!
Lo so che suonano male ma "legare" invece di "bindare" ricorda
qualcosa di piu` sadomaso di quello che si pensi :P...
E poi solitamente i testi delle conferenze si chiamano talk, non
discussioni o altro...
IMHO ovviamente.


 piu` o meno funzioni?'' --- che vuol dire?
Mi sa che hai frainteso, "funzioni" era inteso come: "piace ed e` diffuso",
la chiave oltre alla multipiattaforma sta nell'integrazione. Ecco perche`
Java ha una lib mastodontica, .NET pure, Python si sta muovendo in direzione
PyPi e Perl con CPAN la fa da padrone. Tutto qui :D
-- 
Lawrence

 IMHO ovviamente.
Non solo secondo te, purtroppo :P Lo faccio anche io molto spesso, sia 
chiaro, però a tutto c'è un limite :P


 Però, potrò dire che java è un *vero* linguaggio multipurpose
Piccola precisazione: multipurpose non significa "tutti"
ma "alcuni oppure molti"
-- 
Lawrence

 scrivi Os dalla mattina alla sera.
Non dico che è merda punto, ma dico che le cose scritte in java quando è 
chiaramente meglio usare un altro linguaggio sono merda. Ci sono tante, 
troppe cose scritte in java quando questo non serve.
Su questo non credo possiate dire ``hai torto, io ls, apache e mkfs lo 
riscriverei in java''.


 Peccato che siamo nel mondo reale e il software ha *sempre* dei bug.
Il C++ non ha GC ma non soffre di questi problemi se usato
correttamente. E questo porta tanti vantaggi ed un solo svantaggio:
occorre saper programmare veramente.


 PyPi e Perl con CPAN la fa da padrone. Tutto qui :D
Chiarissimo :)


 occorre saper programmare veramente.
Quoto.
Non sono l'unico agghiacciante residuato bellico che pensa che per fare un
servizio bisogna conoscere sul serio, non le classi java.* javax.* & co, e
che le soluzioni tutte infiocchettate lasciano un po' a desiderare in
ambiti più forti.
<sarcastic> Ad esempio, ora stiamo sviluppando un kernel geometrico
parallelo... Adesso ditemi che lo scrivete in Java </sarcastic>. Si, hai
tutto pronto e con java3d hai pure un visualizzatore al volo... 


 possa avere migliorato.
Dal punto di vista didattico non va in crash un sistema perchè qualcuno
ha usato malamente un puntatore in C.


 occorre saper programmare veramente.
Certo. Ma essendo causato da un errore di programmazione, il buffer 
overflow *per definizione* nemmeno esiste, se il linguaggio è usato 
correttamente. 
Nel mondo reale e in un programma ragionevolmente complesso, l'errore di 
programmazione è un problema concreto e lo sa bene anche (e soprattutto) 
chi sa programmare veramente. Lo dimostra il fatto che anche nei programmi 
noti per la loro qualità di programmazione vengono trovate e corrette delle 
vulnerabilità con relativa frequenza.
Ciò che voglio dire, non significa che un ambiente "managed" sia la manna 
dal cielo per il cialtrone:  se si prende ad esempio un classico errore 
causa del buffer overflow, come una ricezione sbagliata da un socket o una 
copia controllata male, non è che java te la fa passare liscia. Anche in 
java un programma del genere non funziona. La differenza è in C/C++ il 
programma non si limita a non funzionare, ma talvolta funziona in modo 
imprevedibile/indesiderato. E questo non è certo un vantaggio.

 Ciao.
Ciao, ho tagliato il tuo discorso per non quotare tutto e rispettare la
netiquette.
Se anche Materazzi e Cirillo (i due calciatori che si sono azzuffati) hanno
fatto pace possiamo farlo anche noi che non ci siamo nemmeno presi a pugni
(dato che non t'avevo davanti). Per quanto mi riguarda non mi sono
comportato troppo bene. Allora ci mettiamo una pietra sopra!
In effetti, questa volta, riesco a capire in tutta la sua limpidezza ciò che
dici.
Non è proprio che volevo buttare via il C++, ma in alcuni passi certe volte
avevo rinunciato a qualche comodità C++ pensando d'avere vantaggi
prestazionali scrivendo segmenti di codice come fosse C (ma sempre dentro a
programmi C++! Attenzione, questo non lo avevo detto!).
Facevo qualche classe ma pensavo di dover rinunciare (in rarissimi casi dove
la velocità non era sufficiente, quasi mai, capita ne 0.1% dei miei
programmi) a polimorfismo ed ereditarietà run-time (per non far gestire al
mio compiler V-table).
Proprio perché cercavo le massime prestazioni (e quasi m'illudevo di
trovarle) andavo a sostituire in un programma C++ parti praticamente in C
(stringhe C al posto di comode classi per le stringhe, memcpy() ed altre
"vecchie" funzioni C, array[] e non vettori e altre classi STL), ho
guadagnato sempre pochissimo come velocità, quasi niente a dir la verità e a
volte proprio niente (meglio invece come occupazione di ram una volta che
l'elaborazione del programma arrivava nei punti cruciali, evidentemente STL
e le librerie che avevo usato per quanto poco, necessitavano di risorse
maggiori, ma forse dipende anche dalla loro implementazione o dal
compilatore dato che ne uso diversi). Il problema della memoria l'ho notato
soprattutto nei programmi per Windows, non sotto Unix (un programma
compilato di 9Kb sotto Windows non l'ho ancora trovato!).
Altre volte invece, e forse questo era un punto di accordo, sono riuscito a
concentrarmi a tal punto su algoritmi complessi, come facevo fatica a fare
col C puro in effetti, da riuscire a migliorare non il codice in quanto
tale, ma proprio l'algoritmo. Mi accorgevo che dovevo fare meno cose di
quanto pensavo (pensa a progetti moltograndi, a volte con i linguaggi
procedurali si rischiava di perdersi, io poi sono per natura un
disordinato!).
In effetti scrivo sempre in C++ (lo faccio come so fare, anche se
sicuramente posso imparare ancora tanto) e non lo sostituirei con niente.
Cerco sempre di pensare ad oggetti e se ne vale la pena cerco di usare i
container standard data la loro comodità e il fatto di poter contare su
ottime e stabili funzionalità...
Il mio obiettivo è di scrivere software (ci provo, ci devo provare) che
funzioni sempre e che dia il risultato che ci si attende, dopo cerco , ma
solo se è necessario di limare e farlo andare più forte.
A dire la verità qualche volta usando gli algoritmi di STL ho pure
guadagnato PRESTAZIONALMENTE (non so perché forse tu si e potresti dirmelo,
magari nel codice delle loro librerie c'erano ottimizzazioni che sfruttavano
in pieno le caratteristiche del processore meglio di quello che potevo fare
io o erano semplicemente fatti meglio di come gli avevo realizzati io in
vecchie librerie che mi ero fatto tanti anni fa in C, quando il C++ non
esisteva).
Questo (il fatto che in rare occasioni avevo limitato le dimensioni del
codice) mi aveva indotto a pensare che dovendo scrivere un S.O. non avrei
voluto far pagare un due byte e un ciclo clock in più del necessario, ma
forse sono rimasto ai tempi dei computer ad 8 bit. Io sono un vecchio
dinosauro informatico, sai?
Ricordo che quando programmavo sull'apple 2 dovevo scrivere parti di
programma o anche per intero in assembly con il motorola 6502 (che non sa
fare nemmeno le moltiplicazioni e ha un solo accumulatore).
Evidentemente non so quanto e se ne valga la pena oggi. Sono altri tempi.
Sicuramente un buon programma in C++ è per natura un codice "più robusto" e
pulito, e che quindi ti fa sbagliare meno... Per le prestazioni... quasi
sempre C++ non è peggio del C.
Ma sicuramente puoi sempre decidere come programmarlo (il C++) a seconda
delle situazioni, per questo è un grande linguaggio.
Per me è un grande vantaggio, odiavo dovermi scrivere il codice per gestire
una lista.
Va bene, mi fermo quì. Non tutto il male viene per nuovere, sicuramente
certe cose che son state dette da te e da altri mi hanno fatto considerare
le cose in modo differente.
Scusa se mi sono dilungato ma era la mia conclusione ad un lungo discorso
(che ora mi ha dato i suoi frutti).
Grazie a tutti, ora su questo NG voglio tornare a seguire discussioni IT !
Saluto te e gli altri del newsgroup.
Ciao e buon lavoro.
Paolo Ferraresi.

 pagare! E' tanto? E' poco? Ma chi lo sa?
tu. Almeno, è uno dei tuoi compiti

 hai tutto pronto e con java3d hai pure un visualizzatore al volo... 
<sarcastic>Prima di cimentarsi in un kernel geometrico parallelo carpiato 
con doppio avvitamento, forse è meglio sapere che esistono diversi 
ambiti/target di sviluppo e che l'interlocutore sa *benissimo* che non si 
scrive un kernel geometrico parallelo carpiato con doppio avvitamento in 
java.</sarcastic>

 java.</sarcastic>
Sarà il mio lavoro scrivere un kernel geometrico, no? :) So che nessuno 
a questo mondo --- preciso, nessuno dotato di cervello --- userebbe java 
in ambiti come quello... Ma poi l'avvitamento doppio carpiato che è? una 
superficie di riemann? :)
Ma di gente matta ce ne è a bizzeffe...


 tu. Almeno, è uno dei tuoi compiti
E' giusto che sia così, chi meglio del programmatore "dovrebbe" saperlo.
Ciao.

 userebbe java in ambiti come quello... 
Mi sembra superfluo precisarlo, visto che non ha strumenti di basso livello 
per essere usato in quell'ambito. 

 
si concordo, ho fatto male a non aggiornarmi, ma io sviluppo 
principalmente in CORBA e C++, adesso nel settore del multimedia, ed nel 
settore web ci lavoravo anni fa prima di iscrivermi in università. 
piccolo totoquiz sai cosa è il CARBO?

 
si si  lo so benissimo, il senso del discorso era ci sono strumenti che 
permettono di fare scelte di architettura in fase avanzata di progetto, 
altri no. Prendi ASP, quasi certamente dovrai fare hosting su ambiente 
zio bill, perchč non č molto multipiattaforma. Ora esistono anche dei 
runtime asp anche per linux mediante java, mi sembra che sun li venda, 
ma sinceramente, se sono obbligato a cambiare SO di hosting allora 
duante la maintenance cambio anche linguaggio di sviluppo, ovvero passo 
da ASP a PHP,JSP, qualcosa di multipiattaforma nativo.

Paolo Ferraresi wrote:
[SNIP]
data la mia piccola esperienza, posso dire che orami statisticamente 
quasi tutti programmano in C++, gli unici che lavorano ancora in C/ASM, 
sono quelli che lavorano su microcontrollori e/o firmware. L'altro 
giorno un collega che fa firmware mi ha detto che con 20/30 euro, ha 
trovato un arm, con ethernet e 16mb di ram. Lui normalmente usa i PIC da 
programmare in C che gli costano un 10/20 euro, sta seriemnte pensando 
di cambiare ambiente, peccato che sia un elettronico e di programmazione 
OO ne sappia zero. ha troavto un micro economico che lo si può 
programmare altre che in C anche Java direttamente. Mi sa ormai che chi 
lavora in asm/C deve lavorare su micro dal costo inferiore ai 10 euri. 
se aspetttiamo altri 5 anni, mi sa che diremo addio anche a questi.

 università. piccolo totoquiz sai cosa è il CARBO?
No... Non lo so.


 per essere usato in quell'ambito.
E vorrei vedé! :) Anche se ti dirò... qualcuno ci ha pure pensato a
scriverlo in java...


 ottimizzazione. 
C'e` il problema dell'implementazione, che cambia
da architettura ad architettura e dipende dalle
risorse disponibili.
Se peschi un certo algortitmo, anche ottimo e magari
anche ottimizzato, non e` detto che sia il meglio
possibile nel caso che ti interessa.
Si trovano differenze anche oltre il 100%.
bye,
-- 
piergiorgio

 possibile nel caso che ti interessa.
Parlando di applicare l'algoritmo "adatto" rispondo alla tua confutazione.

 Parlando di applicare l'algoritmo "adatto" rispondo alla tua confutazione.
Non basta avere l'algoritmo ottimo, devi anche
ottimizzarlo per il caso che stai considerando.
Se devi fare un filtro FIR su Pentium usi SSE,
su PPC usi Altivec.
L'algoritmo che vai ad implementare sara` lo stesso,
cio` non toglie che devi ottimizzare per la specifica
architettura (e risorse).
Le differenze, ripeto, sono oltre il 100%.
bye,
-- 
piergiorgio

 [SNIP]
Ciao, conosco il settore di cui parli, se leggi la risposta che ho dato a
Hyperion vedrai appunto che sono proprio quelli che ci tocca di programmare
ancora in C.
Primariamente li sviluppa un ingegnere elettronico che lavora con noi, io mi
occupo di progettazione e sviluppo di tutto il software interno su
workstation (o per i PC) che ci può servire per i calcoli e le simulazioni
(e il C++ è il massimo per questo, guai a non averlo).
Dato che lui è un grandissimo elettronico ma come programmazione ha si
esperienza nel suo settore, anzi è imponente, me è un "praticone", spesso ci
confrontiamo sul codice C che scrive... Diciamo che nel suo codice prima
delle mie "imboccate" non usava nemmeno le strutture C, le variabili erano
tutte buttate a livello globale (c'era da mettersi le mani nei capelli)...
però questa persona è effettivamente un "mostro" a capire tutto quello che
succede a livello hardware (e ha pure una grandissima comprensione dei
fenomeni fisici che ci stanno dietro, cosa non trascurabile). Il suo
problema era che finche nel suo codice ci mette le mani lui tutto bene, io
non ci capivo niente (altro che protezione del software!). Ora utilizza
strutture e passa alle funzioni i puntatori alle strutture e il suo codice è
finalmente diventato comprensibile anche agli altri e meglio manutenibile.
L'hardware che usiamo noi sono (per semplificare) "piccole strutture
microprogrammate", cpu da una trentina di Mhz al massimo, non più di 256Kb
di ram, non esiste un monitor, gli unici dispositivi di I/O sono segnali in
ingresso ed in uscita mediante convertitori digitali/analogici. Il debugging
è impressionante, dovresti vedere (via di oscilloscopio). Non hanno S.O., il
sistema operativo è il tuo programma che compili e poi scrivi nella eprom,
ci sono analogie con i firmware (IRQ da gestire, è proprio basso livello) se
immaginiamo tutto il mio sistema come fosse una periferica, e da un certo
punto di vista è la parte "intelligente" di un componente elettro/idraulico.
Se un giorno si potessero programmare in C++ (e fra qualche anno sarà così
certamente), sarebbe un grosso passo in avanti per la produttività. Avere
classi già testate e funzionanti semplificherebbe molto le cose, dato che il
codice non è semplice come un non addetto ai lavori potrebbe ingenuamente
pensare dal fatto che l'hardware è limitato (considera che uno degli
obiettivi è che debbano costare poco alla produzione).
Ciao, saluti!

 su PPC usi Altivec.
Ferma il mondo! Questo è qualcosa che mi interessa molto.
Cosa fa sse/altivec? In cosa mi aiuta a far filtraggi fir/iir? Hanno anche
qualche truccazzo per avere cosa un po' più avanzate? Ed una cosa in
particolare... se puoi darmi una dritta, una implementazione efficiente di
levinson-durbin, avrebbe qualche giovamento da sse & co?
Qualche grassa url su questo c'è?


 Qualche grassa url su questo c'è?
In generale i manuali intel & AMD su MMX, MMX2, 3DNow!, SSE,
SSE2, SSE3...
Oppure Altivec, da Motorola.
intel distrubuisce librerie con funzionalita` gia` implementate,
magari c'e` qualcosa che puo` essere utile, tipo prodotto di
matrici o simili.
bye,
-- 
piergiorgio

 bye,
Thank you. Guarderò!


 spezza: nessuno l'ha già fatto prima.
Allora visto che sei ad ingegneria informatica puoi tranquillamente
tralasciare java e anche tutta la programmazione ad oggetti.
In fondo mica I.I. serve a sfornare programmatori... :))
Ciao

 In fondo mica I.I. serve a sfornare programmatori... :))
E' vero, ma devono essere anche programmatori prima che ingegneri...
altrimenti butteremmo al cesso un sacco di programmi che aiutano
moltissimo (leggi da matlab a maple, da parasolid a giggiņanimalo ;) )


>università. piccolo totoquiz sai cosa è il CARBO?
nel 97, era il leader dei engine di e-commerce, tecnicamente era 
fantastico, io l'importavo per l'italia, poi sono arrivati zio bill, 
ibm, ed un altro grosso tedesco che lavorava in perl, et voila non se ne 
sente + parlare.
quello che voglio dire è che se un prodotto per essere diffuso, oltre ad 
essere funzionale tecnicamente, deve avere una grossa azienda dietro. io 
ad esempio ammiro molto debian, ma senza redhat, suse, caldera e 
turbolinux, oggi linux sarebbe dove è BSD, ovvero un sistema molto 
funzionale conosciuto da pochi, ma diffuso solo per compiti molto 
specifici, mente oggi se vai da una azienda qualsiasi linux sa almeno 
per sommi punti cosa è.

 comportato troppo bene. Allora ci mettiamo una pietra sopra!
Certamente, non vale certo la pena di litigare per divergenze di idee...
[cut]
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 imprevedibile/indesiderato. E questo non è certo un vantaggio.
Il tuo errore è continuare a scrivere C/C++. Per quanto il secondo
derivi dal primo, sono due linguaggi *completamente* e *totalmente*
diversi (hanno in comune solo -e nemmeno tutta- la sintassi).


 forse perché memoria e tempo potrebbero non essere più delle criticità!
http://trion.sourceforge.net
The Trion Object Oriented Operating system is an OS that is designed to meet
the needs for the 21st century, with a kernel written in C++ and modelled
in UML, and lots of features. The project is ran by a team of OSDev.org
community members.
Programming Language: Assembly, C++
Saluti
-- 
Faber
http://www.faberbox.com
Windows 2000: Designed for the Internet.
The Internet: Designed for UNIX. -- From a Slashdot.org post