Linguaggi a confronto.

[TheKaneB]

• 

esattamente :-)

Il Ref counting però nei giochi si lascia, perche le allocazioni le fai esclusivamente durante i loading e mai a frame time.
Se ti serve allocare a frametime, si usa un allocatore con object caching.

EDIT: Ovviamente parlo sempre dei giochi perchè è con quelli che mi sono fatto le ossa, comunque si tratta di tecniche universalmente usate..

[cdimauro]

• 

Sull'uso dell'indentazione e dei : nelle istruzioni è intervenuto Guido nel suo blog.

[Z80Fan]

• 

Io continuo a non capire; perciò, vi chiedo, data la vostra maggior esperienza, di rispondere a questa domanda che può sembrare una provocazione ma che non lo è:

Se il C è il Demonio in persona e Python/Algol/Modula è il linguaggio del futuro, perchè si usa ancora il C ? (userò C per indicare sia C che C++, e potenzialmente linguaggi derivati ma molto vicini a esso come PHP).

Non accetto come risposta "perchè è il più diffuso e c'è molto codice legacy scritto in C", poichè vengono iniziati nuovi progetti in questo linguaggio (C++ in questo caso, non C puro). Non dico che si debba iniziare in ALGOL-60, ma presumo che uno sul Python ci faccia un pensierino.

Se proprio la risposta sopra è l'unica possibile, allora rispondete a questa domanda: perchè si è diffuso il C ? C'erano già molti linguaggi a quel tempo, pure Pascal ha la stessa età del C, quindi perchè si è diffuso il C ?

"Perchè UNIX è scritto in C". Bene, e cosa impediva di scrivere un compilatore di $linguaggio per UNIX e usare quello?

Ho notato che Wikipedia dice che le prime versioni di MacOS e Windows erano scritte in Pascal (per MacOS posso confermare, lo ho letto più volte, e sono almeno sicuro che MacPaint fosse scritto in tale linguaggio); perchè non si è continuato per quella strada? (E sistemi operativi in vari linguaggi ci sono e non son tutto 'sto complicato).

Ripeto: non voglio provocare nessuno, voglio solo capire il perchè; 'sto maledetto C/C++ avrà qualche qualità che lo ha fatto sopravvivere, non penso sia applicabile la storia del Betamax vs. VHS.

[cdimauro]

• 

E dopo questo bel commento di dsar, direi che si può chiudere.

A parte gli scherzi, concordo e aggiungo giusto qualche sciocchezza in ordine sparso:
- il codice legacy C è una realtà con la quale bisogna fare i conti;
- il C si presta bene, per quanto già detto, a sviluppare codice "di sistema" (kernel, driver, librerie di basso livello);
- causa diffusione, c'è tanta gente che lo usa anche per sviluppare applicazioni che si farebbero meglio (e prima) con altri linguaggi (sì, c'è anche gente che sviluppa applicazioni web in C/C++!);
- se ti piace un linguaggio, tendi a usare quello per tutto (questo è legato al punto precedente).

Un esempio che mi viene in mente è quella porcata di GTK: un framework a oggetti realizzato in C. Un autentico abominio, insomma, e si vede a colpo d'occhio:


P.S. E' interessante notare come la stessa immagine sia sparita dalla versione inglese della voce GObject di Wikipedia (l'ho recuperata da quella spagnola). Si vede che qualcuno l'ha tolta dopo tutte le volte che l'ho citata come pessimo esempio di "emulazione" degli oggetti in C. :lol:

[TheKaneB]

• 

Per TheKaneB:
http://brinch-hansen.net/memoirs/photos ... c4000.html
Lui impiegò quasi due anni per assemblarselo, pensi di competere con un nerd del genere?

sono depresso...  :roll:  :|

[lumo]

• 

P.S. E' interessante notare come la stessa immagine sia sparita dalla versione inglese della voce GObject di Wikipedia (l'ho recuperata da quella spagnola). Si vede che qualcuno l'ha tolta dopo tutte le volte che l'ho citata come pessimo esempio di "emulazione" degli oggetti in C. :lol:

Potresti darmi il link al tuo intervento? Sono interessato visto che in questo periodo mi tocca usare le Gtk D:

[cdimauro]

• 

Ho scritto qualche decina di migliaia di messaggi, per cui riuscire a risalire a quelli in cui ho citato le GTK & GObject è un po' complicato.

Comunque cercando con Google ho trovato un po' di roba. In particolare nel secondo risultato ("Torvalds e C++ [Archivio] ") trovi già qualche citazione in merito (in mezzo a parecchia altra roba :mrgreen: ).

[cdimauro]

• 

@dsar: una domanda. Con Ada, Modula-2 & 3 hai la possibilità di referenziare precise locazioni di memoria?

[cdimauro]

• 

Sì, e da quando il C è un linguaggio sicuro? Segmentation fault rulez.

Comunque anche se formalmente lo standard specifica che soltanto il cast da int zero a puntatore nullo, e viceversa, sono validi, questa caratteristica è stata messa a disposizione da tutti i compilatori e utilizzata da chi ha scritto s.o. e/o driver e/o librerie di basso livello per mappare gli indirizzi fissi dei dispositivi, oppure per implementare velocemente le API di allocazione della memoria.

Se pensiamo all'Amiga (visto che siamo in questo sito, un omaggio a queste macchine è doveroso :ugeek:), poi, è stata pesantemente utilizzata per sviluppare giochi (per i pochi si sono buttati nell'impresa senza usare l'assembly), demo, o applicazioni.

Per questo ho fatto quell'affermazione prima.

[TheKaneB]

• 

mah, siete troppo prevenuti! Guardate la questione dal punto di vista sbagliato, IMHO.... diversamente da voi, trovo che il C sia un eccellente macro assembler  :lol:  :angelic-flying:  :animals-chickencatch:  :animals-cow:  :animals-penguin:  :eusa-whistle:

[cdimauro]

• 

Allora non vedo alcun vantaggio a usare il C, se non per la sintassi concisa (ma ben poco leggibile).

[ShInKurO]

• 

Attualmente invece ho approfondito il Java, perchè sviluppo su Android, e devo dire che mi piace così e così... Avrei aggiunto alcune caratteristiche come gli iteratori stile C++ (quelli stile Java mi fanno pena al cubo), e la possibilità di gestire la memoria manualmente con il "delete". Moltissimi programmatori Java sono erroneamente convinti che il Garbage Collector ti salvi il culo dai memory leaks.
In realtà, con strutture complesse e intricate, capita molto spesso che alcuni oggetti si portino dietro un grafo di dipendenze con vari reference ad oggetti non più utili.
Se non metti a "null" TUTTI i reference di un oggetto, questo rimarrà in memoria ovviamente. Con un bel "delete" esplicito invece risolverei molti problemi di memoria in modo molto più semplice. Potrei anche aumentare le performances dei programmi.

Accade banalmente con degli accessi a db che vanno storti: banalmente si istanzia un oggetto datasource collegato a un db sql,  se la query va a puttane e non ci sta un finally con dentro un try-catch che ti chiude la connessione qualunque cosa accade quest'ultima non verrà mai terminata, anche se si esce dal metodo che ha istanziato l'oggetto incriminato...

[ShInKurO]

• 

- causa diffusione, c'è tanta gente che lo usa anche per sviluppare applicazioni che si farebbero meglio (e prima) con altri linguaggi (sì, c'è anche gente che sviluppa applicazioni web in C/C++!);

EH!??!?!?!??!?!?!??!?!?!?!?!?

[cdimauro]

• 

Ebbene sì: c'è gente che lo usa anche per sviluppare applicazioni web. Giuro! Anzi, se cerchi in giro, ci sono anche dei framework allo scopo. :oops:

[ShInKurO]

• 

Questo significa che GObject organizza i tipi in runtime ad albero, quindi per il method call il dynamic binding viene fatto in runtime traversando un albero, una lentezza spaventosa, al pari di un linguaggio dynamic typing (in realtà peggio, leggi sotto). Il C++ essendo un linguaggio static typing risolve il dynamic binding in compile time, quindi non hai un albero da traversare in runtime.
Ma anche paragonandolo ad un linguaggio dynamic typing, la method table è un array di indirizzi fissi per le funzioni che non vanno dereferenziati, quindi a parte il traverse del tree il calling del metodo è veloce, come la chiamata di una funzione normale. Invece con il GObject hai dei puntatori a funzione, quindi la chiamata sarà più lenta perché avviene il dereferencing.

MI ricorda BOOPSI...