NSA - Non Solo Amiga
SOFTWARE => Linguaggi di programmazione e scripting => Topic aperto da: AmigaCori - 05 Luglio 2011, 22:14:50
-
:auto-car: ----->----->-----> :auto-checkeredflag: Dall'OT del thread: [Hollywood] Introduzione + Help Library (http://http://www.nonsoloamiga.com/forum/viewtopic.php?f=12&t=73&start=30)
Continuate :angry-teeth:
:mrgreen:
-
se si modernizzasse di spazio ce ne sarebbe abbastanza.
Esatto, al giorno d'oggi. Ovviamente quando è stato concepito tutti quei codici erano importanti.
Ma sai com'è, gli standard non si toccano, meglio rimpiangere le vecchie scelte ;-)
Mi sembra anche ovvio; ASCII è perfetto per quello che deve/doveva fare, non puoi prenderlo, modificarlo e chiamarlo ancora ASCII, o ISO 646 (o meglio, modificarlo nei codici di controllo, perchè modifiche locali ad alcuni simboli sono state già fatte, anche se il cosiddetto ASCII è quello primo americano).
Modificare lo standard significa rendere inutilizzabili tutte le macchine vecchie che dipendono da tali codici di controllo, e ciò concorderai non è fattibile.
Se vuoi migliorare la situazione, attui le opportune modifiche e rilasci un nuovo standard (http://http://en.wikipedia.org/wiki/UTF-8). ;)
-
Feature che reputo inutile, il codice andrebbe scritto in un linguaggio che tutti dovrebbero comprendere (tipo inglese).
Perchè, inglese è un linguaggio che tutti conoscono?
E' solo perchè la tecnologia si è sviluppata negli USA e si sono poi diffuse le macchine statunitensi che usiamo linguaggi che ricordano la lingua inglese, e che il linguaggio di Internet è diventato quello.
Cosa sarebbe successo se (guerra a parte) si fossero diffusi gli Zuse? Saremmo qua tutti a discutere dei pregi e difetti del Plankalkül in tedesco? Immagina poi se fossero diventati famosi i giapponesi...
Si da la possibilità di scrivere nel modo in cui si vuole, e con i simboli che si preferisce (rimanendo all'interno della sintassi generale del linguaggio, ovvio). Se poi il listato è illeggibile al di fuori di uno sperduto villaggio dell'Asia, chi se ne frega, non lo userà nessuno.
Bisogna dare delle responsabilità al programmatore, e non sempre puntare il dito al linguaggio che "non obbliga a una scrittura corretta", "non previene tali errori" ecc...
Un linguaggio di programmazione deve fornire un modo per dare istruzioni a un computer; ci sarà della simbologia da seguire, ovvio, ma poi il programmatore deve poter fare come vuole. Se è necessario lavorare in gruppo, ci si metterà d'accordo sulle linee da seguire.
Chiedo scusa per lo sfogo e per il semi-OT (ora AmigaCori mi apre un nuovo thread sulle responsabilità del programmatore :lol:), ma per tanto tempo e in molti luoghi (non qui) ho visto dare colpe dei programmatori ai linguaggi, che di colpa hanno ben poco.
-
Premetto che sono d'accordo con dsar per quanto detto prima. Aggiungo qualcosina di mio.
Il compound assignment è la seconda caratteristica peggiore del C dopo l'equivalenza expression/statement.
Come sopra, non ci trovo nulla di male, idem per la seconda. Poi, se qualcuno le usa a sproposito rendendo il tutto una matassa illeggibile, non penso si possano dare tutte le colpe al linguaggio. :)
Persino professionisti con anni di esperienza a volte sbagliano. Il che è tutto dire.
E' una delle cause principali di bug nei programmi. Un'altra è dimenticare l'& in roba come scanf et similia.
Visto che tu sei "quello delle citazioni" :D, te ne propongo una che avevo letto da qualche parte: "UNIX non impedisce all'utente di fare cose molto stupide, perchè gli impedirebbe di fare anche cose molto intelligenti".
Se poi era solo una scusa per nascondere i bug e farli sembrare features, questo non posso dirlo! :lol:
La seconda che hai detto. :D
E così C divenne un linguaggio che piace a tutti perché molto diffuso :-)
Può piacere o Deve piacere. Nella tua frase stà meglio la seconda versione. ;)
Lo uso (insieme al C++) senza grossi problemi, non trovo tutta 'sta anarchia nella sintassi come molti urlano in giro.
Ho usato/userò ancora Python, vari Basic, vari linguaggi di Script; non sono stato tanto li a interrogarmi sui motivi filosofici della sintassi, la usavo e basta (ad esempio: perchè in Python devo terminare la riga di un if con i due punti ":"? il newline non bastava a delimitare?).
Qui (http://http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html) trovi qualcosa sul perché dei :
Comunque si tratta di una scelta di leggibilità, che riguarda il modo in cui si usano in inglese i : per specificare cosa avviene dopo una frase.
E non dite che è perchè arrivo dal C++ e quindi sono pronto a tutto! :P
Purtroppo sei già stato contaminato. :(
se si modernizzasse di spazio ce ne sarebbe abbastanza.
Esatto, al giorno d'oggi. Ovviamente quando è stato concepito tutti quei codici erano importanti.
Ma sai com'è, gli standard non si toccano, meglio rimpiangere le vecchie scelte ;-)
Mi sembra anche ovvio; ASCII è perfetto per quello che deve/doveva fare, non puoi prenderlo, modificarlo e chiamarlo ancora ASCII, o ISO 646 (o meglio, modificarlo nei codici di controllo, perchè modifiche locali ad alcuni simboli sono state già fatte, anche se il cosiddetto ASCII è quello primo americano).
Modificare lo standard significa rendere inutilizzabili tutte le macchine vecchie che dipendono da tali codici di controllo, e ciò concorderai non è fattibile.
Se vuoi migliorare la situazione, attui le opportune modifiche e rilasci un nuovo standard (http://http://en.wikipedia.org/wiki/UTF-8). ;)
Purtroppo anche l'ASCII è stato modificato, a causa dei soliti noti: http://www.appuntidigitali.it/4581/lf-c ... -di-testo/ (http://www.appuntidigitali.it/4581/lf-cr-o-cr-lf-qual-e-lo-standard-per-i-file-di-testo/)
Ricordo che l'agenzia spaziale russa dovette rifiutare un software perché documentazione, commenti e nomi di identifier erano in francese e nessuno ci capì nulla. Bene o male chi lavora in questo settore l'inglese lo conosce.
Tutti i miei progetti (personali e non) hanno identifier e commenti in inglese.
Certo si potrebbe adottare un linguaggio funzionale, formato solo da simboli matematici, universale per tutti! Magari adottare pure la tastiera usata per Algol 60.
Io non ho nulla contro un linguaggio universale a simboli, il problema è che viviamo una realtà molto diversa da quella ideale. Se il linguaggio matematico, a partire dalla logica, fosse insegnato dalla scuola elementare, allora lì saremmo talmente abituati che potremmo leggere 200 - 300 pagine di un programma fatto di simboli senza stancarci.
Purtroppo la realtà è un'altra. Io studio fisica e per me se una dimostrazione matematica superasse le due pagine la troverei stancante.
Un software deve essere espressivo e soprattutto "alla portata di tutti", anche al meno intelligente, probabilmente io potrei far parte di quella categoria, perché il codice scritto da altri non sempre lo capisco ;-)
Guardati i sorgenti di Elastix... in spagnolo. :lol:
-
Chiedo scusa per lo sfogo e per il semi-OT (ora AmigaCori mi apre un nuovo thread sulle responsabilità del programmatore :lol:), ma per tanto tempo e in molti luoghi (non qui) ho visto dare colpe dei programmatori ai linguaggi, che di colpa hanno ben poco.
Gli OT sono tollerati :geek: i Thread "annidati" no :angry-cussingwhite:
:mrgreen:
-
Ricordo che l'agenzia spaziale russa dovette rifiutare un software perché documentazione, commenti e nomi di identifier erano in francese e nessuno ci capì nulla. Bene o male chi lavora in questo settore l'inglese lo conosce.
Se un software lo scrivi per poi darlo in giro, è ovvio che devi scegliere un linguaggio adatto.
Metti invece un software a uso interno, scriverlo nella lingua nativa dei programmatori sarebbe un vantaggio; conosco gente "del settore" che esegue i più banali errori di grammatica e/o sintassi in inglese, immaginateli a scrivere una documentazione (poi ovviamente il codice riflette la loro conoscenza della lingua ;)).
Quindi, tornando al fatto di permettere l'uso di Unicode nei listati: io penso che sia Cosa Buona e Giusta © :D.
Certo si potrebbe adottare un linguaggio funzionale, formato solo da simboli matematici, universale per tutti! Magari adottare pure la tastiera usata per Algol 60.
Però gli identificatori bisogna lo stesso scriverli in lettere, e torniamo al discorso di prima ;).
Un software deve essere espressivo e soprattutto "alla portata di tutti", anche al meno intelligente
Quindi scriverlo nella lingua nativa lo può rendere più accessibile.
perché il codice scritto da altri non sempre lo capisco ;-)
Ci sono talmente tanti modi di scrivere un codice e implementare un algoritmo che questo frase è vera per tutti i programmatori. :D
Persino professionisti con anni di esperienza a volte sbagliano. Il che è tutto dire.
L'unico caso in cui l'equivalenza può portare a errore "grave" è quando si operano assegnazioni all'interno di una condizione, proprio = vs. ==. Fatto sta che la maggior parte se non tutti i compilatori moderni genera un warning quando questo avviene; "professionisti" dovrebbero sempre controllare i warning e viaggiare con -Wall attivo (o persino -Werror) ;).
Comunque si tratta di una scelta di leggibilità, che riguarda il modo in cui si usano in inglese i : per specificare cosa avviene dopo una frase.
Come dice uno dei commenti a quel post: allora bisognerebbe anche preservare il punto e virgola alla fine di ogni statement.
Purtroppo sei già stato contaminato. :(
Invece, provenendo da questo linguaggio, sono più resistente e adattabile a stranezze di nuovi linguaggi. :ugeek:
Purtroppo anche l'ASCII è stato modificato, a causa dei soliti noti: http://www.appuntidigitali.it/4581/lf-c ... -di-testo/ (http://www.appuntidigitali.it/4581/lf-cr-o-cr-lf-qual-e-lo-standard-per-i-file-di-testo/)
Solo l'interpretazione dei simboli è stata modificata nello standard; il significato sei singoli simboli non è cambiato (che è quello che conta di più ed è quello per cui si discuteva).
-
Un software deve essere espressivo e soprattutto "alla portata di tutti", anche al meno intelligente
Quindi scriverlo nella lingua nativa lo può rendere più accessibile.
Sì, ma ha senso farlo a scopo didattico. Ed è questo il motivo per cui a partire da Python 3 i sorgenti sono codificati in UTF-8 e il linguaggio permette di utilizzare simboli Unicode come identificatori.
Questo ha senso perché Python è nato come linguaggio didattico, e continua in questa sua strada.
Ma NESSUN PROFESSIONISTA scriverebbe mai commenti in una lingua diversa dall'inglese, o identificatori non ASCII.
Persino professionisti con anni di esperienza a volte sbagliano. Il che è tutto dire.
L'unico caso in cui l'equivalenza può portare a errore "grave" è quando si operano assegnazioni all'interno di una condizione, proprio = vs. ==. Fatto sta che la maggior parte se non tutti i compilatori moderni genera un warning quando questo avviene; "professionisti" dovrebbero sempre controllare i warning e viaggiare con -Wall attivo (o persino -Werror) ;).
Il linguaggio (mi riferisco al K&R e al draft ISO) NON specifica nulla del genere.
Questa è un'AGGIUNTA, NON standardizzata, a quello che è un evidentissimo difetto di progettazione del linguaggio. Esattamente come qualche anno dopo spuntò fuori lint per eseguire un controllo più rigoroso dei sorgenti scritti correttamente in C, ma che potevano avere problemi come quelli segnalati.
Comunque si tratta di una scelta di leggibilità, che riguarda il modo in cui si usano in inglese i : per specificare cosa avviene dopo una frase.
Come dice uno dei commenti a quel post: allora bisognerebbe anche preservare il punto e virgola alla fine di ogni statement.
Bisogna anche capirle le cose. Il : evidenzia una decisione presa dal programmatore. E' successo un evento che modifica il normale flusso del programma -> eseguo determinate, specifiche, azioni. Ecco perché lo ritrovi negli if, while, def, class, ecc.
Il ; si continua a usare pure in Python (sebbene NON sia preferito) per lo stesso motivo per cui in inglese (ma anche in italiano) vogliamo aggiungere qualcos'altro alla STESSA frase (nel caso di Python, frase = riga di codice).
Se si usa il whitespace al posto del . (perché avrebbe avuto senso il . e non il ; da usare per delimitare un'istruzione) è perché si ricalca l'uso dello pseudocodice. O, da essere umano, vedila come la lista della spesa / cose da fare, o una ricetta.
Purtroppo anche l'ASCII è stato modificato, a causa dei soliti noti: http://www.appuntidigitali.it/4581/lf-c ... -di-testo/ (http://www.appuntidigitali.it/4581/lf-cr-o-cr-lf-qual-e-lo-standard-per-i-file-di-testo/)
Solo l'interpretazione dei simboli è stata modificata nello standard; il significato sei singoli simboli non è cambiato (che è quello che conta di più ed è quello per cui si discuteva).
[/quote]
L'interpretazione attiene al significato, ed è stato cambiato. Perché un Carriage Return ha un bel preciso significato, e un Line Feed pure.
Non si può prendere un Line Feed e farlo diventare magicamente un New Line, che è una cosa completamente diversa.
Per il resto, continuo a concordare con dsar.
EDIT: rileggendo mi rendo conto di essere stato un po' duro. Non mi riferivo a te, ma quelli che hanno scritto quei commenti su : & co.
-
Però gli identificatori bisogna lo stesso scriverli in lettere, e torniamo al discorso di prima ;).
Se il linguaggio non ti aiuta, una buona scelta degli identifier non aiuta nella leggibilità del software. Vedi Haskell:
insertBy :: (a -> a -> Ordering) -> a -> [a] -> [a]
insertBy _ x [] = [x]
insertBy cmp x ys@(y:ys')
= case cmp x y of
GT -> y : insertBy cmp x ys'
_ -> x : ys
O ancora peggio:
trimLookupLo :: Ord k => k -> (k -> Ordering) -> Map k a -> (Maybe (k,a), Map k a)
trimLookupLo lo cmphi Tip = (Nothing,Tip)
trimLookupLo lo cmphi t@(Bin sx kx x l r)
= case compare lo kx of
LT -> case cmphi kx of
GT -> (lookupAssoc lo t, t)
le -> trimLookupLo lo cmphi l
GT -> trimLookupLo lo cmphi r
EQ -> (Just (kx,x),trim (compare lo) cmphi r)
E questi sono casi semplici di algoritmi semplici.
I linguaggi funzionali li capisco (anche se non sono abituato alla lettura), ma dopo un po' mi fanno venire il mal di testa.
L'unico caso in cui l'equivalenza può portare a errore "grave" è quando si operano assegnazioni all'interno di una condizione, proprio = vs. ==. Fatto sta che la maggior parte se non tutti i compilatori moderni genera un warning quando questo avviene; "professionisti" dovrebbero sempre controllare i warning e viaggiare con -Wall attivo (o persino -Werror) ;).
Lasciando perdere l'equivalenza.
Un linguaggio che permette (anzi, il K&R lo consiglia per gli esperti!) questo mix tra statement ed expression per copiare una stringa:
while ((s[i++] = t[j++]) != ' ');
non merita di essere chiamato linguaggio.
Quotoski!
l'Haskell non si può leggere, per cortesia X_x
Ho provato a studiare un po' lo Scheme, seguendo le videolezioni di Berkeley... potente come linguaggio, ma va bene (secondo me) solo per programmini da pippa mentale accademica che non superino le 100 righe di codice.
Per fare un software applicativo è inaccettabile.
PS: Ma lo schema di uno spreadsheet moderno, con formule condizionali e operazioni su array, può definirsi come una forma di programmazione funzionale?
-
Penso di sì. Alla fine tutto viene ricondotto a chiamata e/o composizione di funzioni (per valutare espressioni).
P.S. Nemmeno a me piacciono i linguaggi funzionali. Python mette a disposizione alcuni costrutti di questo tipo, ma fortunatamente rimane leggibile.
-
Un linguaggio che permette (anzi, il K&R lo consiglia per gli esperti!) questo mix tra statement ed expression per copiare una stringa:
while ((s[i++] = t[j++]) != ' ');
non merita di essere chiamato linguaggio.
Il C/C++ permette di scrivere ciò; non obbliga.
Ora non so perchè il K&R consigli quella scrittura; fatto sta che torniamo al discorso di prima: è colpa del linguaggio, o è colpa del programmatore?
Se un programmatore scrive quella cosa li, vabbè, verrà riconosciuto come un magari bravo analista ma come discreto programmatore.
Qualcosa forse impedisce di scrivere:
while (t[j] != ' ')
{
s[i] = t[j];
i++;
j++;
}? No, e questo secondo me è assolutamente lecito, perchè un linguaggio di programmazione, in quanto strumento utile all'uomo, deve lasciargli ampio raggio d'azione; se poi il programmatore non è capace, è colpa del programmatore. Per assurdo, sarebbe come dar la colpa al cemento o ai mattoni se il muratore fa il muro storto.
Come tutti gli strumenti, ci sono linguaggi più facili da usare, linguaggi adatti a esprimere calcoli matematici complessi, linguaggi per comandare un robot industriale... a ognuno il suo strumento.
Bisogna anche capirle le cose. Il : evidenzia una decisione presa dal programmatore. E' successo un evento che modifica il normale flusso del programma -> eseguo determinate, specifiche, azioni. Ecco perché lo ritrovi negli if, while, def, class, ecc.
Il ; si continua a usare pure in Python (sebbene NON sia preferito) per lo stesso motivo per cui in inglese (ma anche in italiano) vogliamo aggiungere qualcos'altro alla STESSA frase (nel caso di Python, frase = riga di codice).
Se si usa il whitespace al posto del . (perché avrebbe avuto senso il . e non il ; da usare per delimitare un'istruzione) è perché si ricalca l'uso dello pseudocodice. O, da essere umano, vedila come la lista della spesa / cose da fare, o una ricetta.
Provo a fare una piccola analisi partendo da queste definizioni di Wikipedia (prese da li per comodità):
- Due Punti (http://http://it.wikipedia.org/wiki/Due_punti)
- Punto e virgola (http://http://it.wikipedia.org/wiki/Punto_e_virgola)
Nella lingua italiana, la funzione fondamentale dei due punti è quella esplicativa: una frase introdotta da essi (come quella che si sta leggendo in questo momento) serve difatti a chiarire il significato della proposizione che la precede. Nonostante questo sia l'uso più affermato dei due punti, ne esistono anche di diversi:
+ i due punti, come si può notare in questo testo, possono precedere una lista numerata o dotata di punti elenco;
Il punto e virgola indica la fine del concetto espresso nella frase al cui termine si trova il segno di interpunzione in questione; tale concetto si ricollega alla più grande idea di cui tratta l'intero periodo. Il punto e virgola non indica perciò né la fine dell'idea generale (come farebbe il punto), né la continuazione del concetto minore (che costituisce il ruolo della virgola), ma qualcosa di intermedio tra queste due funzioni.
Se consideriamo il "periodo" come un blocco di codice, "concetto" come linea di codice (qualcosa che partecipa a definire l'intero pensiero espresso dal codice), allora è corretto usare i due punti all'inizio di un blocco (come se fosse un elenco puntato), il punto e virgola per separare le linee nel blocco, e il punto finale per chiudere un blocco. La virgola dividerebbe istruzioni all'interno di una singola riga; il C/C++ la ha (io veramente non la ho mai usata, la ho vista usare all'interno del terzo campo del for per incrementare più variabili insieme, che forse è l'unico utilizzo dove ha un significato appropriato. Python la usa già meglio per fare le assegnazioni tipo a,b,c = 1,2,3 che voi Pythoniani sapete come si chiamano :D).
Questo è come la penso io; sarà per questo che non vedo tutti questi problemi del C/C++. ;)
Ah, giusto per mettere le cose in chiaro, non voglio dire che i linguaggi che proponete voi non siano adatti o siano errati; il Python ad esempio (proprio uno a caso ;)) lo reputo un gran linguaggio; sto solo difendendo il C/C++ che da più parti è sempre maltrattato. :cry:
-
E lo è a buon ragione, perché il nocciolo della questione, come tra l'altro rimarcato dagli stessi creatori, è che il C è nato con uno scopo ben preciso: velocizzare le scrittura del codice.
Le scelte sintattiche riflettono questo concetto, come penso sarà chiaro a tutti. Inoltre per rendere più semplice e veloce (ancora una volta) la scrittura del relativo compilatore, il linguaggio nacque povero di costrutti sintattici tesi alla scrittura di codice meno suscettibile a commettere errori.
Lo si vede dalla clamorosa mancanza del passaggio dei parametri per riferimento, che costringe fin dal più semplice programma a far uso dei puntatori (vedi il solito esempio della scanf).
Lo si vede anche dall'uso del preprocessore persino nella definizione di costanti (prima non esisteva la keyword const!), per non parlare delle macro (e dei terribili effetti collaterali che possono provocare!). Roba da assemblatore, insomma.
Lo si vede anche nella facilità di passaggio da intero a puntatore e viceversa, che tanti danni ha fatto.
Ciò che tu ritieni un'espressione di libertà, in realtà è frutto della ricerca di velocità di scrittura del codice e del compilatore. Che tanti danni ha fatto, e continua a fare. E non è un caso che, come nell'esempio di cui sopra, per sopperire a queste mancanza si è provveduto nel tempo a utilizzare tool esterni come lint, oppure all'aggiunta di warning per segnalare del codice che FORSE è errato.
E' innegabile che dipende tutto da come lo usa il programmatore, ma è altrettanto innegabile che parliamo di un linguaggio che ti porta con molta più facilità a commettere errori rispetto ad altri linguaggi di programmazione.
Senza considerare, e chiudo, che in genere i linguaggi di programmazione hanno portato a una qualche novità nella letteratura informatica. Il C cos'ha portato? Perché nei primi anni veniva deriso come "Pascal mascherato"?
-
E' per questo che uso C++! :lol:
Cmq, io alla fine gli unici errori di sintassi che compio sono la mancanza di qualche punto e virgola (tipico), o una parentesi fuori posto ecc...
Non noto tutti questi problemi; si vede che sono un bambino speciale. :oops:
-
ma che incubo :-)
Io il C++ lo conosco molto bene quindi OVVIAMENTE so quanto sia cesso :D
Ho scritto centinaia di migliaia di righe di codice in C e C++, e tutto ciò solo perchè non c'era altra alternativa (e se dovessi ricominciare a scrivere videogiochi di alto livello dovrei ritornare a questi linguaggi, per forza di cose).
Per hobby invece ho studiato ed apprezzo tantissimo il Delphi, che è un linguaggio (si è anche il nome del linguaggio, da non confondersi con l'Objective-Pascal) meraviglioso :-)
Mi sono guadagnato il pane anche con PHP per un certo periodo di tempo e, ripensando al C ed al C++, ho capito che al peggio non c'è mai fine :lol: con il C++ piango con un occhio solo almeno :lol:
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. Ad esempio su Android odio quando una lista rallenta durante lo scrolling e, guardacaso, nella debug console spunta un messaggio del GC che ha liberato X byte su Y oggetti deallocati... devo decidere IO se e soprattutto "quando" puoi liberare la memoria, punto!
Poi ci sono altre caratteristiche del java che invece apprezzo, come il meccanismo delle interfacce che risolve in maniera pulita l'inferno dell'ereditarietà multipla del C++ (infatti in C++ usavo la convenzione Java, cioè una sola classe padre + N classi virtuali pure a mo' di interfacce).
Devo studiare meglio la reflection in Java, che è interessante anche se la ritengo una pratica di programmazione pericolosa al pari dei casting selvaggi.
-
ma che incubo :-)
Io il C++ lo conosco molto bene quindi OVVIAMENTE so quanto sia cesso :D
Sante parole. :clap:
Per hobby invece ho studiato ed apprezzo tantissimo il Delphi, che è un linguaggio (si è anche il nome del linguaggio, da non confondersi con l'Objective-Pascal) meraviglioso :-)
:shock: Da pascaliano di lunghissima data, ho lavorato per parecchi anni con Delphi, che ADORO.
Dopo Python è il mio linguaggio preferito. 8-)
Attualmente invece ho approfondito il Java, perchè sviluppo su Android, e devo dire che mi piace così e così...
Troppo verboso. Anche perché gli mancano tutta una serie di agevolazioni. Passando da C# 3 (con Windows Phone 7) a Java, per me è stato un trauma.
Avrei aggiunto alcune caratteristiche come gli iteratori stile C++ (quelli stile Java mi fanno pena al cubo),
Ovviamente preferisco quelli stile Python:
for Item in List:
print Itemma in mancanza meglio quelli di C#
foreach(var Item in List)
Console.WriteLine(Item);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. Ad esempio su Android odio quando una lista rallenta durante lo scrolling e, guardacaso, nella debug console spunta un messaggio del GC che ha liberato X byte su Y oggetti deallocati... devo decidere IO se e soprattutto "quando" puoi liberare la memoria, punto!
import gc
gc.disable()
# Do whatever you want
gc.collect()
# Do whatever you want
gc.enable()8-)
Poi ci sono altre caratteristiche del java che invece apprezzo, come il meccanismo delle interfacce che risolve in maniera pulita l'inferno dell'ereditarietà multipla del C++
Python usa questo (http://http://www.python.org/download/releases/2.3/mro/) per risolvere il problema dell'uso di membri usando l'ereditarietà multipla.
(infatti in C++ usavo la convenzione Java, cioè una sola classe padre + N classi virtuali pure a mo' di interfacce).
In genere è il mio modello preferito, anche se qualche volta ho usato l'ereditarierà multipla in Python (per classi molto semplici, e più che altro per emulare i mixin).
Devo studiare meglio la reflection in Java, che è interessante anche se la ritengo una pratica di programmazione pericolosa al pari dei casting selvaggi.
Provenendo da Python, la trovo molto incasinata e complicata da usare. Sono abituato troppo bene con Python. :D
-
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.
Qui non è colpa del GC :P mica può sapere se ti servono più oppure no.
Se non ci fosse il GC sarebbe pure peggio, perché deallocando la classe causi un numero tremendo di memory leak. In assenza bisogna crearsi procedure che traversano tutto l'algoritmo di dati per deallocare la memoria.
Io sono per l'accoppiata, in Ada e in alcune versioni di Oberon hai il GC e la possibilità di usare il delete/dispose per alleggerire il lavoro del GC. Anche se nei report ufficiali sconsigliano l'accoppiata, devo ancora investigare sui perché.
Ci sono delle tecniche, che conosco e ho implementato, per evitare tutti i memory leaks anche in C++.
Potrei usarle perfettamente anche in Java, se solo avessi il "delete".
In sostanza si elimina l'uso dei puntatori e si usano gli smart pointers, cioè puntatori con ref counting implementato in modo coerente tramite ridefinizione dei costruttori per copia e dell'operatore di assegnazione.
In Java (o perlomeno su Android, non so se sia Java standard) ci sono i SoftReference e i WeakReference che aiutano a spezzare i grafi di interdipendenza. In pratica il GC può decidere di cancellare un oggetto, se gli unici reference ad esso sono tutti di tipo Weak o Soft.
Il danno è che, comunque, non potendo decidere quando deallocare potrei trovarmi con softref che puntano al nulla e dovrei ricostruire tali oggetti, quindi posso farlo solo su oggetti "ricostruibili" (ad esempio per oggetti che incapsulano file XML, file immagini, ecc... cioè roba che posso ricostruire ricaricando e riparsando il relativo file).
@cdimauro:
In Android posso invocare manualmente il "collect" del GC, ma non posso disattivarlo (quindi comunque andrebbe a rompere le scatole nei posti meno opportuni).
Il foreach c'è anche in java
for(Tipo iteratore : insieme)
{
}
Però non è un iteratore vero, perchè va soltanto in avanti e non posso decidere, ad esempio, di usarlo come puntatore ad un elemento del set, ma soltanto per fare cicli semplici. Gli iteratori C++, quelli ad accesso random, invece mi permettono una maggiore comodità in alcune situazioni. Tuttavia, alla fine, stringo i denti e ne faccio a meno. Se non conoscessi il C++ probabilmente nemmeno ci avrei fatto caso.
-
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..
-
Sull'uso dell'indentazione e dei : nelle istruzioni è intervenuto Guido nel suo blog (http://http://python-history.blogspot.com/2011/07/karin-dewar-indentation-and-colon.html).
-
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 (http://http://it.wikipedia.org/wiki/Pascal_%28linguaggio%29) 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 (http://http://z80fan.altervista.org/blog/3/apple-rilascia-i-sorgenti-di-macpaint-a-computer-history-museum/) fosse scritto in tale linguaggio); perchè non si è continuato per quella strada? (E sistemi operativi in vari (http://http://wiki.osdev.org/Pascal) linguaggi (http://http://wiki.osdev.org/FreeBasic_Barebones) 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 (http://http://en.wikipedia.org/wiki/Videotape_format_war).
-
E dopo questo bel commento di dsar, direi che si può chiudere. :D
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:
(http://http://upload.wikimedia.org/wikipedia/commons/1/17/GObject_example.png)
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:
-
Per TheKaneB:
http://brinch-hansen.net/memoirs/photos ... c4000.html (http://brinch-hansen.net/memoirs/photos-html/rc4000.html)
Lui impiegò quasi due anni per assemblarselo, pensi di competere con un nerd del genere?
sono depresso... :roll: :|
-
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:
-
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 (http://http://www.google.it/search?client=opera&rls=it&q=site:hwupgrade.it+cdimauro+GObject&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest). In particolare nel secondo risultato ("Torvalds e C++ [Archivio] ") trovi già qualche citazione in merito (in mezzo a parecchia altra roba :mrgreen: ).
-
@dsar: una domanda. Con Ada, Modula-2 & 3 hai la possibilità di referenziare precise locazioni di memoria?
-
Sì, e da quando il C è un linguaggio sicuro? Segmentation fault rulez. :D
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. ;)
-
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:
-
Allora non vedo alcun vantaggio a usare il C, se non per la sintassi concisa (ma ben poco leggibile). ;)
-
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...
-
- 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!??!?!?!??!?!?!??!?!?!?!?!?
-
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:
-
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... :D
-
Molti sono ossessionati dal performance a tutti i costi, di conseguenza programmano con lo stesso linguaggio del sistema operativo.
In un sistema operativo se non vuoi overhead nelle chiamate di sistema devi scrivere le applicazioni nello stesso linguaggio.
Non si può creare un compilatore (linker) Pascal che genera il codice con la calling convention e i formati del C?
Perchè dici che l'integer del Pascal è diverso dall'int del C? Per via delle diverse lunghezze del campo? Perchè in C un intero potrebbe contenere un puntatore?
Perchè mettere i parametri da destra a sinistra è più lento che metterli da sinistra a destra?
Per TheKaneB:
http://brinch-hansen.net/memoirs/photos ... c4000.html (http://brinch-hansen.net/memoirs/photos-html/rc4000.html)
Lui impiegò quasi due anni per assemblarselo, pensi di competere con un nerd del genere?
Ci posso provare io; avendo tutti i pezzi posso fare anche in meno tempo. :ugeek:
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:
Ovviamente colui che ha deciso di usare un linguaggio non ad oggetti per creare interfacce grafiche è un demente che dovrebbe essere rinchiuso a vita.
Onestamente l'ho detto giusto per dare una motivazione a Z80Fan e non sembrare il solito estremista, diciamo che è un luogo comune che il C vada bene per i sistemi operativi e per il low-level, distruggere i luoghi comuni è difficile, per questo motivo l'ho detto.
Invece voglio proprio che tu li distrugga, ti chiedo di spiegarmi come stanno le cose, non farmi contento perchè sennò mi metto a piangere! :D
Non ho da commentare gli altri post.
Allora non vedo alcun vantaggio a usare il C, se non per la sintassi concisa (ma ben poco leggibile). ;)
Infatti è proprio quello che mi son messo a indagare. :think:
-
Usare gli interi come stringa, una figata eh?
Uhm, no, è una cosa stupida perchè non guadagni nulla in spazio e complichi il codice. Mi dispiace. ;)
La vera differenza tra strong e weak typing è questa. Di conseguenza in Pascal un intero ha un significato nettamente diverso dal C. Magari con una funzione che ritorna un intero io in realtà sto ritornando una stringa, un carattere o qualsiasi altra cosa sia e in Pascal non ho alcun modo per leggerla.
Ma se so che il ritorno è un intero (metti che c'è una stupida funzione che fa una somma), non posso usarlo in Pascal?
Per esempio getchar() torna un intero per carattere perché in C (vedi che furbi) usano il valore di ritorno anche per la gestione degli errori, non hai alcun modo di utilizzarlo in Pascal come carattere. Potresti forzare l'importazione cambiando il valore di ritorno con il char del Pascal, ma quando getchar() ti ritorna -1 perché l'EOF è stato raggiungo, il programma ti va in runtime error.
Non si può fare qualcosa del genere:
var = getcharC();
if var = -1 then
gestisciGliErroriComeSiFaInPascal();
else
return convertiInCarattere(var);
C'è questo piccolo codice da aggiungere ad una eventuale getchar() del Pascal, ma è lo stesso codice che si dovrebbe implementare in C (vedi che furbi! :P).
Poi si parlava dell'usare un altro linguaggio in UNIX, le sue syscall trattano principalmente con numeri interi (che sia un id di un oggetto, una dimensione o un offset).
Diciamo che quello descritto sopra era il calling convention di default prima che il C fosse così diffuso.
Quindi non è più così? Infatti mi sembrava strano, perchè mi permette di ritornare strutture. :think:
i puntatori non sono il massimo dell'efficienza
Questa non la ho proprio capita: alla fine, linguaggio di alto livello o non, a tutto si accede attraverso puntatori; dove sarebbe la penalizzazione nell'usarli? :think:
Come mai a te piace il C/C++?
Io ho scelto il C per programmare il mio OS perchè è semplice, non ha bisogno di una VM o di runtime support, e mi permette di gestire la memoria come voglio io (cosa importante, visto che se programmi un kernel la memoria devi gestirla a mano, byte per byte :P). Non ho scelto il C++ perchè quest'ultimo ha bisogno di un leggero strato di runtime support, ma vedendo i vantaggi rispetto al C (ad esempio, i template), penso che lo riscriverò in questo linguaggio (non che sia un gran lavoro).
Per un gioco che sto sviluppando (un clone potenziato di Minecraft), invece, ho scelto di usare il C++, perchè mi permetteva di ottenere buone prestazioni (Java, con cui è scritto attualmente Minecraft, si può dire quel che si vuole, ma è un mattone anche sul mio PC che non è proprio un bidone; immagina sul mio netbook). Gestire la memoria a mano non mi preoccupa minimamente, perchè gestendo tutto con opportune classi, creo la memoria nel costruttore e la distruggo nel distruttore; non ho bisogno di portarmi puntatori in giro per il programma e dimenticare di eliminarli.
La sintassi di entrambi i programmi non la trovo un problema, non è un problema per me se devo scrivere == e non =, e la capisco meglio di tanti altri linguaggi (sarà perchè lo conosco molto bene, ma lo trovo talvolta più semplice di molti altri linguaggi).
-
Un paio di note.
@Z80Fan: proprio per il fatto che il C può usare gli interi come gli pare, esporre un'interfaccia per altri linguaggi è molto problematico, come ha spiegato correttamente dsar.
Immagina il lavoro che deve fare il generatore di uno stub / interface per un determinato linguaggio, partendo dall'header scritto in C: non sapendo quale tipo utilizzare effettivamente per quel linguaggio, dovrà optare per qualcosa di simile all'int, lasciando poi al programmatore a sbrogliare la matassa.
@dsar: i confronti (load / store in generale) fatti "per word" non necessariamente producono segfault se i dati non sono allineati alla word. Dipende tutto dall'architettura.
-
ci sono alcune architetture (tipo ARM fino alla revisione v5) dove proprio fisicamente non puoi nemmeno specificarlo un indirizzo che non sia word-aligned (2 o 4 byte, in base all'ISA utilizzata, cioè Thumb o ARM). Fisicamente le linee di indirizzi sono 31, e la trentaduesima è hardwired a 0. :shifty:
Il bit meno significativo del Program Counter viene infatti usato per stabilire se la prossima istruzione è in modalità Thumb oppure ARM.
Quindi un branch all'indirizzo 0x400 mette la cpu in modo ARM, mentre se faccio branch a 0x401 comunque eseguirà l'istruzione alla locazione 0x400 ma interpretandola con l'ISA Thumb. Il cambio di ISA si può fare, potenzialmente, ad ogni branch. Questo consente di generare codice misto che può privilegiare lo spazio occupato o le prestazioni (a discrezione del compilatore).
Tuttavia questo vale solo per le istruzioni, perchè i dati saranno sempre allineati alla word (specialmente l'accesso allo stack), con i due bit meno significativi dell'address bus hardwired a 0.
Da ARMv6 in poi le cose sono diventate più flessibili, ed è possibile accedere a dati non allineati. Tuttavia il memory controller dovrà fare due fetch distinti e riproporre il dato allineato alla CPU. Questo comporta penalità nelle prestazioni ma previene errori di programmazioni che possono causare letture / scritture erratiche.
-
Quando lavoravo su PS3 (IBM Cell, una specie di PowerPC), capitava spessissimo un errore che il compilatore avrebbe potuto evitare in automatico, mentre toccava a noi programmatori aggiustare manualmente.
L'OS integrato nella PS3 gestisce thread e sincronizzazione, esponendo le apposite primitive nell'SDK.
Dal momento che quella CPU integra delle operazioni di test-and-set atomiche, queste vengono usate dall'SDK per implementare i semafori in modo "safe" (diciamo). Il problema è che se includi un semaforo dentro una classe, questo semaforo subisce l'allineamento della classe e non sempre era word-aligned (perchè!?) quindi dovevamo specificare a mano l'attributo __attribute__(aligned((128)) su ogni classe e struttura che contenesse un semaforo, altrimenti il lock non avveniva correttamente, senza tuttavia causare errori in runtime. Ovviamente il problema sorgeva solo in caso di race condition, e soltanto compilando in release!
-
...chiaro che fosse un problema di GCC, infatti su XBox360 (sempre IBM PowerPC), con compilatore microsoft, non vi era alcun problema di allineamento. Usando il compilatore SNC (una roba di Sony) il problema non sussisteva, probabilmente perchè allineava in automatico in modo intelligente (il codice era anche mediamente più prestante e compilava 4 volte più velocemente).
-
Fare la comparazione di una stringa byte per byte è più lento di farlo word per word. Word per word ne compari 4 al volo in una piattaforma 32 bit. Ovviamente non sempre si può fare e qui il compilatore può venirti in aiuto. Se la stringa è di 7 byte non puoi fare la comparazione word per word, se lo lasci fare al compilatore lui in realtà alloca 8 byte (lo filla di byte dummy) e poi fa la comparazione word per word. Non ricordo come si chiama, per-word allocation boundary o aligned word allocation.
Si può anche comparare a word la parte iniziale della stringa, e completare a byte. Ho fatto una cosa simile per una memcpy per l'OS, visto che devo gestire le bitmap sullo schermo via cpu, ho fatto in modo di usare la più grande word che la cpu può caricare per la parte centrale del blocco, e poi copiare singoli byte per allineare all'inizio e completare alla fine (la cosa ideale sarebbe usare dell'assembly e caricare i dati con le istruzioni vettoriali da 128 bit).
In assembly x86 se il compilatore ti aiuta può usare rep cmpsw (compsw = comparison word).
Queste vecchie istruzioni sono emulate attraverso microcodice, non so se gli ultimi modelli la possono eseguire direttamente in hardware.
Diciamo di sì, ma questo devi considerarlo un caso semplice e soprattutto c'è il fatto che nessuno andrebbe a cambiare la funzione getchar() del C, ma tu non puoi affidarti alla buona fede dei programmatori.
Prendiamo altri casi molto realistici, in cui un software viene esteso sempre. Il fatto che un intero venga usato per la gestione degli errori, tu domani non sai se ci sarà da gestire anche un -2 e il tuo programma andrà in runtime error perché chr() si ritrova a converire il valore -2 che è fuori range [0 .. 255].
Dovresti fare un design migliore e wrappare la funzione in modo più sicuro (e che in futuro tu possa estendere), immagina un modulo separato che riceve caratteri dal getchar, tipo così:
type GetResult = (char, eof, unexpected);
[...]
intres : integer; (* getchar's integer result value *)
realch : char; (* pascal character *)
mean : GetResult; (* result's meaning *)
intres := getcharC();
if intres = -1 then
[...]
mean := GetResult.eof
elsif intres in [0 .. 255] then (* oppure ch >= 0 and ch <= 255, ma usare l'in è più veloce in Pascal *)
realch := chr(intres);
mean := GetResult.char
else
mean := GetResult.unexpected;
[...]
furthercondition(intres)
end
Ecco, proprio così. Aggiunge così tanto overhead e complessità che uno fa prima ad usare il C piuttosto che convertire Pascal?
Infatti Modula-3 (che è molto UNIX-centric, cioè è stato sviluppato per essere programmato su questa piattaforma) usa un layer di interfaccia per le chiamate.
Ed è molto pesante?
Comunque ricordavo male, il C può tornare valori strutturati per le strutture ma non per gli array (che concettualmente è anche structured).
Si perchè gli array sono semplicemente puntatori al primo elemento. Per poter tornare un "vero" array per valore, bisogna creare una struttura al cui interno c'è il vettore. Ovviamente, se il vettore è un po' più lungo di qualche decina di byte, questa soluzione è assolutamente lenta per via della copia dei dati al ritorno della funzione.
Infatti l'ottimizzazione consiste nell'evitare di deferenziare continuamente la memoria quando leggi o scrivi molto in una struttura dati.
Però, fai conto, se ho un algoritmo che lavora su un vettore, e ha bisogno della cella corrente, e della successiva, e fa diversi calcoli su questi due dati. Anche se scrivo a e a[i+1] ovunque, il compilatore cmq riconosce che "i" non cambia e salva i dati nei registri, senza troppo bisogno di specificarlo. Poi ovvio, se uno usa il compilatore degli anni '60, è inutile anche parlare.:)
Dovrebbe invece. I memory leak avvengono sempre, basta guardare il changelog di qualsiasi progetto opensource, i distruttori vanno bene per robette semplici e risorse limitate. In strutture (o classi) davvero complesse i casini si combinano ugualmente. Se fosse tutto così semplice, non esisterebbero i GC ;-)
Il GC non è il male, soprattutto quando i vantaggi superano i suoi svantaggi. (Uno di questi è la deframmentazione con il copying collector)
Io non ho detto che il GC è brutto e cattivo; io ho detto che non ho problemi a gestire la memoria manualmente, e mi dispiace per quei programmatori opensource. :)
Io so che, nella mia esperienza, se ogni classe si gestisce la sua memoria, non c'è nessun problema; ad esempio, in una lista di nodi, se ogni nodo è una classe, e ogni nodo ha un puntatore al suo successivo, il distruttore si riduce a un "delete successivo" e, automaticamente e ricorsivamente, tutta la lista viene eliminata e la memoria liberata. I problemi vengono quando si vuole avere una classe principale che fa da lista e tante altre classi secondarie che fanno da nodo, e alla classe principale si da il compito di gestire la memoria delle classi nodo, che diventano praticamente delle semplici strutture. Se proprio di vuole andare sicuri, si crea una stupida classe "safe pointer" che si preoccupa di eliminare l'elemento a cui punta quando viene distrutta, ma, ripeto, IO non ne ho mai avuto bisogno. :)
Tempo fa quando i developer di FreeBSD decisero di adottare lo static analyzer di Coverity, scoprirono circa un centinaio di bug nelle expression dovuti a mistyping di == con = nelle expression, e stiamo parlando di developer con anni di coding alle spalle. Inoltre il codice viene sempre revisionato da una o più persone e sono sfuggiti ai loro occhi. Magicamente sparirono bug che da anni si presentavano raramente.
I bug trovati da Coverity erano bug del tutto leciti nel C code, se non ricordo male i bug fixati furono sul migliaio in totale.
Non ho negato che può essere un problema, tu mi hai chiesto perchè usassi il C/C++ e ti ho dato delle motivazioni, che sono assolutamente dal MIO punto di vista. Non sto dicendo che i programmatori FreeBSD sono delle pippe o che è impossibile scambiare == con =; solo che a me non ha mai causato problemi.
Brainfuck (esiste davvero)
Si, lo conosco; quello lo uso per il software applicativo. :P
gli OS sono tutti in C :-) dal mio punto di vista perdono di tantissimo l'interesse da parte di curiosi.
Secondo me un OS "interessante" lo è se implementa qualche algoritmo o qualche soluzione interessante; neanche Modula-3 può rendere interessante un comune kernel monolitico. :)
Perché non provi Go? Scopiazzato interamente da Oberon-2, però ha la sintassi del C (se adotti una sintassi diversa, non ha diffusione).
Ha tutto ciò che serve per il system programming.
Perchè lo hai detto tu stesso, è uno scopiazzo! :D
Abbiamo già millemila linguaggi, preferisco molto più impararmi Oberon-2 piuttosto che un linguaggio che è la solita minestra riscaldata, e che magari sparirà con l'arrivo della nuova moda.
Immagina il lavoro che deve fare il generatore di uno stub / interface per un determinato linguaggio, partendo dall'header scritto in C: non sapendo quale tipo utilizzare effettivamente per quel linguaggio, dovrà optare per qualcosa di simile all'int, lasciando poi al programmatore a sbrogliare la matassa.
Ovviamente se lo fai fare a un sistema automatico, non puoi aspettarti del buon codice; un'interfaccia tra i due linguaggi va fatta da un programmatore umano che conosce i due linguaggi e sa, oltre al tipo di dati richiesti, il contenuto di quei dati. Solo in questo modo puoi sperare di avere un'interfaccia corretta.
Usando il compilatore SNC (una roba di Sony) il problema non sussisteva, probabilmente perchè allineava in automatico in modo intelligente (il codice era anche mediamente più prestante e compilava 4 volte più velocemente).
Perchè usevate GCC allora?
-
Non serve un programmatore per fare la conversione. Serve un linguaggio dichiarativo che permetta di stabilire in maniera precisa la natura di ogni dato (e il modo in cui dev'essere passato).
Riguardo al GCC e i problemi di allineamento, è un problema ricorrente di cui ho parlato anche nell'articolo che ho scritto sul GCC (http://http://www.appuntidigitali.it/10525/gcc-il-miglior-compilatore-al-mondo/) (verso la fine).
-
E' veramente affascinante leggere tutto ciò :)
Continuate pure, io vi ascolto (=leggo) in silenzio religioso
-
E' veramente affascinante leggere tutto ciò :)
Continuate pure, io vi ascolto (=leggo) in silenzio religioso
Affascinante, ecco il concetto che ho provato nel leggere tutto ciò, mi metto anche io in mistico silenzio.
Ciao,
ncc-1700
-
Non capisco anche io perche' hanno usato il GCC (non e' in tono provocatorio :) ), credevo che fosse usato perche' copre molte architetture e quindi venisse usato per un fattore di comodita', pero' dai casi sopra ho letto di Xbox, PS3, quindi architetture specifiche con i compilatori della "casa" quindi mi chiedevo il motivo per cui avessero usato il GCC :P
-
SN Systems sforna compilatori per Sony già dagli inizi della PS2.
Il motivo è molto più prosaico... il kit incluso nel prezzo è basato su GCC e pensavano fosse sufficiente, poi gli ingegneri dell'engine si sono rotti il .... e hanno alzato la voce "compratelo sto ..... di SNC". E così fu luce, e vidi che ciò era buono.
-
SN Systems sforna compilatori per Sony già dagli inizi della PS2.
Il motivo è molto più prosaico... il kit incluso nel prezzo è basato su GCC e pensavano fosse sufficiente, poi gli ingegneri dell'engine si sono :obscene-birdiered: .... e hanno :angry-screaming: "compratelo sto :music-tool: di SNC". E così fu luce, e vidi che ciò era :obscene-sexualdoggy: .
:mrgreen: