Newsgroup: it.comp.lang.c++
Titolo: Linus Torvalds hates C++

"C++ is a horrible language. It's made more horrible by the fact that
a lot of substandard programmers use it, to the point where it's much
much easier to generate total and utter crap with it. Quite frankly,
even if the choice of C were to do *nothing* but keep the C++
programmers out, that in itself would be a huge reason to use C."
Certo che è una bella pubblicità...
ciao


Ah... la fonte è:
http://article.gmane.org/gmane.comp.version-control.git/57918
in italiano è apparso anche su:
http://www.zeusnews.it/index.php3?ar=stampa&cod=6145&numero=907

 programmers out, that in itself would be a huge reason to use C."
Come al solito, sparata ad effetto. 
Il punto č che chi si avvicinasse a C++ pensando che fosse piů facile
del C, sbaglierebbe di grosso. C++ č (per certi versi) piů *comodo*.
Alcuni problemi del C sono risolti (stamattina ho convertito parecchie
righe di codice 'C' dentro un metodo C++ con l'equivalente C++ standard,
che sono tre righe, fra quello che ho risparmiato in gestione della
memoria e degli errori).
D'altra parte mi rendo conto che la mia testa ha garbage collected
larghe parti di quello che sapevo su C++. Sigh. Oh, saranno 6 mesi 6 che
non ci faccio nulla.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 Come al solito, sparata ad effetto.
Probabilmente si riferisce al linguaggio del kernel.
Tratto dalle faq:
http://www.kernel.org/pub/linux/docs/lkml/#s15-1
" for GUI implementation KDE is a good example that C++ beats plain C
any day"
Non penso che generalizzi dicendo che il C++ è un casino per tutto e
per tutti.
In fondo a questa pagina afferma di aver usato il C++ per alcune parti
del kernel:
http://www.pluto.it/files/journal/pj9807/linus.html
Probabilmente non lo ama.
Probabilmente non tutti i programmatori sono incapaci.
Probabilmente lo Stroustrup avrebbe qualcosa da ridire.
Ciao.

 Probabilmente lo Stroustrup avrebbe qualcosa da ridire.
Probabilmente si diverte a fare polemica (come molti informatici).
C'č chi gioca a biliardo, chi fa sport, chi corre dietro alle ragazze.
Linus si diverte cosě ;-)
Bye
Jarod

 non ci faccio nulla.
Anche io sono abbastanza arrugginito... che dici magari mettiamo su un
Garbage collector per C++? giusto per fare una cosa a cui nessuno ha
pensato finora... ;P
ciao

 Ciao.
e probabilmente ha perso una buona occasione per stare zitto...
ciao

 pensato finora... ;P
Beh, scherzi a parte, ci sono gc per C++, solo non sono nella stl. :)
Comunque mi riferivo al fatto che la mia testa ha cancellato che
supponevo di ricordare senza avvertimento. grr.


 Probabilmente si riferisce al linguaggio del kernel.
Sì, concordo. Avevo letto anche altri articoli in cui si diceva che il
C++ per quanto riguarda il kernel offre più svantaggi che vantaggi...
IMHO una certa ragione ce l'ha. Per gestire una cosa di cui si sa già
tutto in partenza (e di cui NON puoi sperare che qualcun altro gestisca
gli errori per te), buona parte dei meccanismi del C++ non serve.

  Beh, scherzi a parte, ci sono gc per C++, solo non sono nella stl. :)
Non ancora =)
--*PaN!*
 
-- 
I'm using an evaluation license of nemo since 35 days.
You should really try it!
http://www.malcom-mac.com/nemo

 memoria e degli errori).
OK, però sarebbe anche sbagliato negare che il C++ e le STL hanno
effettivamente diversi problemi irrisolti. In altro post si diceva
appunto che la RTTI è fatta male... i template li stanno ristrutturando,
la STL verrà presto rimaneggiata (se non ho capito male io). Non è che
Linus abbia del tutto torto.

 Neanche a me, ma perche' e' fatta male =)
vero.


 gli errori per te), buona parte dei meccanismi del C++ non serve.
Ma invece che ricrearsi meccanismi ad oggetti da 0, usi quelli testati e
collaudati di C++.
Per dire l'IOKit di OS X è precisamente scritto in ec++


 Linus abbia del tutto torto.
Su cosa? Sul fatto che C++ sia migliorabile? Pure C lo è. 
Dopo tutto lo è stato continuamente.
RTTI è fatta male? Si. Ma è roba che *comunque* in un kernel non è
particolarmente necessaria. 
I template li stanno ristrutturando: la rogna è upgradare, certo. Ma è
una rogna in qualunque progetto complesso, non solo nel kernel. Come a
dire che *nessun* progetto dovrebbe usare C++.
Riguardo alla STL il kernel potrebbe comunque non avere grande uso della
STL, magari una versione ad hoc, o una versione ridotta.
IMHO Linus non ha torto quando dice che riscrivere il kernel in C++ è da
pazzi. Quando dice che non bisogna scrivere kernel in C++ eleva, come al
solito, la sua personale e parziale esperienza a verità universale.


 Ciao.
Ciao a tutti, 
-- 
Salvatore

 MAI utilizzato goto in un programma C++). 
Ne ho tolto uno stamattina. Si, i goto si vedono e si usano tipicamente
quando si ha a che fare con codice C in C++. Esempio se stai scrivendo
un'implementazione con roba posix. In questo caso può non valere la pena
di scrivere codice del tipo
try{
   if(posix_function() < 0) throw PosixException;
} catch PosixException {
   pulisci.
}
Anche perchè con la roba posix spesso hai allocazioni e deallocazioni di
risorse da gestire a mano: il modo *corretto* di procedere sarebbe
quello di incapsulare tutto sotto RAII e poi scrivere codice standard.
Tuttavia se le condizioni di errore sono sufficientemente rare,
un'approccio più efficiente può essere scrivere (limitatamente a metodi
'infoppati' sotto altri strati di codice) la roba 'alla C'.
Ho un altro esempio, mio e furbo. Ancora una volta ho ragioni di
efficienza e di 'eleganza'. Ho un loop che deve essere particolarmente
veloce che continua ad essere eseguito finchè non si verifica una
condizione di errore, nel caso si esce, la si gestisce, ed eventualmente
si rientra.
Immaginati
while(state == NO_ERROR)
  step();
L'uscita dal while viene fatta in modo ovvio quando qualcuno setta il
membro error al tipo di errore. Questo stesso risultato avrebbe potuto
essere ottenuto con eccezioni, ma con performance leggermente peggiori e
nessun vero vantaggio (il codice dentro step non ha problemi di roba che
scoppia o di eccezioni interne).
Il problema è *ritornare* dentro il loop quando ne sei uscito. Qui non è
questione di eccezioni ne nulla. In Ruby per esempio c'è la keyword
'retry'. In C++ no. Il metodo che a me è parso ovvio?
while(state == NO_ERROR){
  rerun:
    step();
}
/* codice per gestire gli errori */
if (state == DUMB_USER){
  change_user();
  goto rerun;
}
Chiaro, queste cose sono assolutamente specifiche e non generali. Non è
che farcisca il C++ di goto a muso. Solo *quel* codice non ha bisogno di
dichiarazioni, allocazioni, e tutto. E IMHO usare i goto è la strada più
comoda. Certo, avrei potuto ficcare il tutto dentro un altro while e
ottenere lo stesso risultato:
while(true){
  while(state ...){
    ...
  }
 
  if ...
  if ...
  else break;
}
Ma IMHO non è ne più chiaro ne nulla.


 come Linux è realisticamente impensabile :)
Sciocchezze. Se dai un'occhiata qui: 
http://www.research.att.com/~bs/applications.html
troverai diversi sistemi operativi scritti in C++, da BeOS a OS/400.
Qualcun'altro poi ci crede abbastanza da realizzare questo:
http://netlab.ru.is/exception/LinuxCXX.shtml
Ciao,
Nicola

 Nicola
-- 
Salvatore

 come Linux, cioč mi riferivo proprio a Linux.  
Si, ma č impensabile perchč *oggi* č scritto in gnu C e portarlo a C++ č
una mina, non tanto perchč se fosse in C++ la cosa non potrebbe fungere.
Uno anche se usa C++ mica deve usare bloatware ogni 3x2...


 Uno anche se usa C++ mica deve usare bloatware ogni 3x2...
Certo. Del resto sono talmente tante le applicazioni scritte in C++ che 
a volte Java mi sembra un "di più": di sicuro possiamo dedicarci alle
applicazioni, non è il caso di riscrivere tutto il codice C funzionante
in C++, a meno che non si evidenziano drastici miglioramenti tali da
incoraggiare ad intraprendere una mole di lavoro così. 
Ciao :)
-- 
Salvatore

 wrote in message 
news:1190497569.9...@r29g2000hsg.googlegroups.com...


Bhe, il fatto che il kernel di linux sia scritto ancora in C la dice lunga..
Sģ, ma Linus Torvalds deve decidersi perché un tempo la pensava
diversamente. Non ha mai scartato da principio l'idea di scrivere il
kernel di Linux in C++; semplicemente, allora, non trovava
programmatori (compreso lui immagino) che conoscessero questo
linguaggio abbastanza bene. Se ora dice che quella scelta era
ponderata, non č coerente e questo contribuisce (insieme alle sue
supponenti risposte al buon vecchio Tanenbaum) a farmelo stare sulla
coglia.

 coglia.
quasi quasi mi stupisce come il suo kernel sia (a ragione) così tenuto
in seria considerazione nonostante l'aria fanzinara molto tardo-
adolescenziale del suo creatore... peccato.

 in seria considerazione
Su quel codice hanno lavorato parecchie persone. Non è da tempo l'opera 
di una persona sola.


naturale!, ma le cazzate dette dal gran capo fanno una eco più vasta
del lavorìo di molte persone, purtroppo.
ciao.

 lunga..
Si', pero' quando in C vedo certe cose (puntatori char* interni ad una 
struttura castati ad un'altra e passati come valore di ritorno da una 
funzione), mi viene in mente la programmazione per strutture passate in 
memoria tra ***PROCESSI*** di Windows a 16 bit, orripilante....
FlickerFree.

 del lavorìo di molte persone, purtroppo.
Però questo è un NG di programmazione. Infondo a casa ho svariati libri 
del Tanenbaum, e neanche uno di Torvalds. Quelli sui pettegolezzi su 
mondo intorno a Linux ( che ho comprato :-) ) sono poi in una sezione 
ben diversa da quelli di programmazione.

del lavorìo di molte persone, purtroppo.
Non è detto che Torvalds abbia detto cazzate, così come Tanenbaum non
ci è andato leggero, ma il secondo è più perdonabile del primo, a mio
parere e le sue opinioni (forti della grande esperienza che ha nella
scrittura di sistemi operativi) sono comunque valide, a mio parere, a
prescindere dal successo avuto poi dal Linux monolitico. Come al
solito, il tono in cui si trasmette qualcosa contribuisce o meno a far
riflettere gli altri. Se aggredisci, nessuno avrà voglia di analizzare
approfonditamente ciò che dici. Magari, se Linus fosse stato meno
indisponente e Tanenbaum un po' più morbido, oggi avremmo un Linux
migliore :-)

 oggi avremmo un Linux migliore
Il linux di oggi non è poi quel monolite tremendo di un tempo.

 migliore :-)
Già ed è molto triste, tenendo conto di cosa capita in casa MS (vedi
il quasi-disastro Vista) basterebbe così poco per imporsi. Per
curiosità: hai qualche link sulle dichiarazioni di Tanenbaum?
ciao.

curiosità: hai qualche link sulle dichiarazioni di Tanenbaum?
E' una diatriba famosa. Se non ricordo male erano messaggi scambiati
sul ng comp.os.minix (ma non mi ricordo bene il nome del gruppo) e se
ti affacci su Google riesci sicuramente a trovare qualcosa con chiave
"Torvalds Tanenbaum".

 sia così.
Beh, ho avuto modo di provare per due mesi "Vista Business" a 64bit
per ragioni di lavoro.
Abbiamo avuto (e tuttora la situazione non migliora) serissimi
problemi con i driver
Pensa se dovessimo installare su tutte le postazioni il suddetto:
dovremmo cambiare tutte le stampanti (tre anni di vita, laser, di
marca non sconosciuta) della rete. E si pensi al fatto che è stato
assemblato un computer (nuovo ad hoc). E' indubbiamente un disastro...
Per il resto nulla da obiettare, ma siamo OT e sento puzza di flame...
ciao.

[...]E' indubbiamente un disastro...
Con tutto il rispetto, non me la sento di definire questo sistema
operativo "un disastro", a livello oggettivo, in base a quello che mi
racconti. Il problema (sempre a meno di definire che si intenda per
"problema") dei driver riguarda il produttore dell'hardware, non del
sistema operativo.

 sistema operativo.
E' un disastro perché, come al solito, PRIMA si commercializza e POI
si tappano i buchi (a quando il Service pack 1 per Vista?).
suvvia! Sappiamo come vista si sia imposto negli ultimi mesi: Troppe
versioni con l'aggravante di penalizzare i primi utenti  facendo
calare (non per ragioni fisiologiche) il prezzo; utenti che
palesemente non lo vogliono (e non sono 4 gatti tant'è che hanno
dovuto pure creare nuove licenze XP e, obtorto collo,  hanno
prolungato il periodo di commercializzazione di altri 5 mesi);
computer "brand" che, prodotti  e venduti nel periodo di mezzo, si
tramutano in periferiche non funzionanti, crash, lentezza generale del
sistema e i forum ne sono pieni di casi. So benissimo che ci sono
periferiche per Vista ma è possibile comprare tutto da capo? E poi
l'hai detto te: di computer con Vista non ne vedi molti in giro...
Se produttori a livello mondiale non riescono ancora a fare driver
decenti per Vista o si sono rincoglioniti oppure... o no?
Scusami lo sfogo.
Ciao.

 il quasi-disastro Vista) 
io non ho Vista e non lo conosco ... cosa intendi per 
"quasi-disastro" ? Flop commerciale, bug, inefficienza, 
intrusività, o che altro ?
ciao
Soviet



Flop commerciale, bug e "poca comunicativa" con le periferiche.
Che poi ci mettano tante pezze da renderlo presentabile fra due anni è
tutto un altro discorso.
Ciao.
PS.
Ancora svegli a quest'ora??? :)

si tappano i buchi (a quando il Service pack 1 per Vista?).
Non è un disastro, perché questa è la prassi a cui sono sottoposti
*tutti* i software. Il tuo discorso non ha senso. Non si può produrre
un software che non abbia difetti, tantomeno se si sta scrivendo un
sostrato complesso come un sistema operativo. Tu parli di "buchi" da
tappare, ma quelli che citi a me non sembrano buchi del sistema
operativo. Quello che accade con i service pack per i sistemi
operativi Microsoft accade ugualmente per il kernel di Linux, solo che
nel primo caso fa notizia, nel secondo no. Dal mio punto di vista,
invece, è ancor più "disastroso" il caso di Linux, perché le nuove
versioni vengono fuori molto più spesso che non i SP Microsoft (con XP
ce ne sono stati 2, niente di così disastroso). O pensi che quelle del
kernel di Linux non siano patch? Tu dici di vedere come Vista si sta
imponendo, ma la pluralità di versioni non è un difetto, anzi. E poi
io vedo che gli utenti che non lo vogliono sono quelli mossi perlopiù
da pregiudizi. D'altro canto, è normalissimo che la penetrazione del
mercato da parte di un prodotto dipenda dalla capacità di spesa e
dalle esigenze degli utenti: un utente che si trova bene con XP e non
vuol spendere soldi per un nuovo sistema operativo, vive felice e
contento con XP. Si deve ritenere anche questo uno scontento del nuovo
sistema? sarebbe disonesto pensare questo. Torni a parlare di
fantomatici "crash", di "lentezze generali". Troppo generico e comodo
parlare così. Le periferiche non funzionano perché i propri produttori
non si sono adeguati al sistema operativo (come se fosse una novità,
d'altronde, certi driver sono scritti coi piedi). Chi ti ha detto che
devi comprare tutto daccapo? a te sembra plausibile che un'azienda
costringa gli utenti a ricomprare tutte le periferiche hardware?
Concludo dicendo che quando io affermo di non vedere molti computer
con Vista in giro, intendo che prima di giudicare questo sistema
operativo come "disastroso", mi aspetto che vi sia un uso consistente.
Se il sistema non è ancora diffuso è in gran parte per immotivata
diffidenza o per mancanza di convenienza nel passaggio.

e "poca comunicativa" con le periferiche.
Ma per favore!

 kernel di Linux non siano patch? Tu dici di vedere come Vista si sta
LOL!!!
Ma per favore!!! Tu non hai la minima idea di che cosa stai parlando!!!!
Evita, che è meglio...
mik

 sistema operativo.
Con questa definizione Linux sarebbe un OS perfetto!
E.

 *tutti* i software. 
Questo non è vero!
1- c'è software che lo compri una volta e funziona sempre, senza bisogno 
di patch.
2- c'è software che non è necessario comprare.
Non ci si può rilassare al "tanto fan tutti così..."
E.

 diffidenza o per mancanza di convenienza nel passaggio.
E vorrei vedere se non si avessero convenienze! Mica utilizzo XP (da
qualche mese!) per il piacere dell'occhialuto Guglielmo Cancelli :)
Spero di essere stato chiaro che qua si sta come al processo di
biscadi: sempre a "precisare"... :)
Ciao ciao.

 diffidenza 
Io vorrei infatti capire se la mia diffidenza, che è nata con XP 
ed a causa di XP e si estende a VISTA per mera estrapolazione, 
sia immotivata o meno. L'ambito però è solo quello detto : lo 
spregio della privacy per non dire la spioneria e le ingerenze 
dell'OS con le connessioni di rete.
tu che lo conosci bene, come ti trovi in questo senso ?
Sai se si possa rimediare, o non senti il problema, o lo tolleri 
gioco forza ?
ciao
Soviet



Di Vista ho provato la Home edition...seguito da un rapido format
del disco e reinstallazione di XP multimedia edition: non funzionava
praticamente niente, i filmati DVX si bloccavano, mancano i driver
per le periferiche.... lentezze mostruose (su un dualCoree con 1Giga
RAM). Aspetto l' imminente SP, magari migliora e non butto nel
cesso il DVD, anche perche' l' ho pagato.......
Brix

 Ma per favore!
Al momento, e' vero. Cambiera' ma ci vuole un poco di tempo.
Ho un sacco di applicazioni che non funzionano piu' come dovrebbero
su Vista ;-(
Brix

 un suo costo computazionale.
Guarda, ho qui il controesempio. Leopard è *più* veloce e *più* reattivo
sulla mia macchina. Un portatile G4 di parecchi anni fa. Per dire.
Non è che *necessariamente* un OS debba essere più pesante. 

 sistema operativo.
Vero, però molti detrattori di Linux usano proprio la mancanza dei
driver (responsabilità del produttore) per concludere che Linux fa
schifo. Come dire, ci sono sempre due facce, nessuna delle quali scritta
in C++. :)

 "C++ is a horrible language.
Beh... che è NATO in C++ e non può essere certo riscritto da capo. I 
prodotti <<commerciali>> (un po' come gli <<uomini>>) spesso non conta 
solamente se sono validi o no, ma se nascono nel momento giusto, se 
hanno fortuna... Sono parecchi gli ottimi prodotti che non hanno MAI 
avuto successo.

 avuto successo.
Infatti: pensa al caso "Oberon". Non che sia (fosse?) proprio da
buttare...
ciao

 buttare...
O pensa ad un Win vs. *nix:
- *nix č 10.000 volte migliore di Win, che č ancora un DOS (poco) 
evoluto ed č free
- Win č il s.o. piů diffuso al mondo
Ovvero, Win vs. Mac:
- Mac usava le <<finestre>> quando Microsoft era in <<bianco e nero>>
- Win ha copiato Mac e... qualcuno dice che č migliore di Mac (!)

 - Win ha copiato Mac e... qualcuno dice che è migliore di Mac (!)
ma quant'era bello il commodore 64... ma anche allora c'era lo
spectrum che rompeva... sta storia non finirà mai :P
ciao.
PS.
Appassionato del regista K. o dello scrittore T.???

 spectrum che rompeva... sta storia non finirą mai :P
...se non c'era gią, dopo poco č arrivato l'Apple I, che li azzerava 
entrambi.

  Win, che è ancora un DOS (poco) evoluto
no, davvero. o tu non hai contatti con l'informatica da almeno un 
decennio, oppure sei un troll che tenta di giocare con argomentazioni in 
voca dieci anni fa pure loro.

 voca dieci anni fa pure loro.
Complimenti per le argomentazioni <<No, davvero>> e la fantasia <<Sei un 
troll>>.
(((((((((((((((-:
Cmq stai tranquillo, tra un po' slinko, per ora il C++ non mi interessa più.
BTW: i programmatori da sempre sono stati dei complessati e dei palloni 
gonfiati (-;

 Complimenti per le argomentazioni <<No, davvero>> 
non è che ci fosse un gran bisogno di argomentare.
Sicuramente se uno arriva e afferma che il sole è blu, ci può 
essere il tizio su cento che si imbarca in una dimostrazione 
rigorosa, e gli altri novantanove che ritengono sufficiente dire 
: "guarda meglio".
In effetti in XP (e già in Win98-II edition) era proprio il 
DOS-core a non esistere più. PErsino la DOS-box è diventata 
emulata, e te ne accorgi se debuggi un programma che pensa di 
operare in DOS 16 bit e fa le sue brave chiamate di sistema 
(INT), e se debuggi meglio a livello di disassemblato, vedi bene 
che sono tutte quante intercettate e servite dal kernel32 (o 
dalle DLL complementari), per cui il DOS visibile è solo un 
simulacro emulato, tanto per garantire la retrocompatibilità.
Anche le chiamate dirette al bios (almeno le più comuni) sono 
filtrate dal O.S.
ciao
Soviet_Mario


 dal kernel32 (o dalle DLL complementari)
Capisco. Senti... io invece sono una povera testa di cazzo. Me la 
spieghi una cosa facile facile (per te)? Perché se ho un processo in 
esecuzione e mando un <<kill>> con Linux, quel processo termina alla 
velocità della luce; e perché se vado nel task manager di Winzoz e mando 
un <<canc>>, faccio in tempo a farmi panino con nutella, torno ed ancora 
non è killato?

 non è killato?
io uso
Process Explorer 9.25, è un task anager freeware per windows, e 
sulla mia vecchia macchina non è particolarmente lento, killare 
killa subito (poi quel che succede dipende da cosa hai spento 
ovviamente, perché puoi spegnere anche servizi essenziali al 
sistema stesso).
Cmq, ammettendo che Linux sia di per sé più efficiente e 
performante di windows (cosa che forse è probabile ma non posso 
dirlo in prima persona), non capisco cosa c'entri questa 
considerazione col fatto che windows attuale sia solo una sorta 
di DOS mascherato. Io commentavo quella frase e stop, dato che 
non era vera.
Se vuoi dimostrare che secondo te è vera, fai degli esempi 
calzanti nel merito.
Ah, per rinforzare la cosa : nemmeno il file system nativo di XP 
è rimasto l'antico FAT32 del DOS, cosa detta in un recente thread.
Poi forse non abbiamo la stessa definizione di cosa significhi 
rimanere uguale o semplicemente derivare da.
ciao
CCCP++Mario

 non è killato?
Entrambe le affermazioni sono sbagliate. In entrambe i sistemi dipende
da come sono scritte le applicazioni e da quale segnale usi per
cercare di ucciderle. Su entrambe i sistemi poi e' raro ma non
impossibile che una combinazione di livello di priorita' e interrupt
mask faccia si che anche un segnale non intercettabile venga
temporaneamente ignorato.
Ciao,
Nicola
P.S. Per pura coincidenza ho appena fatto fuori qualche decina di
processi dal task manager di Windows e sono tutti scomparsi
all'istante.

 Entrambe le affermazioni sono sbagliate.
Aggiungo alla tua ottima precisazione che se uno lo fa da task manager 
dal pannello "applicazioni" non viene fatto un kill stile unix, ma 
viene mandato un messaggio alla finestra principale dell'applicazione 
con la richiesta di chiudersi.
Siamo arrivati al punto che si usa la propria ignoranza su windows per 
parlarne male. Se uno non è capace di usarlo dovrebbe per prima cosa 
chiedere.
Poi se si vuole temperare le supposte, e immagino che tu non lo hai 
fatto per non infierire, un conto è mandare un segnale tipo control c o 
simili e un conto è terminare un programma. Queste segnali sono 
intercettabili dal programma; l'azione di default del S.O. per un 
segnale simile al cntrl c è la terminazione del programma. Un altro 
conto e "terminare" con una chiamata al S.O. un processo. Se si hanno 
sufficienti diritti amministrativi per "lanciarlo" questo non è 
intercettabile dal programma.

 simili e un conto è terminare un programma.
Mai temperato supposte, sono un pragmatico: una cosa o funziona o non 
funziona. Se poi uno si vuole convincere che il task manager di Winzoz 
scritto in C++ funziona bene... zzzi suoi, non mi tocca (-:
Io oramai uso solo Winzoz, ma sono pienamente consapevole che è il 
peggior S.O. mai venduto sul mercato. Come dire: io sono una troia, ma 
non vado in giro a dire che sono una crocerossina. Ed IMHO il problema 
dei S.O. è nato proprio con DOS, residente su disco; il CP/M era molto 
meglio. Ma non era un buon prodotto commerciale.
BTW: chissà non si ritorni ad un s.o. su firmware prima o poi.

 non è killato?
Probabilmente perché su Linux dai il comando direttamente dalla console 
(o da un terminale virtuale) e il comando arriva direttamente al kernel. 
In windows, invece, devi interfacciarti con il sistema a finestre che 
probabilmente (visto che vuoi killare un processo) è un po' sotto 
pressione...
Questo è un problema piuttosto generale se non hai un sistema ben 
"conservato". Sul mio computer ho cronometrato 35 secondi per cancellare 
un file con Windows! Ovviamente su Linux il file viene cancellato prima 
che ancora che il tasto invio si sia sollevato...
E.

 pressione...
Infatti ho divorziato da Linux il giorno che hanno puntato sulle 
interfacce grafiche. Senza contare la complicazione: prima in c:/etc 
c'erano una decina di files, con 3 - 4 settavi la macchina e facevi 
tutto; ora conl'interfaccia grafica sei fortunato se riesci a stampare. 
E senza contare che un kernel stava perfettamente incapsulato in meno di 
640 Kb, senza <<chioccioline>> e chiamate esterne.

 interfaccia grafica...
Ciao e grazie di tutto: io stacco da questo ng di  erda. Alla prossima,

 contrario di Windows,
Su un server windows, se non ti colleghi alla console, non ha nessun 
gestore di finestre caricato. Windows ha le sue grosse magagne, ma non 
ho sentito nemmeno uno che le citasse. Forse perchè le *grosse* magagne 
non sono visibili nei sistemi "comuni".

 disposizione, l' altro e' proprietario e completamente *ignoto* ...
...
questo non è vero, e però sono in molti a sostenerlo. MS fa vedere i 
sorgenti alle aziende che glie lo chiedono per sviluppare prodotti su 
WIN (ovviamente a certe condizioni).
Ad esempio vedi 
http://www.microsoft.com/resources/sharedsource/licensing/default.mspx
Veramente non ho voglia di fare polemica (e a dire il vero non ne ho 
neppure il tempo :) )
Ciao
GM

 quali API "undocumented"
Se lo dici tu ci credo. Tu lavori abitualmente con CE vero? Tra l'altro 
immagino che tu lavori abitualmente con Linux ritagliati su misura. Che 
tu sappia come configurare e ricompilare il kernel e che tu lo faccia 
abitualmente
Comunque io lavoro in una ditta e per essa scrivo sofware commerciale. 
Io mi pago il mutuo con quello. Linux o Windows non me frega un cazzo.
Sulle documentazione poi stendiamo un velo pietoso. Mi sembra evidente 
che tu non sei un professionista.


Bah!non mi pare proprio...sembra ogni accenno di critica verso *windows* 
sia interpretata come reato..
ma lavorate tutti per Bill???????????

 che tu non sei un professionista.
Acci, mi sono sbagliato ancora... un evidente demente.

 non sono visibili nei sistemi "comuni".
Puoi installare Windows su un computer senza scheda grafica?
E.

?manu* ha scritto:

Non capisco a cosa miri la tua domanda, ma la risposta è si.

 Per il resto nulla da obiettare, ma siamo OT e sento puzza di flame...
Per riportare il discorso in topic, da quel che ho visto dell'interno
del kernel di linux (sviluppo tra le altre cose anche qualche semplice
driver), le interconnessioni tra parti diverse del kernel, ad esempio
verso i driver, sono costituite da grandi tabelle di puntatori a
funzioni... vi ricorda nulla? Mi son sempre chiesto per quale ragione
non intervenire radicalmente utilizzando un linguaggio che tali
meccanismi li rende nativi. La spiegazione è più politica che tecnica,
uno zoccolo duro che, fatta una scelta, non è disposto ad ammettere che
gli strumenti utilizzati fino ad ora sono impropri.
Regards,
ing. Federico Fuga

 forza ?
Io mi trovo meglio con vista che con xp.
E il motivo è il tanto criticato UAC, che permette tranquillamente di
lavorare da utente e di impersonare l'amministratore solo quando necessario.
Qualche fastidio c'è, ma c'era anche con xp e c'è anche con Linux (uso
SuSE dalla 9.1); credo sia normale, anche se non dovrebbe essere cosi'.
Il sistema perfetto non esiste, esistono diversi sistemi più o meno
perfettibili sulla base delle singole esigenze.

 funzioni... vi ricorda nulla?
...eh già. Io ho trovato molto istruttivo guardare il codice delle 
librerie X11, è codice orientato agli oggetti, con funzioni membro 
tabelle virtuali e tutto il resto... scritto in C! Ma credo che la 
motivazione sia più che altro storica.
E.

?manu* ha scritto:

Si. Ma è ridicolo criticare poi il c++ ed affermare che il C è meglio. O no?

 Si. Ma è ridicolo criticare poi il c++ ed affermare che il C è meglio. O no?
Sì, secondo me è ridicolo.
E.

 gli strumenti utilizzati fino ad ora sono impropri.
La spiegazione č economica: hai idea di quanti soldi (o ore uomo o
quello che vuoi) siano necessari per riscrivere tutto quanto da 0?
Per non parlare del costo di ritestare tutto, convincere le aziende che
a passare a codice molto meno maturo, riscrivere tutti i vari moduli.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 sistema operativo.
Stiamo confondendo due piani: uno prettamente tecnico, kernel e
quant'altro, e l'altro "commerciale".
Ho già scritto che il problema è come è stato imposto il un nuovo
prodotto. Per i driver prima o poi se ne verrà a capo.
Scusa mettiamo il caso che a WinXP sia assicurata manutenzione,
aggiornamenti e la possibilità di acquistarlo per molti anni. Secondo
te quanti passerebbero a Vista?
ciao.

 funzioni... vi ricorda nulla?
beh qualcosa sì ;) Ma chi si mette a riscrivere tutto in C++???
Ciao.


A proposito di kernel. Che ne pensate di questo?
http://www.ilsoftware.it/news.asp?ID=3934
ciao.

   
Meglio tardi che mai, era ora che scorporassero  la parte grafica dal 
kernel
(questo discorso mi ricorda qualcosa....) :-)
Quello che secca in Windows e' che prima o poi usano tecnologie sviluppate
da decenni (da altri!) e le fanno passare per grossi imprrovvementt e le 
spacciano
per "novita'".
....Anche se 25Mbytes di kernel non puo' proprio essere definito un 
"micro-kernel" :-)
brix

 a passare a codice molto meno maturo, riscrivere tutti i vari moduli.
Il kernel in gran parte si interfaccia con dispositivi hardware, tali 
dispositivi si usano fondalmentalmente scrivendo e leggendo registri, 
siano essi una MMU, hard disk, il program counter da impostare sulla CPU 
o una scheda di rete... sono operazioni a basso livello che mal si 
adattano ad un paradigma object oriented, non dico che non si possa fare 
in C++, ma i vantaggi sarebbero limitati rispetto a farlo in C.
In questo senso sono d'accordo anch'io che il C++ non sia adatto al 
kernel, anche perche` con il C++ puoi perdere il controllo di quello che 
succede sotto (esempio: quante allocazioni sull'heap vengono fatte in 
una semplice gestione di stringhe "std::string a = b + c;" ? ) , e 
quando si programma un kernel non aver chiaro quello che succede sotto 
non e` una buona cosa.
Un altro problema del C++ e` l'esplosione della dimensione del codice, 
in particolare quando si usano classi template. Tutta l'STL e` 
"templatizzata", quindi se si usa l'STL il codice "esplode". Linux gira 
anche su cellulari e palmari e il kernel puo` avere un footprint di 
poche centinaia di KB, se si scrivesse in C++ usando l'stl per i 
container, le stringhe e qualche classe template qua e la per rendere 
piu` typesafe il kernel si perderebbe anche questa IMPORTANTE feature 
del kernel.
In questo senso sono d'accordo anch'io a tenere il C++ fuori dal kernel, 
le motivazioni di Linus sono simili, lui pero` fa solo sviluppo a 
livello di kernel e quindi si puo` permettere di odiare il C++ :)
Se uno sviluppa grosse applicazioni in userspace, magari con interfaccia 
grafica, puo` permetterselo un po` meno :)
Bye,
  Gabry

 livello di kernel e quindi si puo` permettere di odiare il C++ :)
Linus ha detto un'emerita c.....a ed il fatto che l'abbia detta lui
non la rende meno tale. Secondo me nella sua posizione dovrebbe fare
molta piu' attenzione a quello che dice. "Da un grande potere derivano
grandi responsabilita'", come diceva zio Ben. Anche in questo avrebbe
parecchio da imparare da Bjarne Stroustrup ;-)
Ciao,
Nicola

 del kernel.
Si, ma attenzione, sviluppare in C++ non vuole dire *necessariamente*
usare la stl. Addittura puoi non linkarla affatto.
Nel caso si tratterebbe di usare il *linguaggio* per supportare
ereditarietà e tutto. Inoltre la maggior parte delle features di C++ se
non le usi non le paghi. Tipo RTTI.


 a passare a codice molto meno maturo, riscrivere tutti i vari moduli.
Oggi è vero, ma l'altro ieri non lo era. Un po' più di lungimiranza
sarebbe stata una buona cosa, secondo me.

 grafica, puo` permetterselo un po` meno :)
Eppure ci sono delle teste dure (gnome) che continuano ad usare il C
come se fosse C++ (con pseudo-classi e pseudo oggetti)....

 te quanti passerebbero a Vista?
Sono pochi, ma il mercato non è un buon peso per la qualità tecnica. Il
99% delle persone che si lamentano lo fanno per esempio per l'UAC,
perché rompe le scatole; e usano il pc da admin. Qui è ignoranza, non è
bassa qualità del software.
Ad ogni modo le magagne se vuoi ci sono: con visual studio .net 2003 e
vista si bestemmia non poco. Però non so se con XP sarebbe stato diverso
(mio caso specifico, però).

 "micro-kernel" :-)
Oddio, il termine microkernel è infelice, indica tutt'altra tecnologia
di sistema operativo... neanche linux è un microkernel. Al di là delle
dimensioni.
Ma da quel che ho capito, intendevano piuttosto micro-sistema operativo,
tipo il uLinux di un tempo, kernel + librerie + console. Sarebbe
decisamente interessante.

 dimensioni.
No, aspetta un attimo:
guarda che il termine microkernel non ha nulla ache vedere con le 
dimensioni.
Si tratta di un'architettura diversa rispetto al cosiddetto "kernel 
monolitico" che è proprio il kernel di linux.
Proprio il nostro amico Torvalds, prima delle sparate di cui stiamo 
parlando ora, divenne famoso proprio per un'accesa discussione con un 
tal Andy Tannenbaum (che sui SO ci ha scritto un tot di libri...) a 
proposito del confronto microkernel (Tannenbaum) vs. monolitico 
(Torvalds). Cerca su wikipedia kernel per maggiori dettagli.
In realtà windows è un'architettura per certi versi simile al 
microkernel (alcuni parlano di "kernel ibrido").
GM

 microkernel (alcuni parlano di "kernel ibrido").
In che senso "per certi versi"?

 quello che vuoi) siano necessari per riscrivere tutto quanto da 0?
Mi chiedevo se c'è un metodo sensato per convertire progressivamente il 
C in C++. Probabilmente partendo dall'alto livello e andando verso il 
basso si può fare. Cominicio a convertire il main, poi le funzioni 
chiamate dal main etc...
E.

 latte alle ginocchia.
BTW, l'IOKit di OS X è scritto precisamente in embedded C++.
Precisamente per i vantaggi che elenchi, fra gli altri.


 In che senso "per certi versi"?
Non direi proprio! E' un kernel monolitico che piu' monolitico non si puo'.
brixx

 
Questo non è vero:
linux è "un kernel monolitico che piu' monolitico non si puo'",
windows è "una via di mezzo".
Se non ne sei convinto ti cito ad esempio:
http://en.wikipedia.org/wiki/Architecture_of_Windows_NT
http://www.microsoft.com/technet/archive/ntwrkstn/evaluate/featfunc/kernelwp.mspx
Ciao
GM

GM ha scritto:

Wiki stessa dichiara che il termine e' quanto meno "discusso" :-)
Il modello ibrido si riferisce al fatto che alcune funzioni tipiche del 
kernel possono
essere eseguite nello user space. A parte che questo e' vero anche per 
linux,
che quindo potrebbe anche essere dischiarato "modello ibrito" esso stesso.
Il temine monilitico si riferisce al fatto che tutti i componenti  del 
kernel 
costituiscono sostanzialmente un unico programmone compilato tutto insieme
ed indivisibile: anche questo per Linux non è piu' vero, da quando e' 
possibile
inserire i moduli direttamente nel kernel in modo dinamico.
Per Windows NT e' vero che il kernel è modulare, cioe' non è un unico 
programmone,
ma di fatto i vari moduletti alla fine costituiscono un tutt' uno, sono 
di fatto un kernel monolitico
e girano tutti nello stesso unico contesto.
Se poi vogliamo chiamare "modello ibrido" il fatto che nello spazio user 
si possano realizzare
dei driver, o qualcosa di simile, va be... pero' questa "funzione" usa 
poi delle chiamate
al kernel (tramite wdm o simili) per cui in realta' e' sempre un 
programma user che si
appoggia in definitiva al kernel...cosa che tutti i sistemi monolitico o 
meno possono o potrebbero
fare.
I micro kernel sono tutta un altra tecnologia, e ne' Linux ne' Windows 
lo sono:
http://en.wikipedia.org/wiki/Microkernel
http://www.qnx.com/products/neutrino_rtos/microkernel.html
bye
brix

 chiamate dal main etc...
Io però ho paura che così uno finirebbe per scrivere pessimo codice C++.
 Tipcamente seguendo questo approccio le struct diventerebbero classi
con attributi privati, funzioni per accederli derivate dai metodi che
prima manipolavano le struct. 
Costrutti ad hoc di C per simulare features OO verrebbero sostituiti da
quelli di C++, i tipi verrebbero stretti...
Ma il tutto soffrirebbe del problema che rimarrebbe codice progettato in
C. Quando progetto in C++ (e sono soddisfatto del mio risultato),
tipicamente non ho agito come avrei agito in C. Ho enti che servono a
maneggiare le risorse che non sono traduzione 'naturale' di roba C (che
appunto non necessariamente esisterebbe, sarebbero semplici chiamate di
funzione qua e la con errori gestiti esplicitamente punto per punto).
E poi pensa: praticamente significa riscrivere tutto. Badaci. La
gestione degli errori la riscrivi perchè trasformi i vari goto locali,
gli errno o analoghi in eccezioni. Le struct le riscrivi perchè nascondi
i membri (che divengono privati): ergo tutto il codice che le manipola
deve essere cambiato.
Insomma, IMHO a quel punto tanto vale scrivere il tutto da 0, sfruttando
a pieno il C++ (per esempio i template non vengono 'ovvi' da una
traduzione da C, in alcuni casi si, ma in altri casi in cui avrei usato
pesantemente il compilatore probabilmente il codice corrispondente non
c'è e basta).


 come se fosse C++ (con pseudo-classi e pseudo oggetti)....
Pero` in quel modo hanno realizzato GTK che e` un toolkit molto + 
scalabile, portabile e diffuso nell'embedded che non QT o wx, nonostante 
trolltech sull'embedded ci abbia puntato molto.
Inoltre GTK e` molto + diffuso rispetto ai citati WX e QT in C++ Tper 
applicazioni GUI "agnostiche" rispetto al desktop enviroment.
La verita` e` che portarsi dietro il runtime C++ nelle librerie di 
appoggio dell'applicazione e` una brutta rogna (su linux dove e` 
cambiata tre volte l'ABI in 8 anni e distribuire un'applicazione C++ 
binaria che funzioni su tutte le distribuzioni e` un'utopia), e' pesante 
(su windows, dove di solito viene linkato staticamente, idem e su mac 
fino al 10.4).
Tra l'altro sia QT che WX per dire si portano dietro il fatto che sono 
nate quando l'STL non era cosi` diffusa e stabile e si riscrivono la 
ruota per stringhe, container, ecc, ecc... lo fa anche GTK in glib, ma 
li` la cosa e` utile in quanto la libreria standard del C non ha quelle 
funzionalita` :)
--
Bye,
  Gabry