[C] Futuro del linguaggio [Archivio] - Hardware Upgrade Forum

cdimauro

17-07-2008, 21:25

Meno male... ;)

Se escludiamo contesti molto particolari (es. sistemi embedded, codice legacy, programmazione di device drivers, ...) nel 2008, ma in realtà già da un ventina di anni, non ha alcun senso (se non quello di fare e di farsi del male) usare un linguaggio low-level ed error-prone come il C per lo sviluppo di applicativi quando ci sono validissime alternative.

Ovviamente (e purtroppo, aggiungo io) il C non morirà domani né entro una decina di anni.
*
Linguaggi ad oggetti, strumenti RAD, framework, toolkit per GUI con un livello decente di astrazione, etc, etc, etc. Insomma, TUTTO tranne un linguaggio low-level progettato 36 anni fa (!!!) come un "Assembly ad alto livello". Usarlo per sviluppare applicazioni non di sistema (vedi il messaggio precedente) è come impiegare una forchetta per piantare un chiodo, se non ci si fa male ci si rimette in tempo e salute. Esistono strumenti molto più adatti del C per la programmazione di applicazioni pensate per l'utente finale... Da almeno una ventina di anni. :)
* A parte, però, che linguaggi anche più vecchi, come il Pascal, permettevano di programmare in maniera molto meno prona a commettere errori.
questo è quello che credono loro; in realtà il motivo è pura e semplice ignoranza, inerzia tecnologica, pezze ar culo. ci sono molti modi di chiamarla :asd: :D
*
Le scuole insegnano il C perché comunque un programmatore non può prescindere dalla conoscenza di un linguaggio di basso livello. E' chiaro che oramai è quasi sempre meglio utilizzare le alternative, ma per saper programmare in qualsiasi contesto è necessario saperlo fare sporcandosi le mani con la gestione della memoria, i puntatori, la gestione dello stack algol-like eccetera.
Sono in totale disaccordo. Non è assolutamente necessario sporcarsi le mani così per quello che è lo scopo primario e fondamentale di un programmatore: risolvere problemi.
il modo per evolversi è quello di investire in tempo, un sacco di tempo: tempo per studiare, tempo per scaricare/installare/configurare prodotti software, tempo di farli andare d'accordo col software che avevamo già, tempo di trovare una soluzione/alternativa per il software vecchio che proprio non vuole andare d'accordo, tempo di riorganizzare i corsi, tempo di preparare nuove prove d'esame. l'informatica è una questione di tempo, con esso puoi fare tutto: il vero nerd non ha una vita perché non ne ha tempo, e i professori universitari spesso non sono affatto dei veri nerd; di conseguenza la qualità tecnica dei nostri corsi accademici è scadente - per avere quel dannato "pezzo di carta" (la laurea) siamo costretti ad imparare roba di decenni fa che nel mondo del lavoro potrebbe non servirci per nulla.
*

peppepz

17-07-2008, 21:49

Perché è il tipo più generico di programmazione. In un linguaggio di basso livello puoi scrivere un'interfaccia utente, il firmware di un router, un sintetizzatore vocale, un handler di interrupt. Se impari solamente linguaggi di alto livello, ci saranno situazioni, quelle lontane dal "target" del linguaggio che stai utilizzando,in cui avrai difficoltà a procedere o non potrai procedere affatto. Per non parlare del fatto che potresti perfino non sapere come funziona la macchina che esegue il codice che scrivi; e quindi perché essa esegue meglio un certo tipo di programma anziché un altro, o che cosa ti puoi aspettare quando esegui determinate operazioni, o quali sono i problemi da affrontare quando se ne fanno altre ancora.

cdimauro

17-07-2008, 22:18

Perché è il tipo più generico di programmazione.
Ti sbagli: è il linguaggio macchina che te lo offre.
In un linguaggio di basso livello puoi scrivere un'interfaccia utente, il firmware di un router, un sintetizzatore vocale, un handler di interrupt.
Col linguaggio macchina puoi scrivere interi s.o. senza mai dover ricorrere a nessun altro linguaggio.

Non si può dire lo stesso di altri linguaggi (a parte l'assembly), C incluso.
Se impari solamente linguaggi di alto livello, ci saranno situazioni, quelle lontane dal "target" del linguaggio che stai utilizzando,in cui avrai difficoltà a procedere o non potrai procedere affatto.
In tal caso è possibile scendere di livello utilizzando altri linguaggi.

Ma sono casi rari, che si prenderanno in considerazione quando capiterà realmente un'occasione.
Per non parlare del fatto che potresti perfino non sapere come funziona la macchina che esegue il codice che scrivi;
Che non è assolutamente necessario conoscere.
e quindi perché essa esegue meglio un certo tipo di programma anziché un altro,
Per questo serve il profiler. Poi si decide se riscrivere l'algoritmo cercando uno più efficiente, oppure scendere di livello.
o che cosa ti puoi aspettare quando esegui determinate operazioni,
Se il linguaggio è ben definito, cosa succede è ben determinato.
o quali sono i problemi da affrontare quando se ne fanno altre ancora.
Si valuteranno altre soluzioni.

||ElChE||88

17-07-2008, 22:23

L'unico futuro che auguro al C è:

http://img28.picoodle.com/img/img28/4/7/17/f_gravestonecm_a159b04.jpg

grigor91

17-07-2008, 22:34

L'unico futuro che auguro al C è:

http://img28.picoodle.com/img/img28/4/7/17/f_gravestonecm_a159b04.jpg

Se speriamo che faccia quella fine da solo stiamo freschi. Ci vuole un linguaggio che abbia le stesse prestazioni nei settori di nicchia in cui è rimasto ancorato. Se si sviluppano dei linguaggi che sono n-miliardi di volte migliori nel 90% del mercato, ma in quel 10% il C rimane l'unica scelta conveniente possiamo lamentarci all'infinito.

morskott

17-07-2008, 23:00

quoto totalmente cdimauro, un linguaggio per essere buono deve essere capace di risolvere problemi in modo efficiente (per chi scrive il programma, non necessariamente per l'elaboratore) e quanto meno error-prone possibile, non ci si puo mettere troppo tempo per (non è efficiente fare) un debug legato a errori del linguaggio e non di algoritmo!!!

Personalmente il C non lo sopporto, forse un po troppo immeritatamente e per l'"approccio" che ci è stato fatto (all'uni abbiamo visto/fatto corsi/tesine essenzialmente in Java e i 3 corsi che presupponevano tesine in C ci hanno detto "imparatevelo da soli"), preferisco molto di piu suo evoluzioni tipo C# o derivazioni tipo Java (e mo sto vedendo pure un po di python, ma molto all'acqua di rose)

cdimauro

18-07-2008, 08:11

Se speriamo che faccia quella fine da solo stiamo freschi. Ci vuole un linguaggio che abbia le stesse prestazioni nei settori di nicchia in cui è rimasto ancorato. Se si sviluppano dei linguaggi che sono n-miliardi di volte migliori nel 90% del mercato, ma in quel 10% il C rimane l'unica scelta conveniente possiamo lamentarci all'infinito.
Il C++ è un SUPERSET del C, quindi può fare esattamente le stesse cose (e molto di più ovviamente).

Similmente al C++, c'è anche il D che può essere usato come linguaggio "di sistema", pur presentando dei costrutti semantici interessanti.

Come vedi di alternative al C ce ne sono: basta sfruttarle. :O

tomminno

18-07-2008, 08:33

per avere quel dannato "pezzo di carta" (la laurea) siamo costretti ad imparare roba di decenni fa che nel mondo del lavoro potrebbe non servirci per nulla.

Guarda che poi nel mondo del lavoro verrai quasi sicuramente impiegato come programmatore alla stregua dei ragazzini che escono dalle superiori e non sanno una cippa di niente.
In Italia informatica significa solo programmatori.

Ah dimenticavo VB6 va ancora alla grande

peppepz

18-07-2008, 09:06

Ti sbagli: è il linguaggio macchina che te lo offre.

Col linguaggio macchina puoi scrivere interi s.o. senza mai dover ricorrere a nessun altro linguaggio.

Non si può dire lo stesso di altri linguaggi (a parte l'assembly), C incluso.

Non mi sembra che sei razionale affermando cose del genere. Consiglieresti a qualcuno di scrivere un intero sistema operativo in linguaggio macchina? Consiglieresti a qualcuno di scrivere una qualsiasi cosa in linguaggio macchina se non fosse strettamente necessario?

[i linguaggi di alto livello hanno un target più ristretto]

In tal caso è possibile scendere di livello utilizzando altri linguaggi.

Ma sono casi rari, che si prenderanno in considerazione quando capiterà realmente un'occasione.

Ecco perché bisogna scegliere un compromesso fra l'assembly e il visual basic. E la gente usa il c++ perché a torto o a ragione è il miglior compromesso per ora. Ed è per questo che lo insegnano a scuola. Poi è chiaro che se lavori per un'azienda di software da impresa raramente ti capiterà di toccare qualcosa di più basso livello del Python. Ma non è prerogativa delle istituzioni scolastiche decidere quale sarà l'ambito finale del programmatore, ed ecco che di nuovo il c++ è la soluzione a più ampio raggio.

[la conoscenza della macchina]

Che non è assolutamente necessario conoscere.

Certo che non è /strettamente necessario/, ma non è /opportuno/?
Non è opportuno sapere che una soluzione recursiva è peggiore di una soluzione lineare? Eppure sono entrambe soluzioni valide e ben definite. Non è opportuno sapere che è più veloce trasferire riferimenti anziché spostare dati in memoria? Eppure sono entrambe soluzioni valide e ben definite.

[conoscere la macchina per scrivere codice più efficiente]

Per questo serve il profiler. Poi si decide se riscrivere l'algoritmo cercando uno più efficiente, oppure scendere di livello.

Quindi ancora una volta tu pensi che un programmatore sia ben formato se ha bisogno di affidarsi a strumenti scritti da terze parti per scrivere buon codice? E se nel caso di una malaugurata "discesa di livello" non sa dove mettere mano?

Se il linguaggio è ben definito, cosa succede è ben determinato.

Guarda, probabilmente io detesto il C di più di te. Ho iniziato a programmare in C urlando e scalcitrando. E tutt'ora lo utilizzo solo quando sono costretto. Però né io né tu possiamo fingere di ignorare che il C++ è attualmente usato dalla maggior parte del mondo conosciuto, quando si tratta di scrivere codice nativo. Quindi bisogna conoscerlo per forza di cose, se non altro per non trovarsi nella situazione di non saper interpretare il codice scritto da altri. Se ti portano del codice C che utilizza una gets() su un buffer nello stack, devi sapere che è del codice scorretto che probabilmente consentirà ad un malintenzionato di eseguire codice arbitrario. Ora, poiché tu stesso hai ammesso che un linguaggio di livello più basso è necessario per determinate situazioni, e poiché tali situazioni non andranno prevedibilmente via in un futuro prossimo, ne consegue che deve fare parte della conoscenza di un buon programmatore come farne fronte.

Si valuteranno altre soluzioni.

In che linguaggio è scritto l'interprete ufficiale di Python? In che linguaggio è scritta la versione nativa di Ruby? In che linguaggio sono scritti Perl e gran parte dei suoi moduli? In che linguaggio è scritta la JVM? Non credo che tutti quelli che hanno scritto questi linguaggi sono degli sconsiderati ignoranti "con le pezze al culo" come ho sentito dire in questo thread. Non sarà che attualmente gli ambienti di sviluppo basati su C/C++ sono un buon compromesso per quanto riguarda la scrittura di codice nativo?

shinya

18-07-2008, 09:13

Speriamo che questo thread diventi un "C vs Java vs Python"... non ne posso più fare a meno ormai.

peppepz

18-07-2008, 09:25

Speriamo che questo thread diventi un "C vs Java vs Python"... non ne posso più fare a meno ormai.

Era diventato semplicemente un thread "abbasso il C e basta" e ho pensato di postare un articolo in direzione opposta per farlo diventare "abbasso il C ma con criterio", affinché qualcuno leggendolo non si facesse un'idea del C che io reputo sbagliata. Se pensate che sono stato inopportuno scusate, ma mi sembra di aver postato con moderazione e senza preconcetti di sorta.

cdimauro

18-07-2008, 09:48

Non mi sembra che sei razionale affermando cose del genere. Consiglieresti a qualcuno di scrivere un intero sistema operativo in linguaggio macchina? Consiglieresti a qualcuno di scrivere una qualsiasi cosa in linguaggio macchina se non fosse strettamente necessario?
Proprio perché sono razionale ho fatto quell'esempio: per dimostrare la non razionalità della tua precedente affermazione, dove hai imposto una soluzione al modello prospettato. Io ti ho semplicemente mostrato LA soluzione (perché è unica) che ti permette di realizzare qualunque cosa non dipendendo da nessun'altra.

Per il restono, no, non lo consiglierei al mio peggior nemico di sviluppare in linguaggio macchina. E altrettanto faccio per linguaggi come C et similia (ma su questo mi sono già espresso e non voglio riaprire una diatriba, come qualcuno ha già anticipato).
Ecco perché bisogna scegliere un compromesso fra l'assembly e il visual basic. E la gente usa il c++ perché a torto o a ragione è il miglior compromesso per ora. Ed è per questo che lo insegnano a scuola. Poi è chiaro che se lavori per un'azienda di software da impresa raramente ti capiterà di toccare qualcosa di più basso livello del Python. Ma non è prerogativa delle istituzioni scolastiche decidere quale sarà l'ambito finale del programmatore, ed ecco che di nuovo il c++ è la soluzione a più ampio raggio.
E allora la scuola dovrebbe insegnare anche l'assembly perché ci si potrebbe ritrovare a sviluppare il bootloader, lo scheduler o il gestore di interrupt di un s.o..
Il linguaggio macchina per sviluppare compilatori, emulatori, virtual machine, ecc.
Dovrebbe insegnare un linguaggio funzionale (LISP o Haskell) perché ci si dovrebbe ritrovare a sviluppare software caro ai matematici.
Insegnare Prolog perché potresti lavorare a sistemi di intelligenza artificiale.
Il Fortran perché ancora oggi è usatissimo in sistemi di (massiccio) calcolo numerico.
SQL perché capiterà di utilizzare basi di dati.
E così via.

Esistono tanti di quegli ambiti in cui col solo C++ non si va da nessuna parte, che in teoria non dovresti più uscire da scuola perché dovrebbe prepararti ad affrontarli degnamente.

Io preferisco che la scuola ti fornisca le basi della programmazione, e queste... non coincidono né col C né col C++ né con la programmazione strutturata.
Certo che non è /strettamente necessario/, ma non è /opportuno/?
Non è opportuno sapere che una soluzione recursiva è peggiore di una soluzione lineare? Eppure sono entrambe soluzioni valide e ben definite. Non è opportuno sapere che è più veloce trasferire riferimenti anziché spostare dati in memoria? Eppure sono entrambe soluzioni valide e ben definite.
E per far questo NON ti serve conoscere i dettagli di basso livello della macchina.
Quindi ancora una volta tu pensi che un programmatore sia ben formato se ha bisogno di affidarsi a strumenti scritti da terze parti per scrivere buon codice? E se nel caso di una malaugurata "discesa di livello" non sa dove mettere mano?
Si documenterà. Come sempre. E risolverà il problema.

Quanto a questi strumenti, non sempre sono scritti da terze parti. Esistono linguaggi (di cui non faccio il nome :D) che hanno già librerie built-in allo scopo.

Faccio presente, tra l'altro, che generalmente è sufficiente reimplementare la parte di codice critica utilizzando un algoritmo più efficiente.
Guarda, probabilmente io detesto il C di più di te. Ho iniziato a programmare in C urlando e scalcitrando. E tutt'ora lo utilizzo solo quando sono costretto. Però né io né tu possiamo fingere di ignorare che il C++ è attualmente usato dalla maggior parte del mondo conosciuto, quando si tratta di scrivere codice nativo. Quindi bisogna conoscerlo per forza di cose, se non altro per non trovarsi nella situazione di non saper interpretare il codice scritto da altri. Se ti portano del codice C che utilizza una gets() su un buffer nello stack, devi sapere che è del codice scorretto che probabilmente consentirà ad un malintenzionato di eseguire codice arbitrario. Ora, poiché tu stesso hai ammesso che un linguaggio di livello più basso è necessario per determinate situazioni, e poiché tali situazioni non andranno prevedibilmente via in un futuro prossimo, ne consegue che deve fare parte della conoscenza di un buon programmatore come farne fronte.
Non vedo perché: in quasi 4 anni che lavoro in quel-linguaggio-che-preferisco-non-nominare ho dovuto ricorrere una sola a conoscenze di più basso livello, ma sempre senza richiedere l'uso di C o C++.

Mi riferisco, nello specifico, al recupero dei risultati dell'istruzione CPUID, di cui qualche mese fa si è discusso in un thread.

Al lavoro non sono dovuto MAI, e dico MAI, ricorrere a C o C++ per migliorare le prestazioni delle mie applicazioni. Né tanto meno mi sono mai dovuto porre il problema della sicurezza relativo all'utilizzo di funzioni come la gets del C.
In che linguaggio è scritto l'interprete ufficiale di Python? In che linguaggio è scritta la versione nativa di Ruby? In che linguaggio sono scritti Perl e gran parte dei suoi moduli? In che linguaggio è scritta la JVM? Non credo che tutti quelli che hanno scritto questi linguaggi sono degli sconsiderati ignoranti "con le pezze al culo" come ho sentito dire in questo thread. Non sarà che attualmente gli ambienti di sviluppo basati su C/C++ sono un buon compromesso per quanto riguarda la scrittura di codice nativo?
Non credo proprio. Penso sia dovuto principalmente a due cose: a un retaggio culturale e alla diffusione di questo linguaggio (che, per fortuna, viene usato sempre meno).

Per rispondere alla prima parte, sì, l'ATTUALE implementazione ufficiale è scritta in C e viene chiamata CPython.
Ciò non toglie che esistano soluzioni scritte interamente nel linguaggio nativo (PyPy http://codespeak.net/pypy/dist/pypy/doc/home.html è il più famoso e apprezzato dalla comunità) oppure in C# (IronPython per .NET è l'esempio più noto).

Il linguaggio DI PER SE' ovviamente non specifica l'uso di nessun linguaggio in particolare per la sua implementazione.

Semplicemente al momento la soluzione adottata ufficialmente dalla comunità è CPython, ma non è un "punto fisso".

Idem per gli altri linguaggi.

x shinya: visto? Non ho mai usato quella parola magica... :D

banryu79

18-07-2008, 09:50

Era diventato semplicemente un thread "abbasso il C e basta" e ho pensato di postare un articolo in direzione opposta per farlo diventare "abbasso il C ma con criterio", affinché qualcuno leggendolo non si facesse un'idea del C che io reputo sbagliata. Se pensate che sono stato inopportuno scusate, ma mi sembra di aver postato con moderazione e senza preconcetti di sorta.

Ciao Peppez,
ho letto tutto con calma, guarda, per me tu hai le tue ragioni ma io ho un forte sospetto che il motivo per cui il C sia ancora insegnato all'università non sia esclusivamente e principalmente per i i motivi da te elencati, ma per i fattori espressi in modo colorito nel post di 71104.
Ripeto: questa è una mia opinione.

Qui non si vuole denigrare il linguaggio C (almeno non io), resta il fatto oggettivo che il C come linguaggio è assolutamente indispensabile solo in determinati contesti.

IMHO non è assolutamente necessario come formazione ad un programmatore (io ho cominciato a studiare programmaizone proprio con il C).
Di certo non è un linguaggio didattico.
E' un linguaggio che non perdona, questo sì, e come tale ti costringe a una certa disciplina e cautela nel suo utilizzo.
Con tutte le conseguenze del caso.

Ciao :)

^TiGeRShArK^

18-07-2008, 10:06

Non mi sembra che sei razionale affermando cose del genere. Consiglieresti a qualcuno di scrivere un intero sistema operativo in linguaggio macchina? Consiglieresti a qualcuno di scrivere una qualsiasi cosa in linguaggio macchina se non fosse strettamente necessario?

[i linguaggi di alto livello hanno un target più ristretto]

Consiglieresti a qualcuno di scrivere un intero sistema operativo in C? Consiglieresti a qualcuno di scrivere una qualsiasi cosa in C se non fosse strettamente necessario? :)

Ecco perché bisogna scegliere un compromesso fra l'assembly e il visual basic. E la gente usa il c++ perché a torto o a ragione è il miglior compromesso per ora.

Non serve a nulla usare un compromesso.
Si deve utilizzare un linguaggio a + alto livello possibile e solo dove strettamente necessario si deve scendere di livello utilizzando un altro linguaggio.
Non per niente i giochi, nonostante abbiano stretti requisiti prestazionali, utilizzano massicciamente linguaggi di scripting (python, LUA).

Ed è per questo che lo insegnano a scuola.

No, lo insegnano esattamente per i motivi citati da 71104.

Poi è chiaro che se lavori per un'azienda di software da impresa raramente ti capiterà di toccare qualcosa di più basso livello del Python. Ma non è prerogativa delle istituzioni scolastiche decidere quale sarà l'ambito finale del programmatore, ed ecco che di nuovo il c++ è la soluzione a più ampio raggio.

Ma anche no.
Il c++ ha una diffusione bassissima se paragonato a java o C#, in ambito lavorativo.

[la conoscenza della macchina]

Certo che non è /strettamente necessario/, ma non è /opportuno/?

Per me è opportuno, ma la conoscenza della macchina non te la da certo il c++.
Occorre MINIMO un corso di calcolatori elettronici, di architettura di calcolatori, di reti di calcolatori, INFINITI articoli sulle architetture e sul funzionamento delle architetture attuali, e programmazione in ASSEMBLY o in linguaggio macchina.
Non è certo programmando in C o in C++ che per magia impari come funziona la macchina.. :rolleyes:

Non è opportuno sapere che una soluzione recursiva è peggiore di una soluzione lineare?

Questo vale per tutti i linguaggi. Non lo impari certo usando C, C++.
Anzi lì probabilmente ti concentrerai + sulle peculiarità del linguaggio che sulla risoluzione del problema vera e propria e quindi avrai meno tempo da dedicare sull'algoritmo in se.

Eppure sono entrambe soluzioni valide e ben definite. Non è opportuno sapere che è più veloce trasferire riferimenti anziché spostare dati in memoria? Eppure sono entrambe soluzioni valide e ben definite.

che, ripeto, il C / C++ non insegna assolutamente. :)

[conoscere la macchina per scrivere codice più efficiente]

Quindi ancora una volta tu pensi che un programmatore sia ben formato se ha bisogno di affidarsi a strumenti scritti da terze parti per scrivere buon codice?

Ovvio.
La prima regola che insegnano in qualsiasi articolo / libro sull'ottimizzazione è che qualsiasi supposizione venga fatta sulle performance è al 99% dei casi sbagliata.
Per vedere il bottleneck non ci si può affidare ad una supposizione, ma si DEVE utilizzare un profiler che è l'unico che può dire se qualche blocco di codice sia un blocco critico oppure no.

E se nel caso di una malaugurata "discesa di livello" non sa dove mettere mano?

Nel caso in cui il profiler abbia indicato un blocco critico, si DEVE trovare una soluzione algoritmica + efficiente.
Solo ed esclusivamente nel caso in cui non sia possibile si può ottimizzare utilizzando costrutti + veloci dello stesso linguaggio, e solo come ultima spiaggia si deve usare un linguaggio a basso livello.
Da notare che anche con Java è possibile utilizzare l'assembly tramite JNI.

Guarda, probabilmente io detesto il C di più di te. Ho iniziato a programmare in C urlando e scalcitrando. E tutt'ora lo utilizzo solo quando sono costretto. Però né io né tu possiamo fingere di ignorare che il C++ è attualmente usato dalla maggior parte del mondo conosciuto, quando si tratta di scrivere codice nativo. Quindi bisogna conoscerlo per forza di cose, se non altro per non trovarsi nella situazione di non saper interpretare il codice scritto da altri. Se ti portano del codice C che utilizza una gets() su un buffer nello stack, devi sapere che è del codice scorretto che probabilmente consentirà ad un malintenzionato di eseguire codice arbitrario.

Utilizzando un linguaggio che sia degno di essere definito tale puoi evitarti tutti questi pipponi mentali e concentrarti sulla risoluzione del problema vero e proprio.
Inutile dire quanti bug e problemi di sicurezza ci siano in giro proprio per l'utilizzo a sproposito di un linguaggio come il C / C++.

Ora, poiché tu stesso hai ammesso che un linguaggio di livello più basso è necessario per determinate situazioni, e poiché tali situazioni non andranno prevedibilmente via in un futuro prossimo, ne consegue che deve fare parte della conoscenza di un buon programmatore come farne fronte.

Un bravo programmatore può anche trascorrere la sua intera vita lavorativa senza dover mettere mano ad un dispositivo embedded o al kernel di linux.
Sicuramente vivrà + felice.

In che linguaggio è scritto l'interprete ufficiale di Python? In che linguaggio è scritta la versione nativa di Ruby? In che linguaggio sono scritti Perl e gran parte dei suoi moduli? In che linguaggio è scritta la JVM? Non credo che tutti quelli che hanno scritto questi linguaggi sono degli sconsiderati ignoranti "con le pezze al culo" come ho sentito dire in questo thread. Non sarà che attualmente gli ambienti di sviluppo basati su C/C++ sono un buon compromesso per quanto riguarda la scrittura di codice nativo?
La versione attuale di JRuby e + veloce della versione ufficiale 1.8.7 anche se è + lenta della 1.9.0 che è una "preview per sviluppatori".
Ma torniamo al discorso di cui sopra relativo all'ottimizzazione proseguendo per questo discorso.
Scrivere un programma "general purpose" in C/C++ ad oggi è solo una perdita di salute e di tempo.
E questo mi pare che sia un dato di fatto.

peppepz

18-07-2008, 11:10

Proprio perché sono razionale ho fatto quell'esempio: per dimostrare la non razionalità della tua precedente affermazione, dove hai imposto una soluzione al modello prospettato. Io ti ho semplicemente mostrato LA soluzione (perché è unica) che ti permette di realizzare qualunque cosa non dipendendo da nessun'altra.

La discussione era: i linguaggi di livello medio-basso consentono di scrivere uno spettro più ampio di applicazioni rispetto a quelli di livello alto, che io avevo sintetizzando dicendo che la programmazione in un linguaggio come il C è più "generica".
La tua risposta è che in assembler si può scrivere una quantità ancora maggiore di applicazioni? In questo tempo e su questo pianeta? Quand'è così non è necessario disquisire oltre su questo punto, penso che chi ci legge conosce già i pareri mio e tuo ed abbia gli strumenti per decidere quale dei due sia più consono alla realtà dei fatti.

Per il restono, no, non lo consiglierei al mio peggior nemico di sviluppare in linguaggio macchina. E altrettanto faccio per linguaggi come C et similia (ma su questo mi sono già espresso e non voglio riaprire una diatriba, come qualcuno ha già anticipato).

La differenza è che tutti i sistemi operativi moderni sono scritti in C per il 99%. Io non credo che sia a causa dell'oscurantismo dei professori universitarii.

E allora la scuola dovrebbe insegnare anche l'assembly perché ci si potrebbe ritrovare a sviluppare il bootloader, lo scheduler o il gestore di interrupt di un s.o..
Il linguaggio macchina per sviluppare compilatori, emulatori, virtual machine, ecc.
Dovrebbe insegnare un linguaggio funzionale (LISP o Haskell) perché ci si dovrebbe ritrovare a sviluppare software caro ai matematici.
Insegnare Prolog perché potresti lavorare a sistemi di intelligenza artificiale.
Il Fortran perché ancora oggi è usatissimo in sistemi di (massiccio) calcolo numerico.
SQL perché capiterà di utilizzare basi di dati.
E così via.
Esistono tanti di quegli ambiti in cui col solo C++ non si va da nessuna parte, che in teoria non dovresti più uscire da scuola perché dovrebbe prepararti ad affrontarli degnamente.

Neanche per idea. Deve insegnare un linguaggio che sia il più possibile vicino al baricentro fra tutti i linguaggi che hai menzionato. La opinione mia personale è che si tratti di un linguaggio più vicino al C o al Pascal che non allo Scala o al Lisp. Ed ho fornito esempi basati sulla mia pur limitata esperienza reale; ad esempio, il fatto che la grande maggioranza dei programmi scritti oggi, /hic et nunc/, è scritta in C o in C++.

Io preferisco che la scuola ti fornisca le basi della programmazione, e queste... non coincidono né col C né col C++ né con la programmazione strutturata.

Figurati, io ho imparato a programmare col BASIC, quindi è chiaro che i concetti base della programmazione sono astratti, prescindono anche dal concetto di hardware del tutto. Solo che il C ha il seducente vantaggio di essere il linguaggio mondialmente più usato per scrivere codice nativo. I processori attualmente in commercio eseguono codice "strutturato", quindi non potendo insegnare programmazione "astratta" tout court, non vedo cosa che somigli di più alle "basi della programmazione" più di imparare a scrivere un programma "strutturato" come se lo aspetta la CPU. Senza cadere nella trappola dell'assembly perché quest'ultimo - a differenza del C - non è adatto a sviluppare progetti di complessità più che modesta. Perciò il C mi pare una buona scelta, anche se non obiettivamente definibile la migliore. Se sai programmare in C, ti sarà facile apprendere qualsiasi altro paradigma; il contrario non mi pare altrettanto evidente.

Certo che non è /strettamente necessario/, ma non è /opportuno/?
Non è opportuno sapere che una soluzione recursiva è peggiore di una soluzione lineare? Eppure sono entrambe soluzioni valide e ben definite. Non è opportuno sapere che è più veloce trasferire riferimenti anziché spostare dati in memoria? Eppure sono entrambe soluzioni valide e ben definite.
E per far questo NON ti serve conoscere i dettagli di basso livello della macchina.

Come no? Non ti serve sapere che lo stack è una risorsa potenzialmente limitata e quindi è più "scalabile" fare riferimento ad altre risorse? Non ti serve sapere che le strutture sono composte da un numero di byte molto maggiore rispetto ai riferimenti ad esse?

Non vedo perché: in quasi 4 anni che lavoro in quel-linguaggio-che-preferisco-non-nominare ho dovuto ricorrere una sola a conoscenze di più basso livello, ma sempre senza richiedere l'uso di C o C++.

Magari perché fortunatamente c'è gente che ha scritto in C o C++ le librerie che tu invochi nel tuo linguaggio preferito?

Al lavoro non sono dovuto MAI, e dico MAI, ricorrere a C o C++ per migliorare le prestazioni delle mie applicazioni. Né tanto meno mi sono mai dovuto porre il problema della sicurezza relativo all'utilizzo di funzioni come la gets del C.

Anche in questo caso, questo è perché le parti più critiche delle tue applicazioni - immagino - l'interprete, il sistema operativo, magari anche la libreria standard e qualcos'altro - sono scritte in C o C++?

Non credo proprio. Penso sia dovuto principalmente a due cose: a un retaggio culturale e alla diffusione di questo linguaggio (che, per fortuna, viene usato sempre meno).

Anche in questo non siamo d'accordo ma è inutile continuare a discuterne, penso che le nostre posizioni sono chiare. Un'ultima domanda: quale linguaggio credi possa rimpiazzare completamente il C++ nell'immediato futuro? In modo che si possa passare a insegnarlo nelle scuole senza retaggi di sorta?

Per rispondere alla prima parte, sì, l'ATTUALE implementazione ufficiale è scritta in C e viene chiamata CPython.
Ciò non toglie che esistano soluzioni scritte interamente nel linguaggio nativo (PyPy http://codespeak.net/pypy/dist/pypy/doc/home.html è il più famoso e apprezzato dalla comunità) oppure in C# (IronPython per .NET è l'esempio più noto).

Il linguaggio DI PER SE' ovviamente non specifica l'uso di nessun linguaggio in particolare per la sua implementazione.

Semplicemente al momento la soluzione adottata ufficialmente dalla comunità è CPython, ma non è un "punto fisso".

Idem per gli altri linguaggi.

Solo che se chi ha ideato Python, quindi dotato di tutto il buon senso, della conoscenza e della libertà di chi sceglie di utilizzare questo linguaggio, ha deciso di implementare la sua principale incarnazione in C (manco C++!), allora come minimo significa che le piattaforme di sviluppo basate sul C, per quanto antiquate, ineleganti e facili all'errore, sono tuttora un buon compromesso Ergo, insegnare il C nelle scuole magari non è così insensato come si voleva far credere in questo thread.

Sia chiaro che personalmente non ho nulla contro il Python (tranne la sua dipendenza dal whitespace :-D) mentre ho molto contro il C e moltissimo contro il C++. Penso che il Python sia un ottimo linguaggio e penso che farebbero bene ad insegnarlo nelle scuole. Il mio vuole solo essere un richiamo all'obbiettività: insegnare il C non è una scelta sconsiderata, anche se il C ha i suoi limiti.

cdimauro

18-07-2008, 11:44

La discussione era: i linguaggi di livello medio-basso consentono di scrivere uno spettro più ampio di applicazioni rispetto a quelli di livello alto, che io avevo sintetizzando dicendo che la programmazione in un linguaggio come il C è più "generica".
La tua risposta è che in assembler si può scrivere una quantità ancora maggiore di applicazioni? In questo tempo e su questo pianeta? Quand'è così non è necessario disquisire oltre su questo punto, penso che chi ci legge conosce già i pareri mio e tuo ed abbia gli strumenti per decidere quale dei due sia più consono alla realtà dei fatti.
Sì, la mia risposta è esattamente quella: col linguaggio macchina si può scrivere in assoluto la più grande quantità di applicazioni.

Il prezzo da pagare per farlo NON era in discussione.
La differenza è che tutti i sistemi operativi moderni sono scritti in C per il 99%. Io non credo che sia a causa dell'oscurantismo dei professori universitarii.
Io credo di sì, visto che, come ho detto, esistono linguaggi che sono SUPERSET del C.
Neanche per idea. Deve insegnare un linguaggio che sia il più possibile vicino al baricentro fra tutti i linguaggi che hai menzionato. La opinione mia personale è che si tratti di un linguaggio più vicino al C o al Pascal che non allo Scala o al Lisp.
In questo caso il linguaggio che utilizzo adesso è sicuramente un candidato ideale, visto che permette di utilizzare diversi paradigmi di programmazione.
Ed ho fornito esempi basati sulla mia pur limitata esperienza reale; ad esempio, il fatto che la grande maggioranza dei programmi scritti oggi, /hic et nunc/, è scritta in C o in C++.
Questa statistica dove l'hai presa? Da parecchio tempo C e C++ NON sono i più utilizzati per lo sviluppo di nuove applicazioni. Tutt'altro.
Figurati, io ho imparato a programmare col BASIC, quindi è chiaro che i concetti base della programmazione sono astratti, prescindono anche dal concetto di hardware del tutto. Solo che il C ha il seducente vantaggio di essere il linguaggio mondialmente più usato per scrivere codice nativo.
Cosa intendi per "codice nativo"?
I processori attualmente in commercio eseguono codice "strutturato",
I processori eseguono sequenze di istruzioni condite da salti condizionati e non.
quindi non potendo insegnare programmazione "astratta" tout court, non vedo cosa che somigli di più alle "basi della programmazione" più di imparare a scrivere un programma "strutturato" come se lo aspetta la CPU.
Mi sfugge il passaggio che porta dall'architettura interna di un sistema alle basi della programmazione.

Come programmatore ho sempre seguito il seguente imperativo: http://it.wikipedia.org/wiki/Algoritmo

un algoritmo si può definire come un procedimento che consente di ottenere un risultato atteso eseguendo, in un determinato ordine, un insieme di passi semplici corrispondenti ad azioni scelte solitamente da un insieme finito.
Senza cadere nella trappola dell'assembly perché quest'ultimo - a differenza del C - non è adatto a sviluppare progetti di complessità più che modesta.
Non te lo lascio dire, visto che fino a una dozzina d'anni fa era il linguaggio maggiormente in voga per scrivere videogiochi, che non erano certo roba di modesta complessità...
Perciò il C mi pare una buona scelta, anche se non obiettivamente definibile la migliore. Se sai programmare in C, ti sarà facile apprendere qualsiasi altro paradigma; il contrario non mi pare altrettanto evidente.
Non pare a me e non vedo come. Potresti dimostrarlo?
Come no? Non ti serve sapere che lo stack è una risorsa potenzialmente limitata e quindi è più "scalabile" fare riferimento ad altre risorse? Non ti serve sapere che le strutture sono composte da un numero di byte molto maggiore rispetto ai riferimenti ad esse?
Il problema è sempre riconducibile allo SPAZIO a disposizione, che ovviamente è limitato.
Magari perché fortunatamente c'è gente che ha scritto in C o C++ le librerie che tu invochi nel tuo linguaggio preferito?

Anche in questo caso, questo è perché le parti più critiche delle tue applicazioni - immagino - l'interprete, il sistema operativo, magari anche la libreria standard e qualcos'altro - sono scritte in C o C++?
Come ti ho riportato prima, esistono progetti come PyPy dove l'intero codice è scritto nel linguaggio stesso del compilatore, librerie incluse.
Anche in questo non siamo d'accordo ma è inutile continuare a discuterne, penso che le nostre posizioni sono chiare. Un'ultima domanda: quale linguaggio credi possa rimpiazzare completamente il C++ nell'immediato futuro? In modo che si possa passare a insegnarlo nelle scuole senza retaggi di sorta?
Visto che parli d'insegnamento, la risposta è scontata, e puoi immaginare quale sia.
Solo che se chi ha ideato Python, quindi dotato di tutto il buon senso, della conoscenza e della libertà di chi sceglie di utilizzare questo linguaggio, ha deciso di implementare la sua principale incarnazione in C (manco C++!), allora come minimo significa che le piattaforme di sviluppo basate sul C, per quanto antiquate, ineleganti e facili all'errore, sono tuttora un buon compromesso
No, sono soltanto le più diffuse (con ciò intendo come disponibilità di un compilatore C per qualunque piattaforma esistente). Purtroppo.
Ergo, insegnare il C nelle scuole magari non è così insensato come si voleva far credere in questo thread.
Al solito, non capisco il legame fra diffusione (intesa come disponibilità) e insegnamento.

Se io voglio insegnare le basi della programmazione (e anche più) non ricorrerei certamente al C. Tutt'altro.
Sia chiaro che personalmente non ho nulla contro il Python (tranne la sua dipendenza dal whitespace :-D) mentre ho molto contro il C e moltissimo contro il C++. Penso che il Python sia un ottimo linguaggio e penso che farebbero bene ad insegnarlo nelle scuole. Il mio vuole solo essere un richiamo all'obbiettività: insegnare il C non è una scelta sconsiderata, anche se il C ha i suoi limiti.
Lo è proprio nell'ottica dell'insegnamento invece.

Per imparare a programmare bene e con un certo criterio (leggi: senza entrare nella contorta tipica mentalità del programmatore C) il C non è assolutamente la scelta ideale.

Poi un buon programmatore potrà benissimo, SE NECESSARIO, imparare anche il C.
mmm, quindi se io ti programmo una cosa in C++ senza sfruttare minimamente le funzionalità del C++ ma usando solo quelle del C sei più contento perchè sto usando il C++ e non il C?
Io no, perché tendo a utilizzare tutti i costrutti del linguaggio che uso (ovviamente in base alla necessità).

peppepz

18-07-2008, 11:45

Consiglieresti a qualcuno di scrivere un intero sistema operativo in C? Consiglieresti a qualcuno di scrivere una qualsiasi cosa in C se non fosse strettamente necessario? :)

Sì. Penso che se mi venisse richiesto di scrivere un sistema operativo senza scrivere prima un compilatore all'uopo, sceglierei il C.
Del resto Linux è scritto in C, Minix è scritto in C, Windows è scritto in C (le parti scritte prima del '93) e C++ (quelle più recenti), MacOS X è scritto in C e addirittura ObjectC, il DOS era scritto in C e assembly. Tu cosa proporresti?

Non serve a nulla usare un compromesso.
Si deve utilizzare un linguaggio a + alto livello possibile e solo dove strettamente necessario si deve scendere di livello utilizzando un altro linguaggio.

Questa è un'affermazione arbitraria.

Non per niente i giochi, nonostante abbiano stretti requisiti prestazionali, utilizzano massicciamente linguaggi di scripting (python, LUA).

Infatti la microsoft distribuisce binding per DirectX principalmente in C++. Stupidi e con le pezze al culo anche loro?

No, lo insegnano esattamente per i motivi citati da 71104.

Questa è un'altra affermazione arbitraria.

Ma anche no.
Il c++ ha una diffusione bassissima se paragonato a java o C#, in ambito lavorativo.

Stai estendendo la tua personale esperienza ad esperienza assoluta e rischi di commettere, ancora una volta, un arbitrio. La tendenza attuale è, se scrivi codice /nativo/, di farlo in C++, mentre per il codice lato "enterprise" si usano Java, Perl, Python, col .NET che si sta inserendo.

Per me è opportuno, ma la conoscenza della macchina non te la da certo il c++.
Occorre MINIMO un corso di calcolatori elettronici, di architettura di calcolatori, di reti di calcolatori, INFINITI articoli sulle architetture e sul funzionamento delle architetture attuali, e programmazione in ASSEMBLY o in linguaggio macchina.
Non è certo programmando in C o in C++ che per magia impari come funziona la macchina.. :rolleyes:

E' un punto di partenza e a scuola si insegnano proprio i punti di partenza. Poi ognuno approfondisce in base al settore in cui intende specializzarsi.

Non è opportuno sapere che una soluzione recursiva è peggiore di una soluzione lineare?

Questo vale per tutti i linguaggi. Non lo impari certo usando C, C++.
Anzi lì probabilmente ti concentrerai + sulle peculiarità del linguaggio che sulla risoluzione del problema vera e propria e quindi avrai meno tempo da dedicare sull'algoritmo in se.

Certo che lo impari, perché sai che cos'è lo stack, perché sai dove vengono messe le variabili locali e i parametri, perché in C la memoria la devi gestire tu. Non così in Java, ad esempio. Per quanto riguarda i limiti del C, ripeto che ne sono bene a conoscenza, ma qua il discorso era "vale la pena insegnare il C a scuola?".

Eppure sono entrambe soluzioni valide e ben definite. Non è opportuno sapere che è più veloce trasferire riferimenti anziché spostare dati in memoria? Eppure sono entrambe soluzioni valide e ben definite.

che, ripeto, il C / C++ non insegna assolutamente. :)

Certo che le impari, perché il giorno che provi a trasferire una struttura con = come faresti con un puntatore, otterrai un errore . E questo ti porterà ad usare memcpy, che ti obbliga a sapere quanti byte misura la struttura che devi trasferire.

Ovvio.
La prima regola che insegnano in qualsiasi articolo / libro sull'ottimizzazione è che qualsiasi supposizione venga fatta sulle performance è al 99% dei casi sbagliata.

E questa è un'altra affermazione arbitraria.

Per vedere il bottleneck non ci si può affidare ad una supposizione, ma si DEVE utilizzare un profiler che è l'unico che può dire se qualche blocco di codice sia un blocco critico oppure no.

Nel caso in cui il profiler abbia indicato un blocco critico, si DEVE trovare una soluzione algoritmica + efficiente.
Solo ed esclusivamente nel caso in cui non sia possibile si può ottimizzare utilizzando costrutti + veloci dello stesso linguaggio, e solo come ultima spiaggia si deve usare un linguaggio a basso livello.
Da notare che anche con Java è possibile utilizzare l'assembly tramite JNI.

Una cosa è individuare colli di bottiglia, per i quali ti serve il profiler, altra cosa è scrivere buon codice in partenza, cosa che puoi fare con la conoscenza dell'esecutore del tuo codice. E quale delle due cose ti debbono insegnare a scuola?

[c'è un sacco di codice scritto in C/++ e quindi è bene conoscerlo per migliorarlo]

Utilizzando un linguaggio che sia degno di essere definito tale puoi evitarti tutti questi pipponi mentali e concentrarti sulla risoluzione del problema vero e proprio.
Inutile dire quanti bug e problemi di sicurezza ci siano in giro proprio per l'utilizzo a sproposito di un linguaggio come il C / C++.

A parte che ancora una volta affermazioni come "il c non è un linguaggio degno di essere definito tali" sono arbitrarie, il mio punto non era "il C è il miglior linguaggio di programmazione oggi disponibile", ma "la maggior parte del codice nativo attualmente in circolazione è scritta in C/++, quindi è importante conoscerlo". A questo come rispondi?

Un bravo programmatore può anche trascorrere la sua intera vita lavorativa senza dover mettere mano ad un dispositivo embedded o al kernel di linux.

Dipende dal settore in cui lavori. Scrivi script per servire dati? Allora probabilmente il C non ti serve. Scrivi software di elaborazione dati? Allora probabilmente le prestazioni di un linguaggio nativo come il C potranno cominciare a farti gola. Scrivi software che in generale si deve integrare nel sistema operativo dell'utente? Ancora una volta per qualche motivo la stragrande maggioranza dei sistemi operativi esce di fabbrica con binding per il C/++.

[senza programmare in C, il programmatore...]

Sicuramente vivrà + felice.

Su questo sono pienamente d'accordo con te. Il punto della discussione è se, per com'è configurata la situazione attuale nel mondo della programmazione, egli possa scegliere di farne a meno tutte le volte che vuole.

Scrivere un programma "general purpose" in C/C++ ad oggi è solo una perdita di salute e di tempo.
E questo mi pare che sia un dato di fatto.

Solo che per qualche motivo il mondo pare pieno di masochisti che continuano a farlo. O forse potremmo ammettere che, TUTTORA, qualche minimo motivo per utilizzare il C++ permane?

Big Bamboo

18-07-2008, 12:19

In questo periodo scrivo in C tutti i santi giorni, non è poi così gravoso :D
Alla fine è tutta questione di abitudine e di contesto

^TiGeRShArK^

18-07-2008, 12:31

Sì. Penso che se mi venisse richiesto di scrivere un sistema operativo senza scrivere prima un compilatore all'uopo, sceglierei il C.

Stavamo parlando di scrivere un sistema operativo COMPLETO.
come lo scrivi il bootloader senza usare l'assembly? :)

Del resto Linux è scritto in C, Minix è scritto in C, Windows è scritto in C (le parti scritte prima del '93) e C++ (quelle più recenti), MacOS X è scritto in C e addirittura ObjectC, il DOS era scritto in C e assembly. Tu cosa proporresti?

Mac OS X ha parti in C, parti in objective-c (COCOA) e parti in C++ (Carbon).
comunque, precisazione a parte, per ogni cosa serve lo strumento + adatto.
Per alcune parti di un Sistema Operativo lo strumento + adatto è il C/C++, ma non lo è certo per una qualsiasi altro software, a parte situazioni MOLTO particolari.

Questa è un'affermazione arbitraria.

controbatti allora se per te è un'affermazione arbitraria, allora sarà facilissimo confutarla :)
quale sarebbe il metodo migliore?
scrivere tutto in C/C++ perdendo un'enormità di tempo anche per parti di codice in cui l'utilizzo di tale linguaggio è assolutamente inutile? :)

Infatti la microsoft distribuisce binding per DirectX principalmente in C++. Stupidi e con le pezze al culo anche loro?

Infatti anche alla microsoft, tanto per confermare la mia "affermazione arbitraria" precedente, utilizzano linguaggi di scripting. :)
Chiedi a fek per informazioni che ti potrà spiegare quali sono i linguaggi di scripting + utilizzati nel panorama videoludico.

Questa è un'altra affermazione arbitraria.

comodo bollare come "affermazioni arbitrarie" delle frasi che non si riesce a confutare argomentando :)

Stai estendendo la tua personale esperienza ad esperienza assoluta e rischi di commettere, ancora una volta, un arbitrio. La tendenza attuale è, se scrivi codice /nativo/, di farlo in C++, mentre per il codice lato "enterprise" si usano Java, Perl, Python, col .NET che si sta inserendo.

qual'è la diffusione del codice nativo nel mondo lavorativo odierno rispetto a linguaggi basati su JIT quali Java e C#?
Prova a dare un occhiata agli annunci lavorativi, gugoxx un pò di tempo fa aveva postato delle statistiche molto emblematiche in merito.

E' un punto di partenza e a scuola si insegnano proprio i punti di partenza. Poi ognuno approfondisce in base al settore in cui intende specializzarsi.

Partire con il C è quanto di + sbagliato ci possa essere dato che non impari a programmare ad oggetti.
Partire col c++ è comunque errato dato che piuttosto che concentrarti sulla risoluzione dei problemi ti concentri sulle bestemmie che devi indirizzare sul santo del giorno per il segmentation fault o il memory leak di turno.

Certo che lo impari, perché sai che cos'è lo stack, perché sai dove vengono messe le variabili locali e i parametri, perché in C la memoria la devi gestire tu. Non così in Java, ad esempio. Per quanto riguarda i limiti del C, ripeto che ne sono bene a conoscenza, ma qua il discorso era "vale la pena insegnare il C a scuola?".

e quello secondo te sarebbe "conoscere la macchina" :asd:
Per me puoi dire di conoscere la macchina quando mi sai spiegare per filo e per segno come funziona un architettura x86, partendo dall'acquisizione dei dati tramite il FSB o il memory controlleer integrato, come quello degli A64 e di nehalem, l'interfacciamento con la cache di terzo, secondo livello e primo livello, l'utilizzo del TLB, i vari stadi della pipeline a partire dal prefetch, passando per i decoders che traformano le istruzioni x86 in microops risc-like ed eventualmente le fondono insieme (nelle soluzioni + moderne), ecc... ecc..
Ce ne sarebbe da scrivere una quintalata di roba su un moderno processore.
e assolutamente NIENTE di tutto questo lo impari con il C.
Impari giusto qualcosina programmando in assembly e in linguaggio macchina, perchè quanto meno hai a che fare con il numero dei registri (quelli interi e SSE sono raddoppiati con l'architettura x86-64), con la loro dimensione, con le istruzioni vettoriali delle SSE/MMX ecc... ecc..
Pure in Java impari volendo cos'è uno stack, un riferimento e la differenza tra stack e heap.
anzi, con java molto probabilmente imparerai meglio la differenza tra passaggio per copia e per riferimento che molti sedicenti programmatori C non conoscono per nulla in dettaglio ;)

Certo che le impari, perché il giorno che provi a trasferire una struttura con = come faresti con un puntatore, otterrai un errore . E questo ti porterà ad usare memcpy, che ti obbliga a sapere quanti byte misura la struttura che devi trasferire.

Pensa te che culo.
E mi dici quanto occupa una struttura con 4 interi e un double in C? :)

E questa è un'altra affermazione arbitraria.

no, questa è la prima cosa che ti viene insegnata quando studi cose di un certo livello.
Ma, data la tua affermazione precedente, immagino che non hai un background molto profondo riguardo l'ottimizzazione e i profiler.
Ti consiglio qualche lettura sull'argomento soprattutto in ambito mobile dove le ottimizzazioni sono spesso essenziali e dove puoi trovare una vasta letteratura in merito :)

Una cosa è individuare colli di bottiglia, per i quali ti serve il profiler, altra cosa è scrivere buon codice in partenza, cosa che puoi fare con la conoscenza dell'esecutore del tuo codice. E quale delle due cose ti debbono insegnare a scuola?

Un buon codice è assolutamente slegato dalla conoscenza della macchina.
Citando a memoria: "Every fool can write a code that a machine can execute, only good programmers can write a code that other humans could understand".
Scrivere codice leggibile è molto + difficile che scrivere codice "performante".
Peccato che tutti si sentano geek o "hacker" quanto scrivono un paio di righe incomprensibili in c o in perl.. :doh:

[c'è un sacco di codice scritto in C/++ e quindi è bene conoscerlo per migliorarlo]

Appunto.
Ma solo in ambito legacy.
Lo stesso vale anche per il Fortran e soprattutto il COBOL in ambito bancario.
La maggior parte del codice scritto ad oggi non utilizza certo il C++.

A parte che ancora una volta affermazioni come "il c non è un linguaggio degno di essere definito tali" sono arbitrarie, il mio punto non era "il C è il miglior linguaggio di programmazione oggi disponibile", ma "la maggior parte del codice nativo attualmente in circolazione è scritta in C/++, quindi è importante conoscerlo". A questo come rispondi?

A che serve scrivere codice nativo non portabile nell'era dei JIT altamente efficienti e della portabilità/flessibilità?
Prova a fare in C/C++ quello che fai in java/C#.
Bene che ti vada scrivi 10 volte la quantità di codice necessaria.

Dipende dal settore in cui lavori. Scrivi script per servire dati? Allora probabilmente il C non ti serve. Scrivi software di elaborazione dati? Allora probabilmente le prestazioni di un linguaggio nativo come il C potranno cominciare a farti gola.

Ma anche no.
In quel caso molto meglio utilizzare CUDA, con cui scriverai solo una minima parte in C e poi sarai liberissimo di usare python.

Scrivi software che in generale si deve integrare nel sistema operativo dell'utente? Ancora una volta per qualche motivo la stragrande maggioranza dei sistemi operativi esce di fabbrica con binding per il C/++.

Il C# si integra perfettamente con windows.
Il Java si integra perfettamente con linux, solaris, mac os x e windows.
Dove sarebbe la supposta superiorità del c++ in questo caso?

[senza programmare in C, il programmatore...]

Su questo sono pienamente d'accordo con te. Il punto della discussione è se, per com'è configurata la situazione attuale nel mondo della programmazione, egli possa scegliere di farne a meno tutte le volte che vuole.

Può scegliere di farne a meno ogni volta che ci sia uno strumento migliore.
Un linguaggio è solo uno strumento, è questo che bisogna mettersi in testa.
Bisogna sempre utilizzare "the right tool for the right job" e non ha alcun senso difendere a spada tratta strumenti come il c / c++ se nel 90% dei casi ci sono strumenti migliori.

Solo che per qualche motivo il mondo pare pieno di masochisti che continuano a farlo. O forse potremmo ammettere che, TUTTORA, qualche minimo motivo per utilizzare il C++ permane?
Sono in forte diminuzione i masochisti che utilizzano c++ :)
Per lo + sotto linux vedo che ancora sono in molti ad utilizzarlo, mentre sotto windows si preferisce di gran lunga il C#.

71104

18-07-2008, 12:59

Guarda che poi nel mondo del lavoro verrai quasi sicuramente impiegato come programmatore alla stregua dei ragazzini che escono dalle superiori e non sanno una cippa di niente.
In Italia informatica significa solo programmatori. be' adesso non esageriamo... :mc:

io quando lavorerò vorrei fare il programmatore perché mi piace programmare, anche se so che sarò ampiamente sottopagato (motivo percui ultimamente mi sto informando su cosa dovrei fare per trasferirmi e vivere all'estero), ma se uno ha un buon curriculum spero che anche in Italia le possibilità di carriera non siano così limitate... anche se magari alla fine ti ritrovi a non programmare per nulla ma a fare tutt'altro lavoro.

Ah dimenticavo VB6 va ancora alla grande se lo scordano, io nel curriculum VB6 non ce l'ho e non ho intenzione di impararlo -.-'
si "accontentassero" di quello che gli offro: esperienza in C++, Java, .NET, ultimamente anche un pizzico di Python :D, e dulcis in fundo dovesse mai servire PERSINO IL C. ma VB6 no -.-'

71104

18-07-2008, 13:07

Sono in forte diminuzione i masochisti che utilizzano c++ :) però ha ragione: dei motivi per continuare ad usare il C++ esistono ancora, infatti il bacino di masochismo di cui si parla è in diminuzione ma non può ancora scomparire del tutto, anzi (spesso non si tratta solo di masochismo).

Per lo + sotto linux vedo che ancora sono in molti ad utilizzarlo, mentre sotto windows si preferisce di gran lunga il C#. perché Linux è arretrato :D

in teoria anche su Linux esistono ambienti managed, anche su Linux esiste Java; però C# è più moderno (si parlava l'altro giorno di LINQ, no? :D) e sto benedetto Java 7 non esce, quindi morale della favola il mondo di Linux è sempre indietro, come al solito :asd:

peppepz

18-07-2008, 13:15

Sì, la mia risposta è esattamente quella: col linguaggio macchina si può scrivere in assoluto la più grande quantità di applicazioni.

Il prezzo da pagare per farlo NON era in discussione.

Ti rispiego il mio punto precisando meglio. "Con un linguaggio di basso livello si possono scrivere una quantità ampia di applicazioni, senza incorrere in problemi che rendano la suddetta scrittura difficile o impossibile nei tempi e con le risorse mediamente disponibili al giorno d'oggi per la realizzazione di tali progetti." La fondatezza di tale affermazione è evidentemente documentata dal fatto che la stragrande maggioranza delle applicazioni oggi è, per qualche motivo, scritta in C (in UNIX) o in C++ (in UNIX e nel resto del mondo).

La tua risposta è che con l'assembler...?

La differenza è che tutti i sistemi operativi moderni sono scritti in C per il 99%. Io non credo che sia a causa dell'oscurantismo dei professori universitarii.

Io credo di sì, visto che, come ho detto, esistono linguaggi che sono SUPERSET del C.

Tecnicamente parlando il C++ non è un superset proprio del C, nel senso che ci sono sorgenti C che non sono sorgenti validi C++ ;-) ma non discutiamo di questo.
Il fatto è che questi linguaggi (tipo il D), non hanno una comunità e un seguito sufficientemente larghi da giustificare l'abbandono del C++. Probabilmente perché il C++, con tutti i suoi - ripeto - TANTISSIMI difetti, non è poi un linguaggio così inutilizzabile.

Supponiamo che io progetti una nuova architettura di elaborazione. Quale sarà il primo passo? OK, scrivere un assembler, ma il secondo? Sviluppare un compilatore C e una libreria standard. Dal momento in cui io ho disponibile un compilatore C (che oggi è di solito il gcc), ho a disposizione per la mia macchina un'IMMENSA quantità di software di qualità medio-alta a disposizione, alla quale dovrei rinunciare se scegliessi di usare un linguaggio esotico. Negli anni '80 nel mondo dei computer personali / per le piccole aziende, tale ruolo era svolto dall'interprete BASIC. E infatti a scuola si insegnava il BASIC, che era pieno di difetti. Oggi questo ruolo di "lingua franca" è svolto dal C/++, e per questo a scuola si insegna il C, con tutti i suoi difettacci.

Neanche per idea. Deve insegnare un linguaggio che sia il più possibile vicino al baricentro fra tutti i linguaggi che hai menzionato. La opinione mia personale è che si tratti di un linguaggio più vicino al C o al Pascal che non allo Scala o al Lisp.

In questo caso il linguaggio che utilizzo adesso è sicuramente un candidato ideale, visto che permette di utilizzare diversi paradigmi di programmazione.

Intendi dire come il C++ :-D ? Che in più ti costringe ad avere una maggiore conoscenza tecnica della macchina?

d ho fornito esempi basati sulla mia pur limitata esperienza reale; ad esempio, il fatto che la grande maggioranza dei programmi scritti oggi, /hic et nunc/, è scritta in C o in C++.

Questa statistica dove l'hai presa? Da parecchio tempo C e C++ NON sono i più utilizzati per lo sviluppo di nuove applicazioni. Tutt'altro.

Vuoi che ti presenti la lista dei programmi che uso su questa macchina e il linguaggio in cui sono scritti?

Solo che il C ha il seducente vantaggio di essere il linguaggio mondialmente più usato per scrivere codice nativo.

Cosa intendi per "codice nativo"?

Codice che viene eseguito direttamente dal processore della macchina ospite.

I processori attualmente in commercio eseguono codice "strutturato",

I processori eseguono sequenze di istruzioni condite da salti condizionati e non.

I processori hanno istruzioni e registri per supportare l'utilizzo di funzioni proprio come il C.
I processori hanno istruzioni e registri per supportare l'utilizzo di uno stack per il passaggio dei parametri e il mantenimento delle variabili locali proprio come richiesto dal C.
I processori vedono la memoria come una sequenza non-gestita di byte proprio come il C.

quindi non potendo insegnare programmazione "astratta" tout court, non vedo cosa che somigli di più alle "basi della programmazione" più di imparare a scrivere un programma "strutturato" come se lo aspetta la CPU.

Mi sfugge il passaggio che porta dall'architettura interna di un sistema alle basi della programmazione.

Come programmatore ho sempre seguito il seguente imperativo: http://it.wikipedia.org/wiki/Algoritmo

un algoritmo si può definire come un procedimento che consente di ottenere un risultato atteso eseguendo, in un determinato ordine, un insieme di passi semplici corrispondenti ad azioni scelte solitamente da un insieme finito.

Questo è quello che puoi insegnare alla prima lezione introduttiva di un corso di informatica, ma poi devi scegliere un linguaggio del mondo reale da insegnare, a meno che non vuoi formare degli esperti che, finito il corso, non siano in grado di scrivere software per nessuna macchina reale.
La mia idea è che, potendo scegliere, ha un senso insegnare un linguaggio che non sia troppo distante dalla macchina, perché questo conferisce maggiore libertà di specializzazione a chi apprende. Ha un senso? Sì. E' l'unica scelta possibile? No.

Senza cadere nella trappola dell'assembly perché quest'ultimo - a differenza del C - non è adatto a sviluppare progetti di complessità più che modesta.

Non te lo lascio dire, visto che fino a una dozzina d'anni fa era il linguaggio maggiormente in voga per scrivere videogiochi, che non erano certo roba di modesta complessità...

Nel 1996 l'assembler non era più in uso da almeno sei anni. Nel 96 è uscito Quake, che fu famoso perché era scritto col gcc. La filosofia dei giochi dagli anni novanta in poi è stata di sviluppare il nocciolo del gioco in C o C++ e le routine critiche per le prestazioni (o di interfacciamento generale con l'hardware, che a quei tempi era diretto) in assembly.
Il compilatore più usato era il watcom c++, chiunque abbia usato giochi di quel periodo si ricorderà i messaggi del "dos/4gw" usato come ambiente operativo da quel compilatore.
Inutile dire che lo spostamento dei giochi dall'assembly al C al C++ ha coinciso con il crescere della complessità e profondità degli stessi - alley cat, presumibilmente scritto in assembly, non aveva certo la stessa complessità di duke nukem 3d, scritto in C.

Perciò il C mi pare una buona scelta, anche se non obiettivamente definibile la migliore. Se sai programmare in C, ti sarà facile apprendere qualsiasi altro paradigma; il contrario non mi pare altrettanto evidente.

Non pare a me e non vedo come. Potresti dimostrarlo?

Ad esempio, se programmi in C++ sai allocare e disallocare la memoria. Quando passi a Java, non hai più bisogno di saperlo fare perché c'è il garbage collector. Il contrario non è vero.
Se programmi in C++ sai gestire direttamente le stringhe manovrando i puntatori. Quando passi a Java, non hai più bisogno di saperlo fare perché ci sono le classi della libreria standard che ti aiutano. Il contrario non è vero.

Un'ultima domanda: quale linguaggio credi possa rimpiazzare completamente il C++ nell'immediato futuro? In modo che si possa passare a insegnarlo nelle scuole senza retaggi di sorta?

Visto che parli d'insegnamento, la risposta è scontata, e puoi immaginare quale sia.

No, no, non parlo dell'insegnamento, intendo dire rimpiazzare il C++ del tutto, in modo che come conseguenza non sia più utile insegnarlo.

[le piattaforme basate sul C/C++]
No, sono soltanto le più diffuse (con ciò intendo come disponibilità di un compilatore C per qualunque piattaforma esistente). Purtroppo.

Al solito, non capisco il legame fra diffusione (intesa come disponibilità) e insegnamento.

Semplice, perché dà la maggiore libertà a chi lo impara. Se impari il C++, impari a conoscere come funziona un computer ma per contro devi circumnavigare le deficienze di un linguaggio nato trent'anni fa come "assembler di alto livello". Solo che poi - come tu stesso affermi - sarai in grado di scrivere software per qualunque piattaforma esistente. E di comprendere il codice scritto da una grossissima fetta dei programmatori esistenti. E' questo il legame fra diffusione/disponibilità e convenienza dell'apprendimento. Io penso che la convenienza ci sia, tu pensi di no - ma è importante che chi ci legge possa scegliere.

Se io voglio insegnare le basi della programmazione (e anche più) non ricorrerei certamente al C. Tutt'altro.

E probabilmente faresti bene. L'imporante è che non giudichi arbitrariamente, come si faceva in questo thread, chi fa una scelta differente che comunque, come io ho spiegato, i suoi vantaggi ce l'ha.

Per imparare a programmare bene e con un certo criterio (leggi: senza entrare nella contorta tipica mentalità del programmatore C) il C non è assolutamente la scelta ideale.

Spiegami meglio. M'interessa perché potrei scoprire di avere una mentalità contorta :-D.

Poi un buon programmatore potrà benissimo, SE NECESSARIO, imparare anche il C.

Già, senza farsi venire troppi sensi di colpa!

grigor91

18-07-2008, 13:28

Il C++ è un SUPERSET del C, quindi può fare esattamente le stesse cose (e molto di più ovviamente).

Similmente al C++, c'è anche il D che può essere usato come linguaggio "di sistema", pur presentando dei costrutti semantici interessanti.

Come vedi di alternative al C ce ne sono: basta sfruttarle. :O

quindi il C lo odi e il C++ ti piace?

peppepz

18-07-2008, 14:49

Stavamo parlando di scrivere un sistema operativo COMPLETO.
come lo scrivi il bootloader senza usare l'assembly? :)

A parte che un boot loader si può tranquillamente scrivere in C, l'unica parte in cui avrei bisogno di usare l'assembly sarebbero le istruzioni privilegiate per mettere la CPU in modalità protetta. Poco fa tu avevi fatto sembrare che scrivere un sistema operativo in C fosse una cosa assurda, mentre già ora ammetti:

Per alcune parti di un Sistema Operativo lo strumento + adatto è il C/C++, ma non lo è certo per una qualsiasi altro software, a parte situazioni MOLTO particolari.

Io ritengo che queste situazioni che tu chiami molto particolari siano molto più vicine alla normalità. Confronta quanto ho detto a mauro.

Non serve a nulla usare un compromesso.
Si deve utilizzare un linguaggio a + alto livello possibile e solo dove strettamente necessario si deve scendere di livello utilizzando un altro linguaggio.

controbatti allora se per te è un'affermazione arbitraria, allora sarà facilissimo confutarla :)
quale sarebbe il metodo migliore?
scrivere tutto in C/C++ perdendo un'enormità di tempo anche per parti di codice in cui l'utilizzo di tale linguaggio è assolutamente inutile? :)

E' che se io affermo un concetto, debbo dire anche quali sono le ragioni della mia affermazione, altrimenti di cosa discutiamo? Se non lo faccio mi pare giusto (http://www.demauroparavia.it/7876) che la mia affermazione sia definita arbitraria.
Il fatto che in C++ non si perda poi così tanto tempo è testimoniato dal fatto che ancora la maggior parte dei programmatori lo usa. Per cui non è stupido insegnarlo, la mia affermazione è semplicemente questa.
A me non piace il C, e meno ancora il C++, però bisogna essere obbiettivi.

Infatti la microsoft distribuisce binding per DirectX principalmente in C++. Stupidi e con le pezze al culo anche loro?

Infatti anche alla microsoft, tanto per confermare la mia "affermazione arbitraria" precedente, utilizzano linguaggi di scripting. :)
Chiedi a fek per informazioni che ti potrà spiegare quali sono i linguaggi di scripting + utilizzati nel panorama videoludico.

Padronissimi di farlo, mi hai sentito affermare che gli script non siano utili? Sei tu che affermi che il C++ è un qualcosa che viene usato solamente da individui oscurantisti e arretrati che per qualche motivo non vogliono imparare nuovi linguaggi. Io per contrastare questa tua affermazione ti faccio notare nuovamente che posso indicarti un sito della microsoft dal quale scaricare l'sdk dell'ultima versione di directx per C++. Puoi fare lo stesso con il tuo linguaggio di scripting preferito?

comodo bollare come "affermazioni arbitrarie" delle frasi che non si riesce a confutare argomentando :)

No, bollo come arbitrarie le affermazioni che non sono argomentate da parte tua in prima istanza. Affermazioni come questa:

No, lo insegnano esattamente per i motivi citati da 71104.

qual'è la diffusione del codice nativo nel mondo lavorativo odierno rispetto a linguaggi basati su JIT quali Java e C#?
Prova a dare un occhiata agli annunci lavorativi, gugoxx un pò di tempo fa aveva postato delle statistiche molto emblematiche in merito.

Solo perché ci sono molte più aziende che progettano soluzioni di gestione di dati all'impresa piuttosto che aziende che scrivono software per uso personale. Quanti programmi usi tu tutti i giorni che /non siano/ scritti in C++?

Partire con il C è quanto di + sbagliato ci possa essere dato che non impari a programmare ad oggetti.

Perché? Non è molto più facile imparare prima un linguaggio procedurale invece di cimentarsi di botto con le complessità dei linguaggi orientati agli oggetti? Uno impara prima il C, e poi passa al C++ quando è in grado di apprezzare le qualità della programmazione a oggetti.

Partire col c++ è comunque errato dato che piuttosto che concentrarti sulla risoluzione dei problemi ti concentri sulle bestemmie che devi indirizzare sul santo del giorno per il segmentation fault o il memory leak di turno.

Qualcuno ti potrebbe dire che saper gestire una macchina è una parte importante della programmazione.

e quello secondo te sarebbe "conoscere la macchina" :asd:
Per me puoi dire di conoscere la macchina quando mi sai spiegare per filo e per segno come funziona un architettura x86, partendo dall'acquisizione dei dati tramite il FSB o il memory controlleer integrato, come quello degli A64 e di nehalem, l'interfacciamento con la cache di terzo, secondo livello e primo livello, l'utilizzo del TLB, i vari stadi della pipeline a partire dal prefetch, passando per i decoders che traformano le istruzioni x86 in microops risc-like ed eventualmente le fondono insieme (nelle soluzioni + moderne), ecc... ecc..
Ce ne sarebbe da scrivere una quintalata di roba su un moderno processore.
e assolutamente NIENTE di tutto questo lo impari con il C.
Impari giusto qualcosina programmando in assembly e in linguaggio macchina, perchè quanto meno hai a che fare con il numero dei registri (quelli interi e SSE sono raddoppiati con l'architettura x86-64), con la loro dimensione, con le istruzioni vettoriali delle SSE/MMX ecc... ecc..
Pure in Java impari volendo cos'è uno stack, un riferimento e la differenza tra stack e heap.
anzi, con java molto probabilmente imparerai meglio la differenza tra passaggio per copia e per riferimento che molti sedicenti programmatori C non conoscono per nulla in dettaglio ;)

Semplicemente utilizzando un linguaggio tu impari la "macchina virtuale" che te lo esegue. La "macchina C" è vicinissima alla macchina hardware, presenta come servizio aggiunto la possibilità di scrivere istruzioni più complesse e di utilizzare tipi di dati strutturati, per il resto il funzionamento della macchina rimane bene in vista come ho spiegato prima a mauro e come tu stesso hai affermato poco fa quando dicevi "ti concentri sulle bestemmie che devi indirizzare sul santo del giorno per il segmentation fault o il memory leak di turno".

Tutti i dettagli che mi hai prima elencato non si imparano programmando in C semplicemente perché non interessano ad un programmatore C; possono essere utili a chi deve programmare il firmware della macchina o microprogrammare qualche integrato che la fa funzionare, ma per il programmatore finale della macchina hanno un'utilità marginale. Non così i principi generali del funzionamento di un computer.

Pensa te che culo.
E mi dici quanto occupa una struttura con 4 interi e un double in C? :)

Dipende dall'architettura. Si deve tenere conto della grandezza degli interi e dei double nel processore per il quale stai sviluppando. Nonché del compilatore che stai utilizzando che potrebbe inserire dei byte di padding all'interno della struttura. Sii più preciso e magari potrò aiutarti.

no, questa è la prima cosa che ti viene insegnata quando studi cose di un certo livello.
Ma, data la tua affermazione precedente, immagino che non hai un background molto profondo riguardo l'ottimizzazione e i profiler.
Ti consiglio qualche lettura sull'argomento soprattutto in ambito mobile dove le ottimizzazioni sono spesso essenziali e dove puoi trovare una vasta letteratura in merito :)

Ti faccio notare che supporre deficienze nelle competenze altrui può sembrare offensivo. Sicuramente è una caduta di stile. Possibilmente un errore.

Un buon codice è assolutamente slegato dalla conoscenza della macchina.

Scrivere codice portabile non significa scrivere con gli occhi bendati.

Citando a memoria: "Every fool can write a code that a machine can execute, only good programmers can write a code that other humans could understand".
Scrivere codice leggibile è molto + difficile che scrivere codice "performante".

Leggibilità ed efficienza sono due concetti distinti. Cmq io sono il primo ad ammettere che il codice C possa risultare scarsamente leggibile, soprattutto quando si abusa il preprocessore, ma non stavamo discutendo di questo.

Peccato che tutti si sentano geek o "hacker" quanto scrivono un paio di righe incomprensibili in c o in perl.. :doh:

Sono d'accordo. Io diffiderei direttamente di una persona che definisce se stesso "geek" o "hacker".

A che serve scrivere codice nativo non portabile nell'era dei JIT altamente efficienti e della portabilità/flessibilità?
Prova a fare in C/C++ quello che fai in java/C#.
Bene che ti vada scrivi 10 volte la quantità di codice necessaria.

Vero. E sicuramente i linguaggi nativi saranno usati sempre meno. E questa sarà una cosa buona per la qualità del software. Ma questo non significa che imparare il C++ sia un errore.

Ma anche no.
In quel caso molto meglio utilizzare CUDA, con cui scriverai solo una minima parte in C e poi sarai liberissimo di usare python.

Noto con piacere che queste minime parti in C stanno cominciando a saltare fuori un po' di qua e un po' di là. Sta a vedere che magari questo linguaggio servirà ancora a qualcosa :D .

Il C# si integra perfettamente con windows.

Ma anche no. Richiede l'installazione di 40 mega di software aggiuntivo solo per girare.

Il Java si integra perfettamente con linux, solaris, mac os x e windows.
Dove sarebbe la supposta superiorità del c++ in questo caso?

Java è un ottimo linguaggio. Ma se segui la scena del Java noterai che ci sono forti critiche da parte dei programmatori Java verso la Sun per quanto riguarda l'integrazione con gli ambienti "desktop". Ad esempio puoi leggere dei caratteri dalla console senza eco in Java? Puoi specificare un'icona personalizzata per la tua applicazione? Puoi cambiare lo sfondo del desktop con Java?

Può scegliere di farne a meno ogni volta che ci sia uno strumento migliore.
Un linguaggio è solo uno strumento, è questo che bisogna mettersi in testa.
Bisogna sempre utilizzare "the right tool for the right job" e non ha alcun senso difendere a spada tratta strumenti come il c / c++ se nel 90% dei casi ci sono strumenti migliori.

Sono in forte diminuzione i masochisti che utilizzano c++ :)
Per lo + sotto linux vedo che ancora sono in molti ad utilizzarlo, mentre sotto windows si preferisce di gran lunga il C#.

In questo siamo perfettamente d'accordo [anche se per motivi politici io preferiso il Java al C# :)]. Volevo solo farti notare ancora una volta come io non difendo a spada tratta il C: se vuoi apriamo un thread in cui ci divertiamo a spulciarne tutte le magagne. Però da qui a dire che imparare il C++ sia inutile o addirittura dannosa, ce ne corre.

cdimauro

18-07-2008, 15:08

Ti rispiego il mio punto precisando meglio. "Con un linguaggio di basso livello si possono scrivere una quantità ampia di applicazioni, senza incorrere in problemi che rendano la suddetta scrittura difficile o impossibile nei tempi e con le risorse mediamente disponibili al giorno d'oggi per la realizzazione di tali progetti." La fondatezza di tale affermazione è evidentemente documentata dal fatto che la stragrande maggioranza delle applicazioni oggi è, per qualche motivo, scritta in C (in UNIX) o in C++ (in UNIX e nel resto del mondo).

La tua risposta è che con l'assembler...?
La mia risposta era relativa alla tua precedente affermazione, non a questa tua nuova.

Quello che mi sfugge, però, è il motivo per cui tiri in ballo il concetto di produttività per l'assembly, mentre per C/C++ no.

Nessuno nega che con C/C++, rispetto all'assembly, sia più facile e richieda meno tempo lo sviluppo di un'applicazione "complessa". Ma lo stesso paragone lo posso fare se confronto C/C++ con linguaggi come Python, Ruby, Java, ecc.

Quindi la tua frase la posso riscrivere così: "Con un linguaggio di alto livello si possono scrivere una quantità ampia di applicazioni, senza incorrere in problemi che rendano la suddetta scrittura difficile o impossibile nei tempi e con le risorse mediamente disponibili al giorno d'oggi per la realizzazione di tali progetti."

Questo è il motivo per cui "oggi" (da un pezzo) si utilizzano linguaggi di più alto livello per sviluppare applicazioni, anziché C e C++.

L'evidenza di cui parli, infatti, rimane principalmente una questione di legacy, ed è tanto più vera quando riporti UNIX come esempio, che da sempre è un ambiente poco incline all'ammodernamento e che si è legato col cordone ombelicale al C e (molto meno) al C++ (quelli che si sono accorti che è un superset del C).
Tecnicamente parlando il C++ non è un superset proprio del C, nel senso che ci sono sorgenti C che non sono sorgenti validi C++ ;-) ma non discutiamo di questo.
So che ci sono delle incompatibilità (minime e perfettamente gestibili, tra l'altro), ma mi riferivo principalmente all'insieme di funzionalità.
Il fatto è che questi linguaggi (tipo il D), non hanno una comunità e un seguito sufficientemente larghi da giustificare l'abbandono del C++. Probabilmente perché il C++, con tutti i suoi - ripeto - TANTISSIMI difetti, non è poi un linguaggio così inutilizzabile.
Le due affermazioni non sono logicamente connesse. Se non usa il D è per i motivi sopraesposti. Idem se si preferisce il C al C++.

Perché è OGGETTIVO che un linguaggio come il D permette di essere più produttivo rispetto a C e C++, grazie ai comodi costrutti sintattici che offre.

Il motivo per cui non viene adottato non può certo essere rappresentato dalla scarsa produttività / inutilizzabilità, ma da quanto hai detto anche tu: la diffusione.
Supponiamo che io progetti una nuova architettura di elaborazione. Quale sarà il primo passo? OK, scrivere un assembler, ma il secondo? Sviluppare un compilatore C e una libreria standard. Dal momento in cui io ho disponibile un compilatore C (che oggi è di solito il gcc), ho a disposizione per la mia macchina un'IMMENSA quantità di software di qualità medio-alta a disposizione, alla quale dovrei rinunciare se scegliessi di usare un linguaggio esotico. Negli anni '80 nel mondo dei computer personali / per le piccole aziende, tale ruolo era svolto dall'interprete BASIC. E infatti a scuola si insegnava il BASIC, che era pieno di difetti. Oggi questo ruolo di "lingua franca" è svolto dal C/++, e per questo a scuola si insegna il C, con tutti i suoi difettacci.
Benissimo: oggi è tempo che questo ruolo sia passato a linguaggi ben più produttivi.

Quanto al resto: concordo, ma non fai che confermare ciò che affermo da un pezzo. Legacy. Il che non obbliga a continuare a sviluppare in C / C++. Tutt'altro, visto che c'è di meglio.
Intendi dire come il C++ :-D ?
:Puke:
Che in più ti costringe ad avere una maggiore conoscenza tecnica della macchina?
Conoscenza del tutto superflua per chi, da programmatore, ha il solo mandato di risolvere problemi.
Vuoi che ti presenti la lista dei programmi che uso su questa macchina e il linguaggio in cui sono scritti?
Continui a non capire o a non voler capire. LEGACY. Questo spiega tutto.

Se hai usato sistemi Unix-like, chiediti come mai per strumenti come per installer (Anaconda) o gestore dei pacchetti (YUM) è stato usato Python, visto che C e C++ "dominano"...
Codice che viene eseguito direttamente dal processore della macchina ospite.
In tal caso il C non c'entra niente: è il linguaggio macchina l'unico che può fregiarsi di questo titolo.
I processori hanno istruzioni e registri per supportare l'utilizzo di funzioni proprio come il C.
I processori hanno istruzioni e registri per supportare l'utilizzo di uno stack per il passaggio dei parametri e il mantenimento delle variabili locali proprio come richiesto dal C.
I processori vedono la memoria come una sequenza non-gestita di byte proprio come il C.
I processori hanno istruzioni e registri per supportare qualunque linguaggio di programmazione, non soltanto il C.
Questo è quello che puoi insegnare alla prima lezione introduttiva di un corso di informatica, ma poi devi scegliere un linguaggio del mondo reale da insegnare, a meno che non vuoi formare degli esperti che, finito il corso, non siano in grado di scrivere software per nessuna macchina reale.
Viene usato spesso lo pseudocodice. Secondo te per quale motivo?
La mia idea è che, potendo scegliere, ha un senso insegnare un linguaggio che non sia troppo distante dalla macchina, perché questo conferisce maggiore libertà di specializzazione a chi apprende. Ha un senso? Sì. E' l'unica scelta possibile? No.
Fortunatamente no, visto che un programmatore non dev'essere legato mani e piedi alla macchina.
Nel 1996 l'assembler non era più in uso da almeno sei anni. Nel 96 è uscito Quake, che fu famoso perché era scritto col gcc. La filosofia dei giochi dagli anni novanta in poi è stata di sviluppare il nocciolo del gioco in C o C++ e le routine critiche per le prestazioni (o di interfacciamento generale con l'hardware, che a quei tempi era diretto) in assembly.
Il compilatore più usato era il watcom c++, chiunque abbia usato giochi di quel periodo si ricorderà i messaggi del "dos/4gw" usato come ambiente operativo da quel compilatore.
Fino al '96 sono stati pubblicati giochi per Amiga scritti interamente in assembly. Su PC all'epoca c'erano già soluzioni ibride scritte in C/C++ o Turbo Pascal con diversi pezzi scritti in assembly per le parti critiche.

L'assembly, comunque, era ancora usatissimo, appunto.
Inutile dire che lo spostamento dei giochi dall'assembly al C al C++ ha coinciso con il crescere della complessità e profondità degli stessi - alley cat, presumibilmente scritto in assembly, non aveva certo la stessa complessità di duke nukem 3d, scritto in C.
Benissimo. Mi spieghi allora per quale motivo oggi si utilizzano estensivamente linguaggi come Python o LUA per i giochi?
Ad esempio, se programmi in C++ sai allocare e disallocare la memoria. Quando passi a Java, non hai più bisogno di saperlo fare perché c'è il garbage collector. Il contrario non è vero.
Se programmi in C++ sai gestire direttamente le stringhe manovrando i puntatori. Quando passi a Java, non hai più bisogno di saperlo fare perché ci sono le classi della libreria standard che ti aiutano. Il contrario non è vero.
L'allocazione e disallocazione delle risorse è un concetto che esiste in tutti i linguaggi di programmazione, Java incluso.

Mi puoi dire che per lo più è un aspetto che viene trascurato, vista la comodità offerta dal GC, ma non che non esista.
No, no, non parlo dell'insegnamento, intendo dire rimpiazzare il C++ del tutto, in modo che come conseguenza non sia più utile insegnarlo.
Il problema è la conseguenza logica con cui pretendi di legare l'uso di un linguaggio al suo insegnamento.

Ripeto: per imparare a programmare C e C++ sono tutt'altro che buone soluzioni.

Poi, semmai ti troverai ad affrontare problematiche che lo richiedano, nulla toglie che tu possa impararne la sintassi e sbatterci la testa.

Oggi l'uso di C e C++ è relegato a una NICCHIA di mercato per quanto riguarda lo sviluppo di applicazioni: perché li si dovrebbe preferire a linguaggi ben più produttivi? Meglio insegnare a programmare con linguaggi di questo tipo, no? Sono quelli con cui ti troverai a dover avere a che fare con più probabilità.
Semplice, perché dà la maggiore libertà a chi lo impara. Se impari il C++, impari a conoscere come funziona un computer ma per contro devi circumnavigare le deficienze di un linguaggio nato trent'anni fa come "assembler di alto livello". Solo che poi - come tu stesso affermi - sarai in grado di scrivere software per qualunque piattaforma esistente. E di comprendere il codice scritto da una grossissima fetta dei programmatori esistenti. E' questo il legame fra diffusione/disponibilità e convenienza dell'apprendimento. Io penso che la convenienza ci sia, tu pensi di no - ma è importante che chi ci legge possa scegliere.
Esattamente. Aggiungo che non è affatto vero che impari a conoscere come funziona un computer né tanto meno che riesci a scrivere applicazioni che girino su qualunque piattaforma (usando soltanto il linguaggio).

Esempio pratico: quant'è la dimensione di un int? E di un long? E la loro endianess?

Ci sono linguaggi che ti permettono di evitare del tutto problematiche di questo tipo, e sono sicuramente più portabili di equivalenti scritti in C o C++.

In soldoni, io se scrivo:
x = 4294967296
print x
Sono sicuro dell'output che verrà restituito su QUALUNQUE piattaforma.

Se scrivo:
int x = 4294967296;
printf("%d", x);
invece no, e non so nemmeno se compila correttamente.
E probabilmente faresti bene. L'imporante è che non giudichi arbitrariamente, come si faceva in questo thread, chi fa una scelta differente che comunque, come io ho spiegato, i suoi vantaggi ce l'ha.
Giudico perché ho specificato chiaramente i casi d'uso. Per mantenimento di codice legacy o per particolari applicazioni di sistema nulla da dire: al momento C++ (sicuramente non il C, perché non ha alcun senso continuare a utilizzarlo) e, meglio ancora, il D sono linguaggi che ricoprono questa nicchia di mercato.
Spiegami meglio. M'interessa perché potrei scoprire di avere una mentalità contorta :-D.
Semplice: perché ti forza alla programmazione strutturata. Una mentalità che è difficile rimuovere quando si passa a programmare a oggetti.
Già, senza farsi venire troppi sensi di colpa!
Più che altro se farà questa scelta avrà di che pentirsene.
quindi il C lo odi e il C++ ti piace?
Mai detto questo. Ho semplicemente detto che il C non ha motivo d'essere usanto quando esistono linguaggi che ne sono SUPERSET.

Poi, sia chiaro, a me non piacciono nemmeno C++ e D, e in generale i linguaggi con sintassi C-like.

EDIT. Ecco qui: http://directpython.sourceforge.net/ Chi l'avrebbe mai detto? :p

EDIT2. Mi chiamo Cesare!!!!!!

marco.r

18-07-2008, 15:19

Non è opportuno sapere che una soluzione recursiva è peggiore di una soluzione lineare?

non è necessariamente vero

^TiGeRShArK^

18-07-2008, 15:31

A parte che un boot loader si può tranquillamente scrivere in C, l'unica parte in cui avrei bisogno di usare l'assembly sarebbero le istruzioni privilegiate per mettere la CPU in modalità protetta. Poco fa tu avevi fatto sembrare che scrivere un sistema operativo in C fosse una cosa assurda, mentre già ora ammetti:

Io ritengo che queste situazioni che tu chiami molto particolari siano molto più vicine alla normalità. Confronta quanto ho detto a mauro.

Perchè sarebbero vicine alla normalità? :)
è normale scrivere un SO o lavorare su un dispositivo embedded?
io li chiamerei ambiti *di nicchia* in cui è giusto e sacrosanto che sia relegato il C oggi.

E' che se io affermo un concetto, debbo dire anche quali sono le ragioni della mia affermazione, altrimenti di cosa discutiamo? Se non lo faccio mi pare giusto (http://www.demauroparavia.it/7876) che la mia affermazione sia definita arbitraria.

Mi pare di aver spiegato piuttosto bene perchè il profiler è assolutamente necessario, ma se non ti fidi delle mie parole, puoi leggere un qualsiasi libro o un qualsiasi articolo sull'ottimizzazione del codice.
Per quanto riguarda quando detto da 71104 mi pare che lui abbia argomentato già di suo e ritenevo di non dover aggiungere altro.
Per quanto riguarda la prima osservazione mi pare anche lapalissiano che nel mondo del lavoro conti soprattuto la PRODUTTIVITA', e che linguaggi ad alto livello siano + produttivi di linguaggi a basso livello mi pare ovvio e scontato, non vedo cosa ci sia da dire in merito :)

Il fatto che in C++ non si perda poi così tanto tempo è testimoniato dal fatto che ancora la maggior parte dei programmatori lo usa. Per cui non è stupido insegnarlo, la mia affermazione è semplicemente questa.
A me non piace il C, e meno ancora il C++, però bisogna essere obbiettivi.

Chi sarebbe questa "maggior parte dei programmatori"?
Nelle aziende oggi come oggi, si usano essenzialmente Java e C#, o frose chi usa tali linguaggi non è degno di definirsi "programmatore"?

Padronissimi di farlo, mi hai sentito affermare che gli script non siano utili? Sei tu che affermi che il C++ è un qualcosa che viene usato solamente da individui oscurantisti e arretrati che per qualche motivo non vogliono imparare nuovi linguaggi.

Se lo si usa a sproposito, allora si.
Chiunque lo utilizzi avendo a disposizione strumenti migliori è solo un individuo oscurantista che non ha voglia di imparare un linguaggio nuovo.

Io per contrastare questa tua affermazione ti faccio notare nuovamente che posso indicarti un sito della microsoft dal quale scaricare l'sdk dell'ultima versione di directx per C++. Puoi fare lo stesso con il tuo linguaggio di scripting preferito?

XNA ti dice niente? :p
e se hai scaricato l'ultima versione delle Directx sdk, la 10, dovresti anche sapere che è inclusa la versione per .Net, e che quindi potresti potenzialmente usare anche con ironpython &co. :)

No, bollo come arbitrarie le affermazioni che non sono argomentate da parte tua in prima istanza. Affermazioni come questa:

Solo perché ci sono molte più aziende che progettano soluzioni di gestione di dati all'impresa piuttosto che aziende che scrivono software per uso personale. Quanti programmi usi tu tutti i giorni che /non siano/ scritti in C++?

Faccio prima a citarti quelli che uso che sono scritti in C++:
Firefox e Visual Studio.
Eclipse è scritto in java, netbeans idem, safari è basato su cocoa e sull'objective-c, open office è fortemente basato su java, mercury messenger è scritto in java, xcode in objective-c, IDLE è scritto in python, Mail in objective-c (anche se, se non erro, ha delle parti scritte con ruby-cocoa), ed essenzialmente mi pare basta.

Perché? Non è molto più facile imparare prima un linguaggio procedurale invece di cimentarsi di botto con le complessità dei linguaggi orientati agli oggetti?

Se si stesse parlando del BASIC non avrei nemeno tantissime obiezioni a parte quella che la mentalità procedurale ti corrompe la mente e che per imparare a programmare ad oggetti devi prima dimenticare quello che hai imparato fino a quel momento.
Ma dato che stiamo parlando di C, beh..
E' + facile che un cammello passi nella cruna di un ago che un programmatore alle prime armi non si becchi un mal di testa per cose completamente slegate al problema che deve risolvere :O

Uno impara prima il C, e poi passa al C++ quando è in grado di apprezzare le qualità della programmazione a oggetti.

si vabbè..
a quel punto si sarà già suicidato, oppure, bene che gli vada, scriverà spaghetti-code simil procedurale.

Qualcuno ti potrebbe dire che saper gestire una macchina è una parte importante della programmazione.

e, ripeto, non lo impari certo col C.
Per quello ci sono assembly e linguaggio macchina.
E su questo non credo ci sia altro da aggiungere.

Semplicemente utilizzando un linguaggio tu impari la "macchina virtuale" che te lo esegue.

che non ha alcuna attinenza con la macchina reale.

La "macchina C" è vicinissima alla macchina hardware, presenta come servizio aggiunto la possibilità di scrivere istruzioni più complesse e di utilizzare tipi di dati strutturati, per il resto il funzionamento della macchina rimane bene in vista come ho spiegato prima a mauro e come tu stesso hai affermato poco fa quando dicevi "ti concentri sulle bestemmie che devi indirizzare sul santo del giorno per il segmentation fault o il memory leak di turno".

Appunto.
Ti concentri sulla gestione della memoria del C, che è completamente slegata da quella del SO e da quella *REALE* della macchina.
A meno di non scrivere codice in kernel mode ovviamente, cosa che è raccomandata per tutti i programmatori alle prime armi.

Tutti i dettagli che mi hai prima elencato non si imparano programmando in C semplicemente perché non interessano ad un programmatore C; possono essere utili a chi deve programmare il firmware della macchina o microprogrammare qualche integrato che la fa funzionare, ma per il programmatore finale della macchina hanno un'utilità marginale. Non così i principi generali del funzionamento di un computer.

Ma è QUELLO il funzionamento della macchina REALE.
Con l'assembly impari i modi + efficienti per sfruttare appieno la macchina.
Con il C ti affidi semplicemente al compilatore che sa molto meglio di te come funziona la macchina e che ottimizza il codice nel modo + corretto.
Quindi tu non impari assolutamente nulla del funzionamento REALE.
E bada bene che non ti ho nominato lo schema elettrico o l'implementazione fisica di qualche parte del processore, ma ho solo citato delle parti che sono ESSENZIALI per scrivere un codice performante.
Ovviamente in assembly o in codice macchina, non certo in C.

Pensa te che culo.
E mi dici quanto occupa una struttura con 4 interi e un double in C? :)

Dipende dall'architettura. Si deve tenere conto della grandezza degli interi e dei double nel processore per il quale stai sviluppando. Nonché del compilatore che stai utilizzando che potrebbe inserire dei byte di padding all'interno della struttura. Sii più preciso e magari potrò aiutarti.

Appunto.
Volevo semplicemente evidenziare come con il C non sai nemmeno a priori quanto occupa il tipo di dato con cui hai a che fare.

no, questa è la prima cosa che ti viene insegnata quando studi cose di un certo livello.
Ma, data la tua affermazione precedente, immagino che non hai un background molto profondo riguardo l'ottimizzazione e i profiler.
Ti consiglio qualche lettura sull'argomento soprattutto in ambito mobile dove le ottimizzazioni sono spesso essenziali e dove puoi trovare una vasta letteratura in merito :)

Ti faccio notare che supporre deficienze nelle competenze altrui può sembrare offensivo. Sicuramente è una caduta di stile. Possibilmente un errore.

Beh, sinceramente nessuno che si sia mai trovato nella necessità di ottimizzare qualcosa oserebbe dire che "basta scrivere il codice bene" o "si capisce ad occhio dove ottimizzare", perchè sono cose che non stanno nè in cielo nè in terra e si scoprono sulla propria pelle in caso si persista su queste convinzioni anche in caso di necessità.
Il profiler è uno strumento ESSENZIALE e da molte hints su come ottimizzare il codice *nel modo corretto* e non solo nel modo che *il programmatore pensa sia corretto*.

Un buon codice è assolutamente slegato dalla conoscenza della macchina.

Scrivere codice portabile non significa scrivere con gli occhi bendati.

Può esistere codice potrtabile scritto con i piedi e codice non portabile che gira su una sola macchina che è scritto divinamente.
La portabilità non è un indice della qualità del codice.
La portabilità è solo un eventuale requisito fornitoci dal committente/datore di lavoro.
Allo stesso modo delle performance.

Citando a memoria: "Every fool can write a code that a machine can execute, only good programmers can write a code that other humans could understand".
Scrivere codice leggibile è molto + difficile che scrivere codice "performante".

Leggibilità ed efficienza sono due concetti distinti. Cmq io sono il primo ad ammettere che il codice C possa risultare scarsamente leggibile, soprattutto quando si abusa il preprocessore, ma non stavamo discutendo di questo.

La leggibilità, invece, è un parametro basilare per valutare la qualità di un codice.
Anche perchè il codice viene scritto una volta e letto MOLTE + volte.
Per quest'affermazione arbitraria chiedi la spiegazione a k0nt3 :p

Sono d'accordo. Io diffiderei direttamente di una persona che definisce se stesso "geek" o "hacker".

Vero. E sicuramente i linguaggi nativi saranno usati sempre meno. E questa sarà una cosa buona per la qualità del software. Ma questo non significa che imparare il C++ sia un errore.

Non ho mai detto che imparare il C++ sia un errore.
E' un errore gravissimo iniziare ad imparare la programmazione col C++.
Il C++ è uno strumento quindi di per sè non è nè buono nè cattivo.
Buono o cattivo è solo l'uso che se ne fa.
Apprenderlo per cultura personale o per necessità in caso non ci siano strumenti migliori è un ottimo uso.
Utilizzarlo per imparare la programmazione o al posto di strumenti migliori è un pessimo uso.

Noto con piacere che queste minime parti in C stanno cominciando a saltare fuori un po' di qua e un po' di là. Sta a vedere che magari questo linguaggio servirà ancora a qualcosa :D .

Come ancora oggi a volte servono minime parti di assembly.

Ma anche no. Richiede l'installazione di 40 mega di software aggiuntivo solo per girare.

Mai installato Windows Vista? :fagiano:
c'è il .net framework 3.0 incluso, quindi hai anche il supporto a linq.

Java è un ottimo linguaggio. Ma se segui la scena del Java noterai che ci sono forti critiche da parte dei programmatori Java verso la Sun per quanto riguarda l'integrazione con gli ambienti "desktop". Ad esempio puoi leggere dei caratteri dalla console senza eco in Java? Puoi specificare un'icona personalizzata per la tua applicazione? Puoi cambiare lo sfondo del desktop con Java?

Sinceramente quello era l'ultimo dei miei problemi....

In questo siamo perfettamente d'accordo [anche se per motivi politici io preferiso il Java al C# :)].

Lo preferivo anch'io prima dell'avvento di C# 3.0 e del Linq.

Volevo solo farti notare ancora una volta come io non difendo a spada tratta il C: se vuoi apriamo un thread in cui ci divertiamo a spulciarne tutte le magagne. Però da qui a dire che imparare il C++ sia inutile o addirittura dannosa, ce ne corre.
Dipende quando impari il c++ e per quale scopo.
Per il resto, ribadisco, ogni linguaggio è solo uno strumento e va utilizzato nel modo migliore.
Io non contesto il linguaggio ma l'uso scellerato che se ne fa.

Big Bamboo

18-07-2008, 16:20

Vincenzo1968

18-07-2008, 18:37

^TiGeRShArK^

18-07-2008, 18:45

http://db.apache.org/derby/
:fagiano:

variabilepippo

18-07-2008, 19:03

Onestamente, mi risulta difficile immaginare un DBMS implementato in Python, C# o Java.

Oltre al già citato Derby mi vengono in mente (in ordine sparso): JDataStore, HSQLDB, InstantDB, TurboDB, ...

Vincenzo1968

18-07-2008, 19:18

Intendevo dire DBMS che siano in grado di competere, in quanto a prestazioni, con quelli che ho citato.

Quando la microsoft migrerà SQL Server a C#(o Oracle/Java) allora mi ricrederò(e non mi si venga a dire che aziende come Microsoft non hanno le risorse necessarie(uomini e mezzi) per operare tale conversione in tempi ragionevoli).

:)

variabilepippo

18-07-2008, 19:30

Intendevo dire DBMS che siano in grado di competere, in quanto a prestazioni, con quelli che ho citato.

Io non ho numeri a portata di mano per confrontare le prestazioni dei vari DBMS, ed in vari contesti operativi, tu ne hai? :)

Quando la microsoft migrerà SQL Server a C#(o Oracle/Java) allora mi ricrederò(e non mi si venga a dire che aziende come Microsoft non hanno le risorse necessarie(uomini e mezzi) per operare tale conversione in tempi ragionevoli).

Sinceramente non vedo la necessità di investire tempo, risorse umane e finanziarie nel portare codice complesso, testato ed affidabile in un'altra tecnologia. Il discorso è analogo a quello fatto sulle DirectX, finora gli sviluppatori di giochi hanno usato quasi esclusivamente il C++, quindi era naturale che esempi e librerie fosse sviluppati in quel linguaggio. Non avrebbe senso buttare via tutto e passare di colpo a codice gestito, ma è quello che gradualmente sta avvenendo con XNA&Co... E se la cosa accade nel settore videoludico, quello più avido di risorse computazionali (a livello consumer), non vedo perché non debba valere anche per gli altri.

peppepz

18-07-2008, 19:47

La mia risposta era relativa alla tua precedente affermazione, non a questa tua nuova.

Non mi sembra di avere cambiato rispetto a

Perché è il tipo più generico di programmazione. In un linguaggio di basso livello puoi scrivere un'interfaccia utente, il firmware di un router, un sintetizzatore vocale, un handler di interrupt. Se impari solamente linguaggi di alto livello, ci saranno situazioni, quelle lontane dal "target" del linguaggio che stai utilizzando,in cui avrai difficoltà a procedere o non potrai procedere affatto.

Alla quale tu mi hai risposto dicendo che l'assembly è migliore.

Quello che mi sfugge, però, è il motivo per cui tiri in ballo il concetto di produttività per l'assembly, mentre per C/C++ no.

Perché...

Nessuno nega che con C/C++, rispetto all'assembly, sia più facile e richieda meno tempo lo sviluppo di un'applicazione "complessa".

Appunto. Solo che in questo thread si parlava dell'inopportunità di imparare il C++, che onestamente, mi pareva esagerata.

Ma lo stesso paragone lo posso fare se confronto C/C++ con linguaggi come Python, Ruby, Java, ecc.

Vero, sono d'accordo (anche se le differenze non sono così marcate). Ma io non ho mai affermato il contrario.

Quindi la tua frase la posso riscrivere così: "Con un linguaggio di alto livello si possono scrivere una quantità ampia di applicazioni, senza incorrere in problemi che rendano la suddetta scrittura difficile o impossibile nei tempi e con le risorse mediamente disponibili al giorno d'oggi per la realizzazione di tali progetti."

Questo è il motivo per cui "oggi" (da un pezzo) si utilizzano linguaggi di più alto livello per sviluppare applicazioni, anziché C e C++.

Ragazzi sono d'accordo con voi sul fatto che il C++ sia obsoleto - cacchio è obsoleto il Java che è nato nel '95! Solo che non sono d'accordo sul fatto che studiare il C++ fosse così assurdo, e mi pareva giusto fare sentire il mio parere a chi legge questo thread, magari non sapendo che linguaggio studiare.

In questo caso il linguaggio che utilizzo adesso è sicuramente un candidato ideale, visto che permette di utilizzare diversi paradigmi di programmazione.

Intendi dire come il C++ :-D ?

:Puke:

Molto sintetico ed efficace ma non altrettanto obbiettivo :-) .

Che in più ti costringe ad avere una maggiore conoscenza tecnica della macchina?

Conoscenza del tutto superflua per chi, da programmatore, ha il solo mandato di risolvere problemi.

Penso che su questo punto siamo irreversibilmente in disaccordo.

ad esempio, il fatto che la grande maggioranza dei programmi scritti oggi, /hic et nunc/, è scritta in C o in C++.

Questa statistica dove l'hai presa? Da parecchio tempo C e C++ NON sono i più utilizzati per lo sviluppo di nuove applicazioni. Tutt'altro.

Vuoi che ti presenti la lista dei programmi che uso su questa macchina e il linguaggio in cui sono scritti?

Continui a non capire o a non voler capire. LEGACY. Questo spiega tutto.

Che cosa non capisco? Tu semplicemente dicevi che C e C++ non sono i più utilizzati per lo sviluppo di nuove applicazioni, io ti ho detto che non è vero e come esempio lampante ti stavo per snocciolare tutti i programmi che utilizzo e il linguaggio in cui sono scritti. Tu dici che sono scritti così solo per "tradizione". E allora? Se C++ è ancora un linguaggio valido ed ha una tradizione così consolidata, perché non dovrebbe essere considerato uno strumento valido, anche se non più il migliore?

Se hai usato sistemi Unix-like, chiediti come mai per strumenti come per installer (Anaconda) o gestore dei pacchetti (YUM) è stato usato Python, visto che C e C++ "dominano"...

Perché la libreria standard del C fa schifo per la gestione dei file? :-D
Continui a dirmi che Python è un linguaggio stupendo quando io non ho mai affermato il contrario.

Solo che il C ha il seducente vantaggio di essere il linguaggio mondialmente più usato per scrivere codice nativo.

Cosa intendi per "codice nativo"?

Codice che viene eseguito direttamente dal processore della macchina ospite.

In tal caso il C non c'entra niente: è il linguaggio macchina l'unico che può fregiarsi di questo titolo.

Quando mai? Il compilatore C produce codice oggetto che gira direttamente sulla cpu target.

I processori attualmente in commercio eseguono codice "strutturato",

I processori eseguono sequenze di istruzioni condite da salti condizionati e non.

I processori hanno istruzioni e registri per supportare l'utilizzo di funzioni proprio come il C.
I processori hanno istruzioni e registri per supportare l'utilizzo di uno stack per il passaggio dei parametri e il mantenimento delle variabili locali proprio come richiesto dal C.
I processori vedono la memoria come una sequenza non-gestita di byte proprio come il C.

I processori hanno istruzioni e registri per supportare qualunque linguaggio di programmazione, non soltanto il C.

Non mi pare che esistano processori strutturati per eseguire linguaggi orientati agli oggetti! Tu ne conosci?

Questo è quello che puoi insegnare alla prima lezione introduttiva di un corso di informatica, ma poi devi scegliere un linguaggio del mondo reale da insegnare, a meno che non vuoi formare degli esperti che, finito il corso, non siano in grado di scrivere software per nessuna macchina reale.

Viene usato spesso lo pseudocodice. Secondo te per quale motivo?

Per spiegare concetti a persone che ancora non sanno programmare?

Fino al '96 sono stati pubblicati giochi per Amiga scritti interamente in assembly. Su PC all'epoca c'erano già soluzioni ibride scritte in C/C++ o Turbo Pascal con diversi pezzi scritti in assembly per le parti critiche.

Sei un amighista? Nel 96 immagino che usavate i powerpc. Grandioso il turbo pascal, peccato che avesse dei limiti - primo fra tutti, non creava file .obj da usare con un linker standard.

Benissimo. Mi spieghi allora per quale motivo oggi si utilizzano estensivamente linguaggi come Python o LUA per i giochi?

Perché sono linguaggi validi. Resta il fatto che il linguaggio usato principalmente per i giochi è il C++.

Un'ultima domanda: quale linguaggio credi possa rimpiazzare completamente il C++ nell'immediato futuro? In modo che si possa passare a insegnarlo nelle scuole senza retaggi di sorta?

Visto che parli d'insegnamento, la risposta è scontata, e puoi immaginare quale sia.

No, no, non parlo dell'insegnamento, intendo dire rimpiazzare il C++ del tutto, in modo che come conseguenza non sia più utile insegnarlo.

Il problema è la conseguenza logica con cui pretendi di legare l'uso di un linguaggio al suo insegnamento.

Ma quindi non me lo vuoi dire qual è questo linguaggio pronto per rimpiazzare il C++ in tutti i suoi aspetti? :D

Oggi l'uso di C e C++ è relegato a una NICCHIA di mercato per quanto riguarda lo sviluppo di applicazioni:

Non capisco dove trovi il fondamento quantitativo di questa affermazione. Io dico che C e C++ siano i principali strumenti per lo sviluppo di applicazioni /native/. Voi continuate a dirmi che non è così ma poi tutti i programmi in cui mi imbatto sono scritti in C++.

perché li si dovrebbe preferire a linguaggi ben più produttivi? Meglio insegnare a programmare con linguaggi di questo tipo, no? Sono quelli con cui ti troverai a dover avere a che fare con più probabilità.

Parzialmente d'accordo. In disaccordo quando dici che imparare il C sia inutile.

Aggiungo che non è affatto vero che impari a conoscere come funziona un computer

Anche su questo siamo definitivamente in disaccordo. Ai posteri l'ardua sentenza.

né tanto meno che riesci a scrivere applicazioni che girino su qualunque piattaforma (usando soltanto il linguaggio).

Esempio pratico: quant'è la dimensione di un int? E di un long? E la loro endianess?

Diventa un problema solo se scrivi codice che non tiene conto di queste differenze. :-D

Ci sono linguaggi che ti permettono di evitare del tutto problematiche di questo tipo, e sono sicuramente più portabili di equivalenti scritti in C o C++.

In soldoni, io se scrivo:
x = 4294967296
print x
Sono sicuro dell'output che verrà restituito su QUALUNQUE piattaforma.

Se scrivo:
int x = 4294967296;
printf("%d", x);
invece no, e non so nemmeno se compila correttamente.

Prova con

#include <stdint.h>

int64_t x = 4294967296ll;
printf("%09lld", x);

Compila sempre correttamente e ti stampa x sempre a 9 cifre aggiungendo zeri se serve.

Per imparare a programmare bene e con un certo criterio (leggi: senza entrare nella contorta tipica mentalità del programmatore C) il C non è assolutamente la scelta ideale.

Spiegami meglio. M'interessa perché potrei scoprire di avere una mentalità contorta :-D.

Semplice: perché ti forza alla programmazione strutturata. Una mentalità che è difficile rimuovere quando si passa a programmare a oggetti.

Io non ho avuto problemi, ho sempre pensato che gli oggetti erano record con i metodi :). Sì, ho imparato a programmare ad oggetti col pascal :-D .

EDIT2. Mi chiamo Cesare!!!!!!

Piacere peppe, perdona l'incomprensione :-D
Anzi scusa se a volte dò l'impressione di essere ottuso o saccente, io parto dal presupposto che voi vi divertiate quanto me a cercare di farmi cambiare idea ;-).

nico159

18-07-2008, 20:06

perché Linux è arretrato

in teoria anche su Linux esistono ambienti managed, anche su Linux esiste Java; però C# è più moderno (si parlava l'altro giorno di LINQ, no? ) e sto benedetto Java 7 non esce, quindi morale della favola il mondo di Linux è sempre indietro, come al solito

Guarda che su Linux puoi programmare in C#, come puoi farlo in Java, in Python, in D, in.. :cool:
Sei un pò fissato :mbe:

Vincenzo1968

18-07-2008, 20:14

Sinceramente non vedo la necessità di investire tempo, risorse umane e finanziarie nel portare codice complesso, testato ed affidabile in un'altra tecnologia. Il discorso è analogo a quello fatto sulle DirectX, finora gli sviluppatori di giochi hanno usato quasi esclusivamente il C++, quindi era naturale che esempi e librerie fosse sviluppati in quel linguaggio. Non avrebbe senso buttare via tutto e passare di colpo a codice gestito, ma è quello che gradualmente sta avvenendo con XNA&Co... E se la cosa accade nel settore videoludico, quello più avido di risorse computazionali (a livello consumer), non vedo perché non debba valere anche per gli altri.

Dunque, la Microsoft preferirebbe mantenere la versione scritta con un linguaggio vecchio di trent'anni e con tutti i difetti di cui s'è detto, solo perché non ne vale la pena?
Secondo me il motivo è un altro: efficienza. Quando si tratta di gestire file di grosse dimensioni, il linguaggio C è la scelta migliore. Ne ho avuto esperienza qui:

http://www.hwupgrade.it/forum/showthread.php?t=1779822

Io non ho numeri a portata di mano per confrontare le prestazioni dei vari DBMS, ed in vari contesti operativi, tu ne hai? :)

Possiamo verificarlo. Basta creare un programmino che inserisca, per esempio un milione di record nei database ed effettui qualche query sui dati. Prendiamo i tempi di esecuzione e li confrontiamo. Dei DBMS che hai citato, quale mi consigli di scaricare?

Ciao

^TiGeRShArK^

18-07-2008, 20:35

Guarda che su Linux puoi programmare in C#, come puoi farlo in Java, in Python, in D, in.. :cool:
Sei un pò fissato :mbe:

a settembre uscirà la versione 2.0 di mono che permetterà di usare anche qualche feature di .net 3.0...
Per ora ancora è piuttosto indietro...

shinya

18-07-2008, 20:42

Possiamo verificarlo. Basta creare un programmino che inserisca, per esempio un milione di record nei database ed effettui qualche query sui dati. Prendiamo i tempi di esecuzione e li confrontiamo. Dei DBMS che hai citato, quale mi consigli di scaricare?

Scusate se mi intrometto, ma questa non sarebbe una prova significativa di alcunchè. Engine diversi fanno cose diverse. Non puoi confrontare una insert (per dire) in Oracle e Derby (per dirne uno scritto in C e uno in Java), vedere che uno ci mette meno tempo e dire "è più perfomante!".

Molto probabilmente non stanno facendo le stesse cose. Ci sono troppi dettagli implementativi da tenere in conto che non c'entrano una mazza col linguaggio (gestione degli indici, foreign key, ecc...). I benchmark in questi casi sono una cosa delicata e da prendere con le molle.

E cmq il db in java migliore è H2 :) Love! Se volete una lettura istruttiva, ne consiglio i sorgenti!

^TiGeRShArK^

18-07-2008, 20:43

Dunque, la Microsoft preferirebbe mantenere la versione scritta con un linguaggio vecchio di trent'anni e con tutti i difetti di cui s'è detto, solo perché non ne vale la pena?
Secondo me il motivo è un altro: efficienza. Quando si tratta di gestire file di grosse dimensioni, il linguaggio C è la scelta migliore. Ne ho avuto esperienza qui:

http://www.hwupgrade.it/forum/showthread.php?t=1779822

Possiamo verificarlo. Basta creare un programmino che inserisca, per esempio un milione di record nei database ed effettui qualche query sui dati. Prendiamo i tempi di esecuzione e li confrontiamo. Dei DBMS che hai citato, quale mi consigli di scaricare?

Ciao

beh..
io da quel thread ho visto che il C comporta un aumento assurdo di linee di codice e in C# l'efficienza si può aumentare abbastanza agevolmente utilizzando un buon profiler e trovando i punti critici.
La cosa che mi sa che non consideri è che in un programma estremamente complesso come può essere oracle il punto critico non è dato dal linguaggio ma da n punti critici che ovviamente sono presenti e si sommano tra loro.
Personalmente se dovessi iniziare ora come ora a scrivere un DB non opterei certo per il C / C++, ma seguirei la strada intrapresa dai creatori degli ottimi DB citati da variabilepippo....

^TiGeRShArK^

18-07-2008, 20:46

Scusate se mi intrometto, ma questa non sarebbe una prova significativa di alcunchè. Engine diversi fanno cose diverse. Non puoi confrontare una insert (per dire) in Oracle e Derby (per dirne uno scritto in C e uno in Java), vedere che uno ci mette meno tempo e dire "è più perfomante!".

Molto probabilmente non stanno facendo le stesse cose. Ci sono troppi dettagli implementativi da tenere in conto che non c'entrano una mazza col linguaggio (gestione degli indici, foreign key, ecc...). I benchmark in questi casi sono una cosa delicata e da prendere con le molle.

E cmq il db in java migliore è H2 :) Love! Se volete una lettura istruttiva, ne consiglio i sorgenti!

infatti, tipo in questa slide h2 risulta + veloce di mysql e di postgreSQL..
http://www.h2database.com/html/images/performance.png

shinya

18-07-2008, 20:56

infatti, tipo in questa slide h2 risulta + veloce di mysql e di postgreSQL..

Beh H2 è effettivamente qualcosa di ben fatto, ma quei benchmark mi sembrano un pò tirati per i capelli...

variabilepippo

18-07-2008, 21:01

Dunque, la Microsoft preferirebbe mantenere la versione scritta con un linguaggio vecchio di trent'anni e con tutti i difetti di cui s'è detto, solo perché non ne vale la pena?

Certo, tra sviluppare nuove caratteristiche/migliorare quelle di un software esistente/fare ricerca e investire un tempo non trascurabile nel portare un DBMS da un linguaggio ad un altro per avere delle prestazioni *paragonabili*, ma perdendo in stabilità ed in sicurezza, solo un folle sceglierebbe la seconda opzione. E non credo che alla Microsoft, come in altre grandi realtà aziendali, ce ne siano molti di folli... ;)

Possiamo verificarlo. Basta creare un programmino che inserisca, per esempio un milione di record nei database ed effettui qualche query sui dati. Prendiamo i tempi di esecuzione e li confrontiamo.

Benjamin Disraeli diceva: "esistono tre tipi di menzogne, ossia le piccole bugie, le grandi bugie e la statistica". Con i benchmark puoi dimostrare tutto ed il contrario di tutto. Ricordo un benchmark (pubblicato da una società di consulenza "indipentente" da Microsoft) dal quale emergeva che VB6 era 3/4 volte più performante di C/C++! :muro:

Senza considerare che anche a parità di linguaggio usato esistono differenze sostanziali nelle prestazioni, proprio perché i DBMS fanno cose diverse ed in modo diverso.

Vincenzo1968

18-07-2008, 21:13

beh..
io da quel thread ho visto che il C comporta un aumento assurdo di linee di codice e in C# l'efficienza si può aumentare abbastanza agevolmente utilizzando un buon profiler e trovando i punti critici.
La cosa che mi sa che non consideri è che in un programma estremamente complesso come può essere oracle il punto critico non è dato dal linguaggio ma da n punti critici che ovviamente sono presenti e si sommano tra loro.
Personalmente se dovessi iniziare ora come ora a scrivere un DB non opterei certo per il C / C++, ma seguirei la strada intrapresa dai creatori degli ottimi DB citati da variabilepippo....

Guarda che si può ottimizzare anche la versione in C(per esempio, utilizzando un albero Red-Black o incorporando le chiamate alle funzioni per la gestione dell'albero, nella funzione DFA ;) ).

D'accordo, bisogna scrivere molto più codice. C# e Java, da questo punto di vista, sono le scelte migliori. Ma il parametro che stiamo considerando è la velocità di esecuzione, non la brevità del codice sorgente.

^TiGeRShArK^

18-07-2008, 21:17

Beh H2 è effettivamente qualcosa di ben fatto, ma quei benchmark mi sembrano un pò tirati per i capelli...

i benchmark sono sempre relativi...
Puoi mostrare tutto e il contrario di tutto..
soprattutto in un microbenchmark come quello nell'altro thread :p

Vincenzo1968

18-07-2008, 21:17

Scusate se mi intrometto, ma questa non sarebbe una prova significativa di alcunchè. Engine diversi fanno cose diverse. Non puoi confrontare una insert (per dire) in Oracle e Derby (per dirne uno scritto in C e uno in Java), vedere che uno ci mette meno tempo e dire "è più perfomante!".

Molto probabilmente non stanno facendo le stesse cose. Ci sono troppi dettagli implementativi da tenere in conto che non c'entrano una mazza col linguaggio (gestione degli indici, foreign key, ecc...). I benchmark in questi casi sono una cosa delicata e da prendere con le molle.

E cmq il db in java migliore è H2 :) Love! Se volete una lettura istruttiva, ne consiglio i sorgenti!

Ciao Shinya,

ti propongo una piccola sfida: scriviamo un programma per la gestione di una piccola base di dati. Per gli indici, direi di utilizzare i B+Tree, che è la tecnica maggiormente utilizzata dai vari DBMS(ma, se preferisci, indicane un'altra).
Alla fine confrontiamo i tempi di esecuzione. Prendiamoci tutto il tempo che vogliamo(una settimana, un mese, sei mesi).

Che ne dici? :)

^TiGeRShArK^

18-07-2008, 21:19

Guarda che si può ottimizzare anche la versione in C(per esempio, utilizzando un albero Red-Black o incorporando le chiamate alle funzioni per la gestione dell'albero nella funzione DFA ;) ).
ovvio, ma i microbenchmark lasciano il tempo che trovano imho...
Che C sia il + veloce in assoluto in una moltitudine di micro-benchmark nessuno lo mette in dubbio.
Ma che sia anche il + veloce in un applicazione estremamente complessa questo già è + opinabile.
Quello che è sicuro è invece l'enorme aumentare di linee di codice e di anni uomo per scrivere qualcosa di equivalente rispetto ad un linguaggio + semplice.
Con il tempo risparmiato si potrebbero scrivere penso almeno altre 2 - 3 applicazioni di tutto rispetto.. :stordita:

variabilepippo

18-07-2008, 21:23

i benchmark sono sempre relativi...
Puoi mostrare tutto e il contrario di tutto..

Peraltro è facilissimo dimostrare che un software può essere molto più veloce/lento di se stesso! Basta seguire/non seguire le guidelines, abilitare/non abilitare determinate caratteristiche, porsi o meno in un dato contesto operativo, scegliere di testare una particolare feature, ...

Per esempio riporto qualche dato preso dal sito di SQLite (http://www.sqlite.org/speed.html):

1000 INSERTs

PostgreSQL: 4.373
MySQL: 0.114
SQLite 2.7.6: 13.061
SQLite 2.7.6 (nosync): 0.223

A big INSERT after a big DELETE

PostgreSQL: 13.168
MySQL: 1.815
SQLite 2.7.6: 3.210
SQLite 2.7.6 (nosync): 1.485

25000 text UPDATEs with an index

PostgreSQL: 48.133
MySQL: 6.982
SQLite 2.7.6: 2.408
SQLite 2.7.6 (nosync): 1.725

Tutti sviluppati in C, qual è il più veloce? ;)

Vincenzo1968

18-07-2008, 21:31

Tutti sviluppati in C, qual è il più veloce? ;)

Propongo anche a te la sfida del mio post precedente.

Ciao ;)

Vincenzo1968

18-07-2008, 22:01

Se il moderatore è d'accordo, vorrei estendere la sfida a chiunque ne abbia voglia(e tempo ;) ).
Si potrebbe organizzare una sezione del forum come è stato fatto per il Progetto Diamonds.
Diamoci delle regole su come dev'essere organizzata la base di dati(una piccola, piccolissima base di dati e non, ovviamente, un DBMS completo). Ognuno posterà la propria soluzione, col linguaggio preferito, senza limiti di tempo(se tra un anno qualche nuovo utente volesse partecipare, sarebbe libero di farlo).

Che ne dite? :)

shinya

18-07-2008, 22:02

Ciao Shinya,

ti propongo una piccola sfida: scriviamo un programma per la gestione di una piccola base di dati. Per gli indici, direi di utilizzare i B+Tree, che è la tecnica maggiormente utilizzata dai vari DBMS(ma, se preferisci, indicane un'altra).
Alla fine confrontiamo i tempi di esecuzione. Prendiamoci tutto il tempo che vogliamo(una settimana, un mese, sei mesi).

Che ne dici? :)

No guarda, declino l'offerta.
Primo, perchè non ho tempo/voglia (e probabilmente capacità... quello che hai proposto non mi è molto chiaro nello specifico. Hai parlato di indici, ma un db è molto altro. C'è un parser sql, per dirne un'altra... e il parser di oracle NON fa le stesse cose del parser di derby).
Secondo, non mi interessa provare la forza di java o quel che è a dispetto del C. Anche perchè a me il C piace... sono solo intervenuto per dire che un benchmark di quel tipo non ha senso.

variabilepippo

18-07-2008, 22:10

Propongo anche a te la sfida del mio post precedente.

Scriviamo un software molto complesso e valutiamo:

1) I tempi di sviluppo
2) Il numero di LOC
3) Le prestazioni

???

Chiaramente un programmatore esperto può ottimizzare una funzione scrivendola in Assembly meglio di quanto possa fare un compilatore, ma non credo che lo stesso programmatore possa battere un compilatore su un codice C++ da 20kLOC (o più). Lo stesso paragone si può fare tra codice C e codice gestito. Una funzioncina da 20LOC può essere ottimizzata in tempi ragionevoli da un programmtore C, ma quando si passa dalla funzioncina "challenge" ad un software non banale dubito che le differenze prestazionali siano apprezzabili. :rolleyes:

Vincenzo1968

18-07-2008, 22:10

No guarda, declino l'offerta.
... Hai parlato di indici, ma un db è molto altro. C'è un parser sql, per dirne un'altra... e il parser di oracle NON fa le stesse cose del parser di derby).

Ok, come dicevo nel mio post precedente, non dobbiamo implementare un DBMS completo. Potrebbe bastare, per esempio, il database in un file binario, con un parser SQL(o, meglio, un sottoinsieme minimale del linguaggio SQL) e l'implementazione di indici tramite B+Tree o altro.

Rinnovo il mio invito al moderatore del post precedente.

Ciao :)

cdimauro

18-07-2008, 22:50

Il C non è utilizzato soltanto per sistemi operativi e compilatori. Laddóve ci sia bisogno di velocità di esecuzione, si utilizza il C(o il C++).
Penso ai DBMS, commerciali(SQL Server, Oracle) o open source(MySQL, PostgreSQL), ai programmi di grafica(Provate a scaricare i sorgenti di The Gimp e guardate con quale linguaggio è implementato ;) ).

Onestamente, mi risulta difficile immaginare un DBMS implementato in Python, C# o Java.

:)
Scarica questo http://www.getpaint.net/ e dimmi se ti sembra lento. ;)
Non mi sembra di avere cambiato rispetto a

Alla quale tu mi hai risposto dicendo che l'assembly è migliore.
Veramente avevo risposto con linguaggio macchina, ma va bene lo stesso. Comunque il motivo è questo:

Perché è il tipo più generico di programmazione.

e non è il C, appunto. ;)
Perché...

Appunto. Solo che in questo thread si parlava dell'inopportunità di imparare il C++, che onestamente, mi pareva esagerata.
E' inopportuno perché, come già detto, c'è di molto meglio per la stragrande maggioranza delle applicazioni che vengono sviluppate e con cui un programmatore generalmente si ritrova a lavorare.
Vero, sono d'accordo (anche se le differenze non sono così marcate). Ma io non ho mai affermato il contrario.
Le differenze in termini di produttività sono enormi, anche di un ordine di grandezza.
Ragazzi sono d'accordo con voi sul fatto che il C++ sia obsoleto - cacchio è obsoleto il Java che è nato nel '95! Solo che non sono d'accordo sul fatto che studiare il C++ fosse così assurdo, e mi pareva giusto fare sentire il mio parere a chi legge questo thread, magari non sapendo che linguaggio studiare.
Sì, l'abbiamo capito, e... personalmente non sono d'accordo. :D
Molto sintetico ed efficace ma non altrettanto obbiettivo :-) .
Vabbé, a parte i gusti personali, il C++ permette di utilizzare soltanto la programmazione strutturata e a oggetti.

Altri linguaggi hanno una maggior varietà, nonché semplicità e manutenibilità.
Penso che su questo punto siamo irreversibilmente in disaccordo.
Mi spiace, ma nessuno finora ha dimostrato che si tratta di concetti indispensabili, o anche lontamente utili, nella vita di tutti i giorni di un qualunque programmatore.

Fatta eccezione per particolari ambiti, come già ampiamente discusso.
Che cosa non capisco? Tu semplicemente dicevi che C e C++ non sono i più utilizzati per lo sviluppo di nuove applicazioni, io ti ho detto che non è vero e come esempio lampante ti stavo per snocciolare tutti i programmi che utilizzo e il linguaggio in cui sono scritti. Tu dici che sono scritti così solo per "tradizione". E allora? Se C++ è ancora un linguaggio valido ed ha una tradizione così consolidata, perché non dovrebbe essere considerato uno strumento valido, anche se non più il migliore?
Perché, come dicevo, c'è di molto meglio.
Perché la libreria standard del C fa schifo per la gestione dei file? :-D
Continui a dirmi che Python è un linguaggio stupendo quando io non ho mai affermato il contrario.
Non ho detto nulla su Python. Semplicemente ho cercato di farti notare che persino in ambiente Unix-like, dove impera il dogma del C = linguaggio da utilizzare (nemmeno il C++ va bene), qualcuno ha pensato bene di sviluppare quelle applicazioni usando Python. :cool:
Quando mai? Il compilatore C produce codice oggetto che gira direttamente sulla cpu target.
Questo non dipende dal linguaggio, ma dal compilatore.

Posso scrivere un compilatore C che... genera bytecode. Come pure posso scrivere anche un compilatore Python, Ruby, Java, che produce codice "nativo". Oltre, ovviamente, a soluzioni ibride (produzione di bytecode che viene trasformato al volo in codice "nativo").
Non mi pare che esistano processori strutturati per eseguire linguaggi orientati agli oggetti! Tu ne conosci?
Certamente: http://en.wikipedia.org/wiki/MAJC

Ma non è il solo esempio. Ecco qui http://www.arm.com/products/esd/jazelle_home.html l'estensione ideata da ARM per eseguire bytecode Java direttamente.

Lo stesso si potrebbe fare con la classica virtual machine Python o quella di .NET. ;)
Per spiegare concetti a persone che ancora non sanno programmare?
Appunto. Allora non sarebbe meglio utilizzare linguaggi che più si avvicinano allo pseudocodice per imparare a programmare? Uno "a caso" :D http://www.melbpc.org.au/pcupdate/2108/2108article9.htm :fiufiu:
Sei un amighista? Nel 96 immagino che usavate i powerpc.
Sì, sono un (ex) amighista. Nel '96 i Motorola dominavano ancora, ma c'era già qualche scheda acceleratrice PPC.
Grandioso il turbo pascal, peccato che avesse dei limiti - primo fra tutti, non creava file .obj da usare con un linker standard.
Mumble. E' passato troppo tempo, ma ricordo che era possibile generare file .obj utilizzabili da altri linguaggi.
Perché sono linguaggi validi. Resta il fatto che il linguaggio usato principalmente per i giochi è il C++.
Per adesso sì, ma la tendenza è quella di abbandonarlo. XNA, che è stato già nominato, non è nato per caso, e non è basato su C++... ;)
Ma quindi non me lo vuoi dire qual è questo linguaggio pronto per rimpiazzare il C++ in tutti i suoi aspetti? :D
In tutti no, ma in buona parte sì. E lo conosci già. :fiufiu:
Non capisco dove trovi il fondamento quantitativo di questa affermazione. Io dico che C e C++ siano i principali strumenti per lo sviluppo di applicazioni /native/. Voi continuate a dirmi che non è così ma poi tutti i programmi in cui mi imbatto sono scritti in C++.
La definizione di applicazioni "native" lascia il tempo che trova. Vedi sopra.

Sul fatto che ancora oggi tante applicazioni sono scritte in C o C++ mi sono già espresso. Altri hanno fatto degli esempi di applicazioni non scritte con questi linguaggi, ma molto diffuse.

Quanto al fondamento quantitivo non posso darti dati concreti. Personalmente non guardo al passato remoto, ma a quello recente e al presente: per progetti nuovi la scelta che, nella mia esperienza, va per la maggiore è quella di linguaggi di più alto livello.
Parzialmente d'accordo. In disaccordo quando dici che imparare il C sia inutile.
Lo è, perché molto difficilmente oggi ti capiterà di sbatterci la testa. Molto meglio imparare uno dei linguaggi più in voga e più produttivi, che non si sono diffusi certo per caso, nonostante il dominio del C.
Anche su questo siamo definitivamente in disaccordo. Ai posteri l'ardua sentenza.
C'è poco da aspettare: perfino il C nasconde dettagli di basso livello, e ti ho fatto anche qualche esempio pratico.
Diventa un problema solo se scrivi codice che non tiene conto di queste differenze. :-D
E dove sta la portabilità del C allora? :O
Prova con

#include <stdint.h>

int64_t x = 4294967296ll;
printf("%09lld", x);

Compila sempre correttamente e ti stampa x sempre a 9 cifre aggiungendo zeri se serve.
No, perché dipende dal compilatore (se non è C99-compliant).

Tra l'altro mi spieghi che fine ha fatto il tipo int, che avevo usato prima? :cool:
Io non ho avuto problemi, ho sempre pensato che gli oggetti erano record con i metodi :). Sì, ho imparato a programmare ad oggetti col pascal :-D .
Stessa "scuola" allora, ma io mi sono trascinato per un bel po' il retaggio della programmazione strutturata.
Piacere peppe, perdona l'incomprensione :-D
Non ti preoccupare: mi capita spesso di essere chiamato Mauro. :|
Anzi scusa se a volte dò l'impressione di essere ottuso o saccente, io parto dal presupposto che voi vi divertiate quanto me a cercare di farmi cambiare idea ;-).
Se non mi divertissi non scrivere nel forum. :D

Ma a volte prendo le discussioni troppo seriamente... :|

^TiGeRShArK^

19-07-2008, 02:37

Ok, come dicevo nel mio post precedente, non dobbiamo implementare un DBMS completo. Potrebbe bastare, per esempio, il database in un file binario, con un parser SQL(o, meglio, un sottoinsieme minimale del linguaggio SQL) e l'implementazione di indici tramite B+Tree o altro.

Rinnovo il mio invito al moderatore del post precedente.

Ciao :)

just imho, sarebbe meglio aprire una sezione di contest secondo quanto proposto da gugoxx, in modo da trovare gli algoritmi migliori, e non il linguaggio migliore che implementa un dato algoritmo, poichè penso che sia assodato che su un microbenchmark vincerebbe ovviamente il C (e se repne scasb [:ave: ]partecipasse al contest ovviamente vincerebbe l'assembly).
Imho è MOLTO + interessante spremere le meningi per trovare l'algoritmo con complessità computazionale minore piuttosto che trovare quale linguaggio esegue dei microbenchmark + velocemente rispetto ad un altro.
Comunque per aprire una nuova sezione non basta l'intervento di un moderatore ma bisognerebbe parlare con Davide (evidad) o con Ale (Bordin) oppure direttamente col grande capo il Corsini (caffè :O [:asd:]).
Almeno per quanto ricordi l'iter che abbiamo seguito per aprire la sezione "Diamonds" :p.
Detto ciò, aprire una sotto-sezione dedicata alla risoluzione di problemi mi pare un'ottima idea :D

peppepz

19-07-2008, 12:37

Perchè sarebbero vicine alla normalità? :)
è normale scrivere un SO o lavorare su un dispositivo embedded?
io li chiamerei ambiti *di nicchia* in cui è giusto e sacrosanto che sia relegato il C oggi.

Ma questo è quello che vuoi credere tu; non è affatto vero che il C++ oggi è relegato a scrivere sistemi operativi o software embedded, questa è un'affermazione della quale non vedo il fondamento. Una cosa è dire "/mi piacerebbe/ che il C++ venisse relegato agli ambiti in cui è strettamente necessario", e anche su questo ci sarebbe da discutere, scusa ma affermare che questa sia la realtà mi pare un po' mistificare.

Per quanto riguarda la prima osservazione mi pare anche lapalissiano che nel mondo del lavoro conti soprattuto la PRODUTTIVITA', e che linguaggi ad alto livello siano + produttivi di linguaggi a basso livello mi pare ovvio e scontato, non vedo cosa ci sia da dire in merito :)

Che nel mondo del lavoro contano pure le PRESTAZIONI, e visto che il C++ equipaggiato con un ambiente di sviluppo paragonabile a quello dei linguaggi più moderni, tipo Qt, ha una produttività affatto vicina a quella di suddetti linguaggi, però ha prestazioni quasi sempre superiori, oltre che una maggiore flessibilità, allora si capisce come mai il C++ sia tuttora largamente usato.

Chi sarebbe questa "maggior parte dei programmatori"?

Per esempio, tutti quelli che sviluppano un qualsiasi progetto per Unix. Per esempio, tutti quelli che sviluppano un qualsiasi progetto per Win32. Per esempio, tutti quelli che sviluppano un qualsiasi progetto per le MFC.

Nelle aziende oggi come oggi, si usano essenzialmente Java e C#, o frose chi usa tali linguaggi non è degno di definirsi "programmatore"?

Ancora una volta dipende dalle aziende dove lavori, e ancora una volta io non ho mai detto questo. Io stesso sono favorevole ad un progressivo allontanamento dal C++, e come potrei non esserlo? Quello di cui vorrei convincerti è che
1) questa cosa non avverrà nel prossimo futuro,
2) per come stanno le cose, /adesso/ lavorare in C++ ha i suoi vantaggi

[il C++]
Chiunque lo utilizzi avendo a disposizione strumenti migliori è solo un individuo oscurantista che non ha voglia di imparare un linguaggio nuovo.

O che ha bisogno che il suo codice giri con le migliori prestazioni possibili. O col minor numero di svantaggi per l'utente finale.

XNA ti dice niente? :p

Visto che parliamo di aziende, quanti giochi basati su XNA posso andare oggi nel negozio sotto casa e trovare sullo scaffale? E quanti scritti in, diciamo, C++ :D?

e se hai scaricato l'ultima versione delle Directx sdk, la 10, dovresti anche sapere che è inclusa la versione per .Net, e che quindi potresti potenzialmente usare anche con ironpython &co. :)

Sì ma la versione per .NET è inclusa perché le directx sono interfacce COM e quindi accessibili da .NET attraverso marshalling. A Microsoft non sarebbe costato nulla specificare per le DX10, visto che sono esclusive per vista, solamente un'interfaccia .NET, ed escludere così il C++ dai giochi una volta per tutte; ma per qualche motivo - evidentemente sono ancora pieni di dirigenti oscurantisti che non vogliono imparare un linguaggio nuovo ;-) - hanno scelto di lasciare il C++ come linguaggio primario per lo sviluppo ANCHE delle nuove applicazioni.

Faccio prima a citarti quelli che uso che sono scritti in C++:
Firefox e Visual Studio.
Eclipse è scritto in java, netbeans idem, safari è basato su cocoa e sull'objective-c, open office è fortemente basato su java, mercury messenger è scritto in java, xcode in objective-c, IDLE è scritto in python, Mail in objective-c (anche se, se non erro, ha delle parti scritte con ruby-cocoa), ed essenzialmente mi pare basta.

Giusto un paio di precisazioni: Eclipse non è scritto in puro Java ma usa le SWT che sono una libreria grafica nativa, proprio per avere migliore reattività dell'interfaccia utente (vagli a spiegare che non hanno saputo usare il profiler).
Safari è basato su WebKit che è in C++.
OpenOffice.org è scritto in C++ con piccole parti in Java (cfr. http://en.wikipedia.org/wiki/Openoffice#Java_controversy).

Ti concentri sulla gestione della memoria del C, che è completamente slegata da quella del SO e da quella *REALE* della macchina.

Veramente la visione della memoria del C mi pare identica a quella vista dalla macchina in usermode. Un array di byte. Ad esempio se il tuo processore non è in grado di accedere a determinati indirizzi (tipo quei RISC che hanno bisogno di allineamento) tale limitazione sarà perfettamente esposta in C.
Spiegami meglio le differenze.

E bada bene che non ti ho nominato lo schema elettrico o l'implementazione fisica di qualche parte del processore, ma ho solo citato delle parti che sono ESSENZIALI per scrivere un codice performante.
Ovviamente in assembly o in codice macchina, non certo in C.

Non vedo come! Mi puoi fare un esempio di codice qualsiasi che dipenda dall'implementazione del TLB? Che fra l'altro varia enormemente fra cpu e cpu?

Volevo semplicemente evidenziare come con il C non sai nemmeno a priori quanto occupa il tipo di dato con cui hai a che fare.

Ecco perché in C c'è sizeof(). E se ti interessa utilizzare interi di lunghezza prefissata, c'è <stdint.h> che è un toccasana per la portabilità.

Beh, sinceramente nessuno che si sia mai trovato nella necessità di ottimizzare qualcosa oserebbe dire che "basta scrivere il codice bene" o "si capisce ad occhio dove ottimizzare", perchè sono cose che non stanno nè in cielo nè in terra e si scoprono sulla propria pelle in caso si persista su queste convinzioni anche in caso di necessità.
Il profiler è uno strumento ESSENZIALE e da molte hints su come ottimizzare il codice *nel modo corretto* e non solo nel modo che *il programmatore pensa sia corretto*.

Ma perché io t'ho detto che "basta scrivere il codice bene" o "si vede a occhio"? L'ultima volta che l'ho usato io un profiler mi diceva semplicemente quanti millisecondi la cpu passava in ogni zona del codice, non mi diceva certo come dovevo fare per migliorare il programma: stava poi a me, con le mie conoscenze, ottimizzare l'algoritmo e ripassare dal profiler per verificare i risultati.

[java]
Lo preferivo anch'io prima dell'avvento di C# 3.0 e del Linq.

(offtopic)
Speriamo in questo java 7, va. Per ora non vedo molta luce. Se aggiungono al linguaggio le closure con la stessa filosofia con cui hanno aggiunto i generici, java rischia di diventare un pasticcio tipo C++.
Ancora mi si intrecciano i neuroni se cerco di capire che cacchio significa
class Enum<E extends Enum<E>>
:doh: .
(/offtopic)

Io non contesto il linguaggio ma l'uso scellerato che se ne fa.

OK!

^TiGeRShArK^

19-07-2008, 13:59

Ma questo è quello che vuoi credere tu; non è affatto vero che il C++ oggi è relegato a scrivere sistemi operativi o software embedded, questa è un'affermazione della quale non vedo il fondamento. Una cosa è dire "/mi piacerebbe/ che il C++ venisse relegato agli ambiti in cui è strettamente necessario", e anche su questo ci sarebbe da discutere, scusa ma affermare che questa sia la realtà mi pare un po' mistificare.

L'utilizzo + sensato per lo strumento c++, ad oggi, è quello che ho elencato prima.
Se poi lo si vuole utilizzare nel modo sbagliato, posso anche mettermi a scrivere qualsiasi cosa in C++ nonostante ci siano strumenti migliori per farlo.

Per quanto riguarda la prima osservazione mi pare anche lapalissiano che nel mondo del lavoro conti soprattuto la PRODUTTIVITA', e che linguaggi ad alto livello siano + produttivi di linguaggi a basso livello mi pare ovvio e scontato, non vedo cosa ci sia da dire in merito :)

Che nel mondo del lavoro contano pure le PRESTAZIONI, e visto che il C++ equipaggiato con un ambiente di sviluppo paragonabile a quello dei linguaggi più moderni, tipo Qt, ha una produttività affatto vicina a quella di suddetti linguaggi, però ha prestazioni quasi sempre superiori, oltre che una maggiore flessibilità, allora si capisce come mai il C++ sia tuttora largamente usato.

Solo in determinati ambienti contano le prestazioni.
Ad esempio, nei giochi, è utilizzato il C++ non per le sue maggiori prestazioni, ma perchè l'utilizzo di linguaggi con un garbage collector renderebbe non deterministica la latenza, requisito strettamente necessario in un gioco.
Da notare però che già ora si stanno muovendo i primi passi per superare questo scoglio mediante l'introduzione di XNA, basata su C# :p

Chi sarebbe questa "maggior parte dei programmatori"?

Per esempio, tutti quelli che sviluppano un qualsiasi progetto per Unix. Per esempio, tutti quelli che sviluppano un qualsiasi progetto per Win32. Per esempio, tutti quelli che sviluppano un qualsiasi progetto per le MFC.

Nel 90% dei casi ci sono strumenti migliori per fare quello che stanno facendo.
E ocmunque "Early optimization is the root of all evils" e per me nell'ottimizzazione precoce rientra a pieno titolo anche la scelta di un linguaggio solo per le maggiori prestazioni.
Ovviamente ci sono ambiti dove le prestazioni sono ESSENZIALI e utilizzare un linguaggio dinamico o un garbage collector è improponibile, ma nella maggior parte dei casi non è assolutamente necessario l'uso del C/C++.

Nelle aziende oggi come oggi, si usano essenzialmente Java e C#, o frose chi usa tali linguaggi non è degno di definirsi "programmatore"?

Ancora una volta dipende dalle aziende dove lavori, e ancora una volta io non ho mai detto questo. Io stesso sono favorevole ad un progressivo allontanamento dal C++, e come potrei non esserlo? Quello di cui vorrei convincerti è che
1) questa cosa non avverrà nel prossimo futuro,
2) per come stanno le cose, /adesso/ lavorare in C++ ha i suoi vantaggi

Nel prossimo futuro non potrà avvenire dato che c'è l'inerzia dovuta all'enorme quantità di codice scritto in quei linguaggi ad oggi esistente.
Lavorare in C++ ad oggi ha i suo vantaggi solo quando non ci sono strumenti migliori, e, vista l'abbondanza di strumenti a disposizione, non mi pare che siano moltissimi i casi in cui è vantaggioso usare il c++.

O che ha bisogno che il suo codice giri con le migliori prestazioni possibili. O col minor numero di svantaggi per l'utente finale.

Con l'utilizzo del C/C++ si hanno sempre svantaggi per l'utente finale in termini di features in meno che non è possibile aggiungere per vincoli di tempo rispetto all'utilizzo di un linguaggio + produttivo.
Ovviamente anche qui dipende strettamente dall'ambito in cui si lavora perchè, ad esempio, potrebbe essere + conveniente utilizzare C++ al posto di Java Real Time o viceversa, a seconda del dominio del problema da affrontare...

Visto che parliamo di aziende, quanti giochi basati su XNA posso andare oggi nel negozio sotto casa e trovare sullo scaffale? E quanti scritti in, diciamo, C++ :D?

Infatti ho detto che si stanno muovendo i primi passi in questa direzione :p
E ho anche spiegato il motivo per cui ad oggi è necessario il C++ nei giochi che NON è un motivo prestazionale, ma dipende dal determinismo della latenza che è un requisito essenziale.

Sì ma la versione per .NET è inclusa perché le directx sono interfacce COM e quindi accessibili da .NET attraverso marshalling. A Microsoft non sarebbe costato nulla specificare per le DX10, visto che sono esclusive per vista, solamente un'interfaccia .NET, ed escludere così il C++ dai giochi una volta per tutte; ma per qualche motivo - evidentemente sono ancora pieni di dirigenti oscurantisti che non vogliono imparare un linguaggio nuovo ;-) - hanno scelto di lasciare il C++ come linguaggio primario per lo sviluppo ANCHE delle nuove applicazioni.

vedi sopra.

Giusto un paio di precisazioni: Eclipse non è scritto in puro Java ma usa le SWT che sono una libreria grafica nativa, proprio per avere migliore reattività dell'interfaccia utente (vagli a spiegare che non hanno saputo usare il profiler).

Perchè ai tempi le swing erano poco ottimizzate.
Dalla jdk 6 invece hanno scritto molte + funzioni accelerando direttamente con la scheda video e, se non sbaglio, dovrebbero avere abilitato sulle macchine windows il rendering path in direct x di default, al posto di quello open gl che era utilizzato prima.
E questo influisce abbastanza sulle prestazioni, soprattutto per chi aveva schede ati vecchiotte con i driver open gl dei tempi che obiettivamente facevano cacare :p

Safari è basato su WebKit che è in C++.
OpenOffice.org è scritto in C++ con piccole parti in Java (cfr. http://en.wikipedia.org/wiki/Openoffice#Java_controversy).

Infatti rientra perfettamente nella filosofia "the right tool for the right job" :)
Comunque anche safari credo che abbia parti scritte in objective-c dato che è possibile chiamare direttamente da javascript dei metodi objective-c:
http://developer.apple.com/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/ObjCFromJavaScript.html

Veramente la visione della memoria del C mi pare identica a quella vista dalla macchina in usermode. Un array di byte. Ad esempio se il tuo processore non è in grado di accedere a determinati indirizzi (tipo quei RISC che hanno bisogno di allineamento) tale limitazione sarà perfettamente esposta in C.
Spiegami meglio le differenze.

Non vedi la paginazione, la memoria virtuale e cose del genere.
Se la tua applicazione sfrutta pesantemente la memoria sono cose che è bene conoscere.
Come era essenziale sapere che abilitando PAE, quando ancora non erano presenti architetture basata su x86-64 nel mondo x86, e accedendo a pagine che erano disposte "da una parte e dall'altra" del limite di memoria fisica (semplificando) si avevano ENORMI decadimenti prestazionali...

Non vedo come! Mi puoi fare un esempio di codice qualsiasi che dipenda dall'implementazione del TLB? Che fra l'altro varia enormemente fra cpu e cpu?

LA dimensione della cache e la sua associatività ad esempio è essenziale per definire il blocco di dati su cui lavorare, soprattutto per applicazioni che devono analizzare "batch" di dati, come le applicazioni di codifica di flusso video o le applicazioni di rendering.
Lo stesso dicasi per quanto riguarda la conoscenza del numero di registri interi e SSE.
Ma sono cose che puoi utilizzare scrivendo direttamente in assembly.
A livello di C te le dimentichi completamente questo tipo di ottimizzazioni, che saranno demandate al compilatore.

Ecco perché in C c'è sizeof(). E se ti interessa utilizzare interi di lunghezza prefissata, c'è <stdint.h> che è un toccasana per la portabilità.

Per me è assurdo avere dimensioni di dati diverse che cambiano da un'architettura ad un'altra.
E' completamente anti-intuitivo.
Ha il suo senso in assembly, ma in un linguaggio che *dovrebbe* essere ad alto livello non ha alcun senso...

Ma perché io t'ho detto che "basta scrivere il codice bene" o "si vede a occhio"? L'ultima volta che l'ho usato io un profiler mi diceva semplicemente quanti millisecondi la cpu passava in ogni zona del codice, non mi diceva certo come dovevo fare per migliorare il programma: stava poi a me, con le mie conoscenze, ottimizzare l'algoritmo e ripassare dal profiler per verificare i risultati.

Il profiler evidenzia le parti critiche del codice..
Di solito la "rule of thumb" è che il 99% dei problemi prestazionali stanno nell'1% del codice.
E il profiler ti mostra inequivocabilmente qual'è il collo di bottiglia (o i colli di bottiglia) del tuo software.
E tutto questo senza fare supposizioni o senza scrivere una parte di codice (che magari poi viene chiamata solo un migliaio di volte) in assembly per ottimizzare.

(offtopic)
Speriamo in questo java 7, va. Per ora non vedo molta luce. Se aggiungono al linguaggio le closure con la stessa filosofia con cui hanno aggiunto i generici, java rischia di diventare un pasticcio tipo C++.
Ancora mi si intrecciano i neuroni se cerco di capire che cacchio significa
class Enum<E extends Enum<E>>
:doh: .
(/offtopic)

OK!
Infatti per ora sono passato a C# (anche se ogni tanto qualcosina la scrivo ancora in java) e sinceramente mi sto trovando MOLTO meglio da quando sto usando Linq :p

sasyultrasnapoli

19-07-2008, 21:08

:help: :help: :help:

Fate paura quando vi mettere a quotare :stordita:

peppepz

19-07-2008, 21:45

L'utilizzo + sensato per lo strumento c++, ad oggi, è quello che ho elencato prima.
Se poi lo si vuole utilizzare nel modo sbagliato, posso anche mettermi a scrivere qualsiasi cosa in C++ nonostante ci siano strumenti migliori per farlo.

Ok mi può andare anche bene, è un grandissimo miglioramento rispetto a quando dicevi che il C++ non è adatto per fare niente, non è usato quasi da nessuno ed è un linguaggio di nicchia.

Solo in determinati ambienti contano le prestazioni.

Immagino molti di quelli in cui le risorse si pagano :D .

Ad esempio, nei giochi, è utilizzato il C++ non per le sue maggiori prestazioni, ma perchè l'utilizzo di linguaggi con un garbage collector renderebbe non deterministica la latenza, requisito strettamente necessario in un gioco.

Ed ecco che salta fuori un altro ambito dove il C++ si può usare. Vedi che questa nicchia la stiamo piano piano ampliando ;).

Con l'utilizzo del C/C++ si hanno sempre svantaggi per l'utente finale in termini di features in meno che non è possibile aggiungere per vincoli di tempo rispetto all'utilizzo di un linguaggio + produttivo.

Forse questo può succedere se confronti il C "liscio" con le ricche librerie standard fornite dagli altri linguaggi. Ma a voler fare un confronto più onesto si potrebbe fare riferimento ad una piattaforma di sviluppo C++ più ricca, tipo Qt o MFC, e in questo caso il divario di produttività sarebbe affievolito.
Mentre l'utente finale quando si sceglie qualcosa di diverso dal C si trova ad avere a che fare con scocciature provenienti dai limiti della piattaforma "esotica" utilizzata - ad esempio in Java non si possono creare link simbolici, e così via.

Non vedi la paginazione, la memoria virtuale e cose del genere.

Vabbe' perché no? Se scrivi codice usermode non le vedi al pari di come non le vedresti con un programma in assembly. Se scrivi codice kernelmode le vedi come le vedresti con un programma in assembly. La visione mi pare fondamentalmente la stessa, era di questo che discutevamo.

La dimensione della cache e la sua associatività ad esempio è essenziale per definire il blocco di dati su cui lavorare, soprattutto per applicazioni che devono analizzare "batch" di dati, come le applicazioni di codifica di flusso video o le applicazioni di rendering.
Lo stesso dicasi per quanto riguarda la conoscenza del numero di registri interi e SSE.
Ma sono cose che puoi utilizzare scrivendo direttamente in assembly.
A livello di C te le dimentichi completamente questo tipo di ottimizzazioni, che saranno demandate al compilatore.

La conoscenza della dimensione della cache e la sua associatività le puoi sfruttare anche dal C - visto che gestisci direttamente la memoria.
La conoscenza del numero di registri interi e SSE onestamente non mi pare che sia molto utile per il programmatore - il compilatore sicuramente può fare un lavoro migliore di lui nello sfruttarli, anzi a volte con i processori moderni sotto il compilatore ci si mette anche la CPU con register renaming e altre finezze. E cmq il C è l'unico linguaggio che conosco che ti consente di "consigliare" al compilatore quali variabili mettere nei registri, con la parola chiave register. Mi pare che tutto questo confermi il fatto che con il C "si vede" come funzioni la macchina.

Per me è assurdo avere dimensioni di dati diverse che cambiano da un'architettura ad un'altra.

Già. Ma è quello che succede quando un linguaggio attraversa un periodo di vita di trent'anni, che informaticamente sono un'EONE, passando da mainframe a 36 bit :) attraverso home computer a 16 bit e PIC a 12 bit fino a console di gioco a 64 bit.
Guarda per confronto cosa è successo a Java in questi 10 anni: come dici tu,

E' completamente anti-intuitivo.

come i generici type-erased di Java. "Cicatrici di guerra" dei linguaggi di programmazione :D .

alderighi

20-07-2008, 22:26

Lunga vita al C e al C++, chi li disprezza in genere sono programmatori che hanno imparato a programmare all'università e che hanno poca esperienza alle spalle. Quello che puoi fare in Java lo puoi fare anche in C++, quello che puoi fare in C++ non lo puoi fare in Java.
D'altra parte se la maggior parte dei programmi più impostanti sono scritti in C++ ci sarà un motivo.
Poi chi si lamenta e dice che il Java è più facile non lo capisco proprio visto che i due linguaggi si assomigliano molto.

||ElChE||88

20-07-2008, 22:52

Lunga vita al C e al C++, chi li disprezza in genere sono programmatori che hanno imparato a programmare all'università
Vero, studentelli sbarbati tipo cdimauro che non hanno esperienza alcuna... :)

:doh:

marko.fatto

20-07-2008, 22:52

don't feed the troll!? :asd:

shinya

20-07-2008, 22:53

cdimauro

20-07-2008, 22:58

don't feed the troll!? :asd:
Ma nemmeno gli rispondo, altrimenti è la volta buona che i moderatori mi sospendono... :D

71104

21-07-2008, 10:44

a settembre uscirà la versione 2.0 di mono che permetterà di usare anche qualche feature di .net 3.0...
Per ora ancora è piuttosto indietro... mono per definizione è sempre indietro: è una copiatura, come fanno a copiare cose che ancora non sono uscite? prima devono aspettare che escano, poi devono spendere un sacco di tempo per documentarsi a dovere, poi devono implementare, e poi devono testare. nel frattempo chissà cos'altro hanno introdotto nell'originale.

71104

21-07-2008, 10:47

71104

21-07-2008, 10:53

[...] Che ne dici? :)
che leggendo la tua firma mi chiedo se tu ritenga di essere un cretino intelligente o un intelligente cretino :asd:
hai mai considerato l'ipotesi di essere un cretino cretino? :D

^TiGeRShArK^

21-07-2008, 13:27

Ok mi può andare anche bene, è un grandissimo miglioramento rispetto a quando dicevi che il C++ non è adatto per fare niente, non è usato quasi da nessuno ed è un linguaggio di nicchia.

veramente io questo non l'ho mai detto.
Invece eri tu che sostenevi che il C è la programmazione "+ generica" e con cui puoi fare tutto.
E io ti ho semplicemente dimostrato come è semplicemente folle scrivere tutto in C quando hai strumenti infinitamente migliori. :)

Immagino molti di quelli in cui le risorse si pagano :D .

No.
Solo negli ambienti in cui le risorse sono LIMITATE e non è possibile ampliarle, non certo in quelli in cui si pagano.
Al giorno d'oggi il costo di un upgrade di velocità è + basso anche di quello di un solo mese/uomo.

Ed ecco che salta fuori un altro ambito dove il C++ si può usare. Vedi che questa nicchia la stiamo piano piano ampliando ;).

Il C++ ha la sua utilità in determinati ambiti, l'ho sempre detto che si deve usare lo strumento giusto per ciascun lavoro.
Sei tu che sostenevi la maggior "genericità" del C, concetto assolutamente errato :)

Forse questo può succedere se confronti il C "liscio" con le ricche librerie standard fornite dagli altri linguaggi. Ma a voler fare un confronto più onesto si potrebbe fare riferimento ad una piattaforma di sviluppo C++ più ricca, tipo Qt o MFC, e in questo caso il divario di produttività sarebbe affievolito.
Mentre l'utente finale quando si sceglie qualcosa di diverso dal C si trova ad avere a che fare con scocciature provenienti dai limiti della piattaforma "esotica" utilizzata - ad esempio in Java non si possono creare link simbolici, e così via.

Puoi usare tutte le librerie che vuoi, ma la quantità di LOC media per il C/C++ e la quantità media di errori è MOLTO + elevata rispetto ad altri linguaggi.
E una parte ENORME del tempo di sviluppo se ne va nella fase di debug.

Vabbe' perché no? Se scrivi codice usermode non le vedi al pari di come non le vedresti con un programma in assembly. Se scrivi codice kernelmode le vedi come le vedresti con un programma in assembly. La visione mi pare fondamentalmente la stessa, era di questo che discutevamo.

Sbaglio o è dai tempi del 386 che è possibile usare la paginazione? :mbe:
e il memory model del C non è basato sulla segmentazione, o ricordo male?

La conoscenza della dimensione della cache e la sua associatività le puoi sfruttare anche dal C - visto che gestisci direttamente la memoria.
La conoscenza del numero di registri interi e SSE onestamente non mi pare che sia molto utile per il programmatore - il compilatore sicuramente può fare un lavoro migliore di lui nello sfruttarli, anzi a volte con i processori moderni sotto il compilatore ci si mette anche la CPU con register renaming e altre finezze. E cmq il C è l'unico linguaggio che conosco che ti consente di "consigliare" al compilatore quali variabili mettere nei registri, con la parola chiave register. Mi pare che tutto questo confermi il fatto che con il C "si vede" come funzioni la macchina.

No, perchè non hai il diretto controllo sulla macchina che avresti con l'asembly :)
E' il compilatore che maschera tutto e, anche per la cache, in teoria potrebbe introdurre ottimizzazioni che sballano completamente i tuoi piani.
Che poi in media sia + efficiente di un programmatore medio assembly nessuno lo mette in dubbio.
Però non puoi dire di avere il controllo completo della macchina in c (cosa che tra l'altro ritengo perfettamente inutile nel 2008).

Già. Ma è quello che succede quando un linguaggio attraversa un periodo di vita di trent'anni, che informaticamente sono un'EONE, passando da mainframe a 36 bit :) attraverso home computer a 16 bit e PIC a 12 bit fino a console di gioco a 64 bit.
Guarda per confronto cosa è successo a Java in questi 10 anni: come dici tu,

come i generici type-erased di Java. "Cicatrici di guerra" dei linguaggi di programmazione :D .
Appunto.
E' anche giusto che un linguaggio così vecchio lasci la scena a linguaggi + moderni. :)

^TiGeRShArK^

21-07-2008, 13:37

banryu79

21-07-2008, 14:11

detto da uno che ha scritto nel profilo "studente" come professione è tutto dire :asd:
lollissima questa :D

peppepz

21-07-2008, 15:28

veramente io questo non l'ho mai detto.
Invece eri tu che sostenevi che il C è la programmazione "+ generica" e con cui puoi fare tutto.
E io ti ho semplicemente dimostrato come è semplicemente folle scrivere tutto in C quando hai strumenti infinitamente migliori. :)

Ma non mi hai dimostrato che con qualche altro linguaggio si può fare tutto quello che si può fare in C. Probabilmente si possono fare /meglio/ tante cose, ma non tutto quello che si può fare in C. Per questo continuo imperterrito a ritenere che la programmazione in C sia più generica - quantomeno rispetto a qualsiasi altro tipo di programmazione mi sia stata portata ad esempio in questo thread. E ad attendere esempi del contrario.

Il C++ ha la sua utilità in determinati ambiti, l'ho sempre detto che si deve usare lo strumento giusto per ciascun lavoro.
Sei tu che sostenevi la maggior "genericità" del C, concetto assolutamente errato :)

In your not so humble opinion. Io non sono d'accordo e se la memoria non m'inganna ne ho portato esempi.

Puoi usare tutte le librerie che vuoi, ma la quantità di LOC media per il C/C++ e la quantità media di errori è MOLTO + elevata rispetto ad altri linguaggi.
E una parte ENORME del tempo di sviluppo se ne va nella fase di debug.

Dici? Alla fine se si usano solo costrutti di alto livello la sintassi del C++ è praticamente uguale a quella di Java e C#, e in fondo c'è così tanta differenza fra un'eccezione non gestita ed un errore di protezione?

Sbaglio o è dai tempi del 386 che è possibile usare la paginazione? :mbe:
e il memory model del C non è basato sulla segmentazione, o ricordo male?

No, il modello di memoria del C è lineare (dato che gli interi si possono castare a puntatori). Anche se nel corso della storia i compilatori per architetture segmentate (tipo DOS reale e modalità protetta a 16 bit) sono stati estesi con macro e funzioni specifiche per gestire la segmentazione (ti ricordi i "memory model" dei compilatori per DOS, tipo tiny, huge, etc. :-P).
[Comunque non ho mai visto un'implementazione a 32 bit che facesse uso dei segmenti. Questa parte dell'architettura Intel è stata snobbata da qualsiasi sistema operativo che conosca. E probabilmente è stato meglio così :-D .]

No, perchè non hai il diretto controllo sulla macchina che avresti con l'asembly :)
E' il compilatore che maschera tutto e, anche per la cache, in teoria potrebbe introdurre ottimizzazioni che sballano completamente i tuoi piani.

Il compilatore trasforma le mie istruzioni in assembly, non capisco quali ottimizzazioni potrebbe introdurre dietro la mia schiena che possano farmi cambiare addirittura il modo in cui vedo la macchina. Al massimo può eliminare qualche istruzione inutile o qualche controllo ridondante, ma se io faccio

*(char *) 0x80001234 = 3;

metto un 3 nell'indirizzo di memoria $80001234, qualsiasi cosa ne possa pensare il compilatore.

Aggiungo che con il C, proprio per la fisicità dei puntatori, posso sfruttare direttamente la paginazione con funzioni come mmap() per ottenere prestazioni altissime, anche in applicazioni moderne e di alto livello.

Però non puoi dire di avere il controllo completo della macchina in c (cosa che tra l'altro ritengo perfettamente inutile nel 2008).

Non sarà completo, ma è - istruzioni speciali a parte - lo stesso che puoi ottenere in assembly. E quanto al fatto che sia inutile, probabilmente lo è, ma io non credo che un programmatore si possa definire completo se non è in grado di controllare - o per lo meno avere una vaga idea di come si faccia - una generica macchina.

sottovento

21-07-2008, 15:49

Ciao a tutti, volevo chiedere i vostri pareri di esperti sul futuro del linguaggio C(non C++).

Guardando i sorgenti di molti programmi open source la maggior parte sono scritti in C++(molti utilizzano le qt) e ora sta venendo fuori anche python.

Voi che ne dite?

Ciao,
il mio parere e' un po' discordante: penso che ci sia ancora tanto spazio per il linguaggio C, soprattutto perche':
- esiste un compilatore per praticamente tutti i processori. Questo non e' vero per nessun altro linguaggio;
- scrivi codice compatto;
- puoi scrivere codice anche per processori, per esempio, a 4 bit, pur mantenendo una buona portabilita';
- ....

Per alcuni processori, tutt'oggi non c'e' alternativa al C. E non ci sara' mai, probabilmente "moriranno" prima detti processori...

^TiGeRShArK^

21-07-2008, 16:16

Ma non mi hai dimostrato che con qualche altro linguaggio si può fare tutto quello che si può fare in C. Probabilmente si possono fare /meglio/ tante cose, ma non tutto quello che si può fare in C. Per questo continuo imperterrito a ritenere che la programmazione in C sia più generica - quantomeno rispetto a qualsiasi altro tipo di programmazione mi sia stata portata ad esempio in questo thread. E ad attendere esempi del contrario.

come no? :)
con l'assembly e con il codice macchina puoi anche fare molto di + :)
Quindi è giusto usare l'assembly/ il codice macchina a sproposito avendo a disposizione strumenti migliori? :)

In your not so humble opinion. Io non sono d'accordo e se la memoria non m'inganna ne ho portato esempi.

esempi di codice C/C++ che abbia la stessa leggibilità/complessità di un codice C# equivalente a questo ad esempio? :)

Console.WriteLine("Download");
string text = new WebClient().DownloadString("http://www.gutenberg.org/dirs/etext98/grexp10.txt"); // Great Expectations
string[] words = text.Split(new char[] { ' ', '\t', '\n', '\r', '-' }, StringSplitOptions.RemoveEmptyEntries);
List<string> array = new List<string>();
Console.WriteLine("Prepare");
for (int t = 0; t < 200; t++)
{
array.AddRange(words);
}
int totalLength = array.Count;
Console.WriteLine("Start - Numero di parole che iniziano con 'a', tra un elenco di {0} parole",totalLength);
Stopwatch watch;
watch = Stopwatch.StartNew();
res = array.AsParallel().Count(t => t.StartsWith("a"));
watch.Stop();
Console.WriteLine("Funzionale Parallel: {0} ms - Res:{1}", watch.ElapsedMilliseconds,res);
Console.ReadKey();

Ti sfido a scrivere qualcosa di equivalente in C (o anche in C++ se vuoi) che mantenga una parvenza di leggibilità :)
Da notare che sfrutta automaticamente tutti i core disponibili sulla macchina grazie al semplice metodo AsParallel() :)

Dici? Alla fine se si usano solo costrutti di alto livello la sintassi del C++ è praticamente uguale a quella di Java e C#, e in fondo c'è così tanta differenza fra un'eccezione non gestita ed un errore di protezione?

si, proprio uguale uguale :)
vedi sopra :)

No, il modello di memoria del C è lineare (dato che gli interi si possono castare a puntatori). Anche se nel corso della storia i compilatori per architetture segmentate (tipo DOS reale e modalità protetta a 16 bit) sono stati estesi con macro e funzioni specifiche per gestire la segmentazione (ti ricordi i "memory model" dei compilatori per DOS, tipo tiny, huge, etc. :-P).
[Comunque non ho mai visto un'implementazione a 32 bit che facesse uso dei segmenti. Questa parte dell'architettura Intel è stata snobbata da qualsiasi sistema operativo che conosca. E probabilmente è stato meglio così :-D .]

vabbè... e 'sti cazzi..
il modello reale della macchina è basato sulla paginazione, non sulla segmentazione o sul modello lineare, quindi il c non ti fa vedere realmente come funziona la macchina, che è quelo che sostenevi, o sbaglio? :)

Il compilatore trasforma le mie istruzioni in assembly, non capisco quali ottimizzazioni potrebbe introdurre dietro la mia schiena che possano farmi cambiare addirittura il modo in cui vedo la macchina. Al massimo può eliminare qualche istruzione inutile o qualche controllo ridondante, ma se io faccio

*(char *) 0x80001234 = 3;

metto un 3 nell'indirizzo di memoria $80001234, qualsiasi cosa ne possa pensare il compilatore.

E dove si troverebbe *fisicamente* quest'indirizzo di memoria? :)

Aggiungo che con il C, proprio per la fisicità dei puntatori, posso sfruttare direttamente la paginazione con funzioni come mmap() per ottenere prestazioni altissime, anche in applicazioni moderne e di alto livello.

pensa te che culo...
prestazioni che nella quasi totalità dei casi saranno inutili dato che il bottle-neck vero e proprio ce lo mostrerà il profiler e non certo una tua supposizione :)

Non sarà completo, ma è - istruzioni speciali a parte - lo stesso che puoi ottenere in assembly. E quanto al fatto che sia inutile, probabilmente lo è, ma io non credo che un programmatore si possa definire completo se non è in grado di controllare - o per lo meno avere una vaga idea di come si faccia - una generica macchina.
Allora io potrei dire per assurdo che un programmatore non si può definire completo finchè non conosce ogni singolo elemnto dell'architettura di una macchina perchè è importantissimo sapere tutto quello che accade "under the hood" anche se è il compilatore che si occupa di quelle cose a basso livello :)
Quindi naturalmente deve conoscere a menadito l'architettura dei diversi processori e deve saper programmare in assembly per almeno un paio di architetture deiverse.
Occhio però che con questa definizione sono ben pochi quelli che si possono definire programmatori.
Guarda caso invece per me un bravo programmatore è chi riesce a risolvere il problema richiesto dal customer (e SOLO quello) + velocemente possibile e producendo codice dall'elevata leggibilità e qualità intrinseca, che è DI GRAN LUNGA il parametro + importante da valutare.
Visto che ci sei inoltre dimmi quanta richiesta lavorativa c'è per programmatori C# e per programmatori Assembly (che a stare a sentire te sarebbero i migliori in assoluto dato che conoscono a fondo la macchina) :)

EDIT: dimenticavo..
da notare come le righe significative nell'esempio postato, come avrai capito, siano solo quelle tre in neretto.
Quindi mi aspetterei ottimisticamente almeno 30 righe di codice C++, anche se imho saranno diverse in + :)

71104

21-07-2008, 17:48

Sbaglio o è dai tempi del 386 che è possibile usare la paginazione? :mbe: il bello è che sti niubbi usano con dimestichezza termini come "user mode" e "kernel mode" come se ne sapessero qualcosa :asd:

ogni tanto salta pure fuori qualche mezza sega che ti spara a freddo un bel "ring 0" e te per un attimo ci rimani :D asdasdasdasdasdasd

e il memory model del C non è basato sulla segmentazione, o ricordo male? tu però non sei da meno eh... :fagiano:

71104

21-07-2008, 18:10

Ma non mi hai dimostrato che con qualche altro linguaggio si può fare tutto quello che si può fare in C. Probabilmente si possono fare /meglio/ tante cose, ma non tutto quello che si può fare in C. mi introduco un attimo nella discussione: con C++ si può fare necessariamente tutto quello che si può fare in C, e anche molto di più naturalmente.

Per questo continuo imperterrito a ritenere che la programmazione in C sia più generica - quantomeno rispetto a qualsiasi altro tipo di programmazione mi sia stata portata ad esempio in questo thread. E ad attendere esempi del contrario. scrivimi in C un'applicazione basata su GDI+ :Prrr:

Alla fine se si usano solo costrutti di alto livello la sintassi del C++ è praticamente uguale a quella di Java e C#, 1) definisci "costrutto di alto livello"
2) falsissimo in ogni caso: C++ non ha il garbage collector

e in fondo c'è così tanta differenza fra un'eccezione non gestita ed un errore di protezione? sono due cose completamente diverse: le eccezioni C++ vengono definite dallo standard (e non dalle specifiche del processore, come invece quelli che tu chiami "errori di protezione") ma la loro implementazione viene lasciata al compilatore, e potrebbe essere molto diversa da quella delle eccezioni del processore.

ad ogni modo non si capiva dove volevi arrivare.

No, il modello di memoria del C è lineare (dato che gli interi si possono castare a puntatori). assolutamente no: il C non definisce nessunissimo modello di memoria; il modello di memoria dipende dall'architettura e dall'uso che il sistema operativo ne fa, ed infatti era possibile programmare in C tanto su DOS quanto su Windows 3.1 quanto su Windows 95 quanto su Windows 2000/XP/Vista, tutti sistemi che hanno tre modelli di memoria totalmente differenti; neanche la minima somiglianza, fatta eccezione per Windows 95 e Windows 2000/XP/Vista.

Comunque non ho mai visto un'implementazione a 32 bit che facesse uso dei segmenti. Questa parte dell'architettura Intel è stata snobbata da qualsiasi sistema operativo che conosca. Windows NT usa i segmenti: il segmento che permette di accedere allo user space è diverso da quello usato per accedere al kernel space.

Al massimo può eliminare qualche istruzione inutile o qualche controllo ridondante, e ritardare l'esecuzione di qualche istruzione e scambiarne l'ordine

ma se io faccio

*(char *) 0x80001234 = 3;

metto un 3 nell'indirizzo di memoria $80001234, qualsiasi cosa ne possa pensare il compilatore. *metterai, non metti; e comunque se vuoi fare il figo scegli un indirizzo più credibile :asd:

Aggiungo che con il C, proprio per la fisicità dei puntatori, posso sfruttare direttamente la paginazione con funzioni come mmap() per ottenere prestazioni altissime, anche in applicazioni moderne e di alto livello. pointless; worthless; e mi sembra anche una discreta pippa mentaless.
se magari ce lo spieghi meglio...

Non sarà completo, ma è - istruzioni speciali a parte - lo stesso che puoi ottenere in assembly. E quanto al fatto che sia inutile, probabilmente lo è, ma io non credo che un programmatore si possa definire completo se non è in grado di controllare - o per lo meno avere una vaga idea di come si faccia - una generica macchina. il programmatore non è colui che risponde alla tua fantasiosa idea di programmatore, ma colui che crea programmi, punto. poi ci sono programmatori e programmatori, ma poco poco che uno piazza un JavaScript di sua creazione in una pagina HTML, tàcchete: quello è un programmatore.

ci sono programmatori di ogni genere al mondo: ci sono quelli che scrivono compilatori (e che vengono a diretto contatto con l'assembly della macchina) e quelli che scrivono sofisticate applicazioni web non senza un vasto uso di scripting; ma non vedo perché sminuire la seconda categoria nei confronti della prima (per poi ritrovarci con applicazioni web scritte di merda?).

71104

21-07-2008, 18:15

- scrivi codice compatto; questo non è assolutamente vero, ma anzi spesso è vero il contrario.

^TiGeRShArK^

21-07-2008, 18:38

il bello è che sti niubbi usano con dimestichezza termini come "user mode" e "kernel mode" come se ne sapessero qualcosa :asd:

ogni tanto salta pure fuori qualche mezza sega che ti spara a freddo un bel "ring 0" e te per un attimo ci rimani :D asdasdasdasdasdasd

tu però non sei da meno eh... :fagiano:

beh.. non tocco il C dai tempi del Quick C :asd:
saranno passati una dozzina d'anni così ad occhio... :stordita:

marco.r

21-07-2008, 18:53

2) falsissimo in ogni caso: C++ non ha il garbage collector

:mbe:
Intendi dire "di default" ?

sottovento

21-07-2008, 18:55

questo non è assolutamente vero, ma anzi spesso è vero il contrario.

;) Non mi sento di aprire un flame su questo.
Tutto sommato il principale motivo, secondo me, per cui il C ha ancora vita lunga e' che su molte piattaforme industriali c'e' solo lui :D

marco.r

21-07-2008, 18:59

;) Non mi sento di aprire un flame su questo.
Tutto sommato il principale motivo, secondo me, per cui il C ha ancora vita lunga e' che su molte piattaforme industriali c'e' solo lui :D
Il che vuol dire che c'e' anche altro :p.
Molti linguaggi usano il C come "assembler portabile" invece che codice macchina nativo proprio per questo motivo.

71104

21-07-2008, 19:28

:mbe:
Intendi dire "di default" ? no :fagiano:
se avessi detto che il C++ non ha un garbage collector "di default" si sarebbe inteso che se cambi qualche impostazione attivi il garbage collector del C++ :fagiano:
mi sembrava chiarissimo quello che volevo dire: quando allochi dinamicamente un blocco di memoria in C++ (sia che lo fai con new sia che lo fai con malloc, calloc o realloc) ti devi preoccupare di deallocarlo, rispettivamente con delete o free. in alternativa puoi scriverti un tuo garbage collector oppure usarne uno scritto da qualcun altro, ma questo non mi autorizza a dire che il C++ non ha un GC solo "di default": il C++ il GC non ce l'ha per niente :fagiano:

;) Non mi sento di aprire un flame su questo.
Tutto sommato il principale motivo, secondo me, per cui il C ha ancora vita lunga e' che su molte piattaforme industriali c'e' solo lui :D e chi dice nulla; il C vivesse quanto e dove gli pare, solo che io personalmente quando programmo in C++ o in Java o in C# riesco a realizzare le stesse cose scrivendo molto di meno :fagiano:

alderighi

21-07-2008, 19:30

shinya

21-07-2008, 20:18

certo sarò anche un bambino con il lecca lecca che di lavoro fa il programmatore presso una grossa ditta di procedure oracle

Pure io programmo su Oracle. Non è un vanto te l'assicuro...

^TiGeRShArK^

21-07-2008, 20:53

certo sarò anche un bambino con il lecca lecca che di lavoro fa il programmatore presso una grossa ditta di procedure oracle ma cominciamo ad argomentare: in c++ puoi accedere direttamente ad aree di memoria, alle librerie del s.o., ha l'ereditarietà multipla ecc ecc
il java no

pensa te che culo...
inizia ad aggiornare il profilo allora dato che, se non sei un cazzaro, è sbagliato.
E non è che ci voglia poi questa scienza infusa a lavorare con oracle, tanto che credo che la maggior parte delle persone che postano qui ci hanno avuto a che fare.
Comunque vale anche per te l'invito per tradurre le tre righe di codice che ho postato sopra in c++, che se è così potente come sostieni dovrebbe essere una passeggiata :)

marco.r

21-07-2008, 21:25

no :fagiano:
se avessi detto che il C++ non ha un garbage collector "di default" si sarebbe inteso che se cambi qualche impostazione attivi il garbage collector del C++ :fagiano:
mi sembrava chiarissimo quello che volevo dire: quando allochi dinamicamente un blocco di memoria in C++ (sia che lo fai con new sia che lo fai con malloc, calloc o realloc) ti devi preoccupare di deallocarlo, rispettivamente con delete o free. in alternativa puoi scriverti un tuo garbage collector oppure usarne uno scritto da qualcun altro, ma questo non mi autorizza a dire che il C++ non ha un GC solo "di default": il C++ il GC non ce l'ha per niente :fagiano:

Quando parlavo di default intendevo dire che l'allocatore di default non fa uso di GC, ma che (a differenza di altri linguaggi) e' possibile cambiarlo. Tra dire "il C++ non ha per niente il GC" e "la libreria standard del C++ non fornisce un allocatore con GC" ne passa.

71104

21-07-2008, 22:09

certo sarò anche un bambino con il lecca lecca che di lavoro fa il programmatore presso una grossa ditta di procedure oracle mecojoni :asd:

ma cominciamo ad argomentare: in c++ puoi accedere direttamente ad aree di memoria, assolutamente no: in C++ puoi accedere direttamente solo alle aree di memoria allocate (e su molte piattaforme hardware aggiungerei anche che devi anche avere i permessi di scrittura, e su alcune altre anche quelli di lettura), per tutte le altre è undefined behavior.

alle librerie del s.o., ammetto che mi stava per scappare un: "anche in Java, con JNI" :D
lo ritiro subito :Prrr:

edit - in compenso però, dopo un ulteriore ripensamento, aggiungo: solamente perché C e C++ giocano in casa. in altre parole, questa affermazione è vera solo se contestualizzata: non sarebbe necessariamente vera in un sistema operativo scritto in C#, ad esempio.

ha l'ereditarietà multipla ecc ecc
il java no cervelli migliori del tuo hanno sostenuto che questo è un bene perché l'ereditarietà multipla porta a design-are gerarchie inutilmente complesse e troppo difficili da mantenere.

"la libreria standard del C++ non fornisce un allocatore con GC" e siccome la libreria standard del C++ è tutto ciò che il C++ ti fornisce, si giunge immediatamente a:
"il C++ non ha per niente il GC" non ne passava poi tanto.

Unrue

21-07-2008, 22:13

Che senso ha confrontare linguaggi differenti per età di ben 30 anni?:confused: E' ovvio che gli ultimi sono più evoluti.

Io scrivo molto in C. Certo è rognoso, ma mi dà una padronanza sulla macchina che nessun altro ti dà. Se togliete il C con cosa li scrivete i sistemi operativi? In Java? Mah provateci. Perché non vi scagliate contro l' Assembly che è moolto più complesso?:confused:

Come può un linguaggio con cui si crea tutto l'ambiente morire? Che senso ha? Alternative? Java, C# e compagnia bella NON possono sostituire C nel loro ambito, semplicemente perché non sono progettati per questo. Se devo scrivere una web application uso Java è chiaro. Dipende tutto dal contesto. E' il contesto che mi fa scegliere, non la difficoltà del linguaggio stesso. Esempio: l'altro giorno mi serviva uno script per il parsing di alcuni files di testo. Ho preso il manuale di Perl è l'ho fatto. Potevo farlo in C, ma se un linguaggio con una riga mi fa fare una cosa che con un altro ne servono 10 perché non usarlo ?

^TiGeRShArK^

21-07-2008, 22:16

Che senso ha confrontare linguaggi differenti per età di ben 30 anni?:confused: E' ovvio che gli ultimi sono più evoluti.

Io scrivo molto in C. Certo è rognoso, ma mi dà una padronanza sulla macchina che nessun altro ti dà. Se togliete il C con cosa li scrivete i sistemi operativi? In Java? Mah provateci. Perché non vi scagliate contro l' Assembly che è moolto più complesso?:confused:

Ma infatti io sono anche contrario all'assembly dato che oggi non ha praticamente + senso.

Come può un linguaggio con cui si crea tutto l'ambiente morire? Che senso ha? Alternative? Java, C# e compagnia bella NON possono sostituire C nel loro ambito, semplicemente perché non sono progettati per questo. Se devo scrivere una web application uso Java è chiaro. Dipende tutto dal contesto.
appunto, the right tool for the right job.
Ma da qui al dire che la programmazione in C è "generica" e ci fai di tutto, ce ne passa parecchia di acqua sotto i ponti :p
A meno di non essere masochisti fin nel profondo dell'anima ovviamente :asd:

marco.r

21-07-2008, 22:18

e siccome la libreria standard del C++ è tutto ciò che il C++ ti fornisce, si giunge immediatamente a:
non ne passava poi tanto.

:mbe:
E quindi potrei ad esempio dire anche che Java non ha lo Unit Testing ?:wtf:

Mi sembra perlomeno un modo scorretto di esprimersi...

71104

21-07-2008, 22:18

Che senso ha confrontare linguaggi differenti per età di ben 30 anni?:confused: E' ovvio che gli ultimi sono più evoluti. il problema è che qualcuno sembra quasi voler dire il contrario, ecco che senso ha :D

Io scrivo molto in C. Certo è rognoso, ma mi dà una padronanza sulla macchina che nessun altro ti dà. l'assembly

Se togliete il C con cosa li scrivete i sistemi operativi? conosci Singularity? non è scritto in Java, ma è un primo esperimento di ambiente managed a livello di kernel.

Perché non vi scagliate contro l' Assembly che è moolto più complesso?:confused: perché la stupidità umana ha dei limiti: c'è ancora qualcuno che sostiene la grande utilità del C, ma che io sappia nessuno si è ancora azzardato a dire che l'assembly è preferibile ad un altro linguaggio :D
c'è ancora qualche povero ingenuo che crede che i device drivers si scrivano in assembly, ma lo si smentisce molto facilmente.

Come può un linguaggio con cui si crea tutto l'ambiente morire? Che senso ha? aspetta e vedrai.

71104

21-07-2008, 22:19

:mbe:
E quindi potrei ad esempio dire anche che Java non ha lo Unit Testing ?:wtf:

Mi sembra perlomeno un modo scorretto di esprimersi...
ti risulta che Java abbia lo Unit Testing? :wtf:
lo puoi fare in Java (si, ok, JUnit, lo sappiamo), ma non è che Java ce l'ha già.

^TiGeRShArK^

21-07-2008, 22:22

:mbe:
E quindi potrei ad esempio dire anche che Java non ha lo Unit Testing ?:wtf:

Mi sembra perlomeno un modo scorretto di esprimersi...

:mbe:
Java è stato progettato proprio per utilizzare un GC perfettamente integrato nel framework, C++ no.
Non mi pare ci sia altro da dire... :fagiano:
Che poi tu lo possa scrivere e utilizzare in C++ è un altro conto.
Altrimenti potresti anche dire che con il C o con l'assembly fai la programmazione ad oggetti, che è esattamente lo stesso concetto. :stordita:

Unrue

21-07-2008, 22:22

Ma infatti io sono anche contrario all'assembly dato che oggi non ha praticamente + senso.

E con cosa lo sostituiresti? Senza pensare che TUTTE le istruzioni scritte in qualsiasi linguaggio sono tramutate in Assembly, per forza di cose non potrà mai morire :p

Ma da qui al dire che la programmazione in C è "generica" e ci fai di tutto, ce ne passa parecchia di acqua sotto i ponti :p
A meno di non essere masochisti fin nel profondo dell'anima ovviamente :asd:

Beh, in C fai TUTTO. Solo che alcune cose le fai velocemente altre meno, altre non ha senso usarlo perché ci sono linguaggi che in 10 volte meno fai la stessa cosa. Questo è innegabile.

Unrue

21-07-2008, 22:25

:mbe:
Altrimenti potresti anche dire che con il C o con l'assembly fai la programmazione ad oggetti, che è esattamente lo stesso concetto. :stordita:

Lo puoi fare, si chiama Object-C :D

^TiGeRShArK^

21-07-2008, 22:26

E con cosa lo sostituiresti? Senza pensare che TUTTE le istruzioni scritte in qualsiasi linguaggio sono tramutate in Assembly, per forza di cose non potrà mai morire :p

Veramente sono compilate in linguaggio macchina.. :fagiano:

Beh, in C fai TUTTO. Solo che alcune cose le fai velocemente altre meno, altre non ha senso usarlo perché ci sono linguaggi che in 10 volte meno fai la stessa cosa. Questo è innegabile.
Appunto ed usarlo per fare TUTTO, o anche una grossa parte del tutto, è assolutamente da ricovero psichiatrico se hai a disposizione strumenti n volte migliori.

Unrue

21-07-2008, 22:27

conosci Singularity? non è scritto in Java, ma è un primo esperimento di ambiente managed a livello di kernel.

No. In cosa è scritto? E comunque sono allo stato embrionale, quindi di qui a raggiungere la solidità del C per scriverci una cosa delicata come il kernel..

Unrue

21-07-2008, 22:28

Veramente sono compilate in linguaggio macchina.. :fagiano:.

Quello è l'ultimo passo..:) Prima sono tramutate in Assembly, passando per l'Instruction Set del processore.

^TiGeRShArK^

21-07-2008, 22:29

Lo puoi fare, si chiama Object-C :D

Objective c..
ma io parlavo del C classico, non dei linguaggi derivati.

^TiGeRShArK^

21-07-2008, 22:29

Quello è l'ultimo passo..:) Prima sono tramutate in Assembly, passando per l'Instruction Set del processore.

e c'è qualche impedimento fisico a saltare la traduzione in assembly e a compilare direttamente in linguaggio macchina? :fagiano:

Unrue

21-07-2008, 22:31

e c'è qualche impedimento fisico a saltare la traduzione in assembly e a compilare direttamente in linguaggio macchina? :fagiano:

Il compilatore/interprete associa istruzioni di alto livello in istruzioni Assembly. Poi c'è l'ultimo accostamento Assembly-linguaggio macchina con l'ISA. Altrimenti ISA sarebbe inutile con i linguaggi tipo Java o C#? :fagiano:

cdimauro

21-07-2008, 22:31

Qualche piccolo appunto, visto che ti hanno già risposto e la discussione è andata avanti. :)
Dici? Alla fine se si usano solo costrutti di alto livello la sintassi del C++ è praticamente uguale a quella di Java e C#, e in fondo c'è così tanta differenza fra un'eccezione non gestita ed un errore di protezione?
Sì, c'è: il traceback con l'elenco delle chiamate effettuate e la riga di codice incriminato.

Direi che non c'è proprio paragone con un anonimo segmentation fault o, peggio ancora, con un bug intermittente. :cool:
[Comunque non ho mai visto un'implementazione a 32 bit che facesse uso dei segmenti. Questa parte dell'architettura Intel è stata snobbata da qualsiasi sistema operativo che conosca. E probabilmente è stato meglio così :-D .]
All'inizio la pensavo anch'io così, ma il modello segmentato ha anche i suoi pregi, che sono pure abbastanza consistenti.

Esempio: si possono tranquillamente ridimensionare strutture dinamiche come gli array senza alcuno spostamento di memoria.
Il compilatore trasforma le mie istruzioni in assembly,
Dipende dal compilatore: potrebbe anche tradurle direttamente in codice macchina.
Non sarà completo, ma è - istruzioni speciali a parte - lo stesso che puoi ottenere in assembly. E quanto al fatto che sia inutile, probabilmente lo è, ma io non credo che un programmatore si possa definire completo se non è in grado di controllare - o per lo meno avere una vaga idea di come si faccia - una generica macchina.
Meglio assembly e linguaggio macchina allora.

Per inciso: con C, C++, ecc. è possibile sfruttare soltanto una parte delle istruzioni dei microprocessori, e con ciò non mi riferisco soltanto a istruzioni privilegiate / di sistema, ma anche a una banale ROL o ROR. ;)
ma cominciamo ad argomentare: in c++ puoi accedere direttamente ad aree di memoria, alle librerie del s.o., ha l'ereditarietà multipla ecc ecc
il java no
A parte l'ereditarietà multipla, anche Java lo permette.

Python permette anche l'ereditarietà multipla. Per il resto: http://docs.python.org/lib/module-ctypes.html

In particolare: http://docs.python.org/lib/ctypes-loading-dynamic-link-libraries.html e http://docs.python.org/lib/ctypes-pointers.html

In particolare con questi ultimi puoi divertirti a simulare i segmentation fault e i bug intermittenti tipici di C, C++ et similia. Così ti senti a casa. :p

Unrue

21-07-2008, 22:36

Dipende dal compilatore: potrebbe anche tradurle direttamente in codice macchina.

Che io sappia no. Hai qualche esempio? E riguardo gli interpreti? Non mi pare:confused:

71104

21-07-2008, 22:37

No. In cosa è scritto? il kernel in C#, managed e unmanaged; l'HAL in C++, non so se managed o meno; ed infine c'è anche un piccolo pezzo scritto in C e assembly che viene richiamato all'avvio, quando ancora il sistema non ha caricato i drivers e deve usare il BIOS. per la cronaca, il garbage collector è scritto in C# unmanaged.

per maggiori informazioni:
http://en.wikipedia.org/wiki/Singularity_%28operating_system%29

E comunque sono allo stato embrionale, quindi di qui a raggiungere la solidità del C per scriverci una cosa delicata come il kernel.. la "solidità" è solo una tua impressione emotiva; in informatica non esiste "solidità", o funziona o non funziona. fidati che Singularity funzionerà, e rispetto agli odierni kernel scritti in C avrà molti vantaggi.

71104

21-07-2008, 22:40

Sì, c'è: il traceback con l'elenco delle chiamate effettuate e la riga di codice incriminato. i segnali Unix sono una delle cose più distruttive mai concepite dall'uomo, e siamo d'accordo (forse avevi in mente quelli quando hai scritto questa frase); ma se usi un qualunque debugger Microsoft lo stack trace dettagliato ti viene dato sia che parte un'eccezione C++, sia che parte un'eccezione SEH, e questo indipendentemente dal compilatore e dall'implementazione delle eccezioni C++; è sufficiente che le informazioni di debug siano in formato CodeView.

Unrue

21-07-2008, 22:41

per maggiori informazioni:
http://en.wikipedia.org/wiki/Singularity_%28operating_system%29

Beh, c'è sempre C vedo :D E C++. Dove è la novità? Anche Vista è scritto in C, C++ C# e compagnia bella. La vera novità sarebbe un SO scritto interamente con linguaggi di alto livello.

la "solidità" è solo una tua impressione emotiva; in informatica non esiste "solidità", o funziona o non funziona. fidati che Singularity funzionerà, e rispetto agli odierni kernel scritti in C avrà molti vantaggi.

La solidità è data dai compilatori. In C sono sviluppati da 30 anni. Per solidità intendo esenzione da bachi. Questo Singularity ne avrà a bizzeffe essendo nuovo.

71104

21-07-2008, 22:46

Beh, c'è sempre C vedo :D E C++. Dove è la novità? Anche Vista è scritto in C, C++ C# e compagnia bella. La vera novità sarebbe un SO scritto interamente con linguaggi di alto livello. sapevamo già che la tua ignoranza fosse consistente, non c'era bisogno dell'ennesima affermazione disinformata. giusto affinché i lettori non restino ingannati comunque, specifico: il kernel di Vista non è neanche lontanamente scritto in C#: è scritto interamente in C.

Unrue

21-07-2008, 23:25

sapevamo già che la tua ignoranza fosse consistente, non c'era bisogno dell'ennesima affermazione disinformata. giusto affinché i lettori non restino ingannati comunque, specifico: il kernel di Vista non è neanche lontanamente scritto in C#: è scritto interamente in C.

:mbe: :mbe: Sapevamo chi?? Oh ciccio, ma come ti permetti? Già mi stavi sul cavolo prima, adesso poi.. Meno male che ci sono i mod va. :rolleyes: Non ha senso perdere tempo a risponderti, meglio continuare a discutere con gente più seria.

marco.r

21-07-2008, 23:38

ti risulta che Java abbia lo Unit Testing? :wtf:
lo puoi fare in Java (si, ok, JUnit, lo sappiamo), ma non è che Java ce l'ha già.

No, e' proprio l'affermazione che non ha molto senso.
Dire che un linguaggio "non ha X " non ha senso se non si tratta di caratteristiche del linguaggio ma funzionalita' che il linguaggio stesso ti permette di scrivere. Ha senso dire che il C++ non ha le lambda expression o le closure, non ha senso dire che il C++ non ha "il" garbage collector perche' la libreria standard non fornisce "un" garbage collector. Idem per il discorso Java e (sorry, mi riferivo al linguaggio in questo caso). Tra l'altro da la falsa impressione che non sia una questione che non si possa ovviare.

marco.r

21-07-2008, 23:47

:mbe:
Java è stato progettato proprio per utilizzare un GC perfettamente integrato nel framework, C++ no.

Java dipende dalla presenza di un GC, C++ no.
Quando e' stato redatto lo standard corrente del C++ non e' che il comitato ignorasse l'esistenza dei Garbage Collector, anzi, uno degli usi previsti della possibilita' di scriversi gli allocatori era proprio quella di poter scrivere un GC.
La struttura del linguaggio limita il tipo di GC utilizzabili (niente copying GC ad esempio) ma quelli fattibili lo sono al 100%.

marco.r

22-07-2008, 00:01

Giusto per chiarire: diversi linguaggi che hanno compilatore/interprete scritto in C o C++ usano l'Hans-Boehm (http://www.hpl.hp.com/personal/Hans_Boehm/gc/ , un GC per C e C++, come GC per il linguaggio implementato.
Tra questi ci dovrebbe essere ancora Mono (di sicuro un po' di tempo fa lo era, mi sembra stiano cercando di implementare un compacting GC).

nico159

22-07-2008, 02:58

a settembre uscirà la versione 2.0 di mono che permetterà di usare anche qualche feature di .net 3.0...
Per ora ancora è piuttosto indietro...
Per quanto riguarda C#, secondo il capo progetto no
http://tirania.org/blog/archive/2008/Jul-21.html

^TiGeRShArK^

22-07-2008, 03:11

http://tirania.org/blog/archive/2008/Jul-21.html

:mbe:
sta parlando del repository e dell'upcoming development, non delle stable versions disponibili al pubblico... :mbe:
e tra l'altro dice *chiaramente* che ancora non hanno idea di come sarà C# 4.0 (che integrerà plinq, di cui si vede un esempio sopra) e che sono in attesa del PDC:

Sadly there are no actual details on the interview about what is coming up on C# 4.0. We have to wait until the PDC to get an idea of what will be coming.

sinceramente non ho capito cosa volevi evidenziare col tuo post... :stordita:

^TiGeRShArK^

22-07-2008, 03:26

No, e' proprio l'affermazione che non ha molto senso.
Dire che un linguaggio "non ha X " non ha senso se non si tratta di caratteristiche del linguaggio ma funzionalita' che il linguaggio stesso ti permette di scrivere. Ha senso dire che il C++ non ha le lambda expression o le closure, non ha senso dire che il C++ non ha "il" garbage collector perche' la libreria standard non fornisce "un" garbage collector. Idem per il discorso Java e (sorry, mi riferivo al linguaggio in questo caso). Tra l'altro da la falsa impressione che non sia una questione che non si possa ovviare.
...spè marco...
quindi secondo te ha senso dire che il C o l'assembly non permettono la programmazione ad oggetti oppure no? :mbe:
sappiamo benissimo tutti noi che in C (e in assembly) è possibile scrivere codice OO, ma secondo te è sbagliato dire che il C non permette questo paradigma poiché non fornisce alcuno strumento che lo supporta???
Per me 71104 ha detto una cosa essenzialmente corretta.
Il C++ non fornisce uno strumento per la garbage collection poiché allo stesso modo il C non fornisce strumenti per la programmazione ad oggetti.
Ma questo non implica che sia impossibile programmare ad oggetti col C (anche in assembly, volendo, è possibile), ma, bensì, che il C non supporta la programmazione ad oggetti.
Esempio classico, citato + volte in questo thread, è l'objective C che permette di programmare ad oggetti (con una sintassi ihmo ORRIBILE dato che a me mi si incrociano gli occhi dopo la terza parentesi quadra nidificata).
Ma ciò non vuol dire assolutamente che il C puro, che è l'oggetto della discussione, permette la programmazione ad oggetti.
Anche perché, se non vado errato, c != objective c.
Altrimenti quelli della Adobe non avrebbero imparato l'aramaico, solo per bestemmiare in quella lingua, pur di non passare dal codice c++ (Carbon) al codice Objective C e, + recentemente all'objective c 2.0 (Cocoa) che introduce diversi miglioramenti (ma che continua a incrociarmi gli occhi con quelle dannate parentesi quadre.. :muro: ).
boh..
secondo me, alla fine dei conti, dire che il C++ non supporta il garbage collector e dire che il C non permette la programmazione procedurale stanno sullo stesso piano per quanto detto prima... :mbe:

^TiGeRShArK^

22-07-2008, 03:28

Java dipende dalla presenza di un GC, C++ no.
Quando e' stato redatto lo standard corrente del C++ non e' che il comitato ignorasse l'esistenza dei Garbage Collector, anzi, uno degli usi previsti della possibilita' di scriversi gli allocatori era proprio quella di poter scrivere un GC.
La struttura del linguaggio limita il tipo di GC utilizzabili (niente copying GC ad esempio) ma quelli fattibili lo sono al 100%.

java è stato progettato appositamente per l'uso di un GC.
il C++ no.
E su questo credo che possiamo essere d'accordo tutti..
..quindi a che pro questa "precisazione"? :stordita:

cdimauro

22-07-2008, 08:34

Che io sappia no. Hai qualche esempio? E riguardo gli interpreti? Non mi pare:confused:
Non è importante un esempio pratico (che al momento non mi sovviene), ma se la cosa è fattibile oppure no.

Quando il back-end di un compilatore (quindi non mi riferisco soltanto al C) esegue la classica EMIT (in genere si chiama così la funzione o il metodo che produce il codice di output), si può benissimo sostituire questa:

EMIT("MOV AX,0AA55")

con questa:

EMIT(0xA1, 0x55, 0xAA)

;)
i segnali Unix sono una delle cose più distruttive mai concepite dall'uomo, e siamo d'accordo (forse avevi in mente quelli quando hai scritto questa frase);
No, volevo semplicemente sottolineare il fatto che linguaggi come Java, C#, Python, ecc., normalmente ritornano il traceback quando ci sono problemi, mentre C, C++, ecc. non danno nessuno aiuto.

Francamente non pensavo proprio ai segnali di Unix. :)
ma se usi un qualunque debugger Microsoft lo stack trace dettagliato ti viene dato sia che parte un'eccezione C++, sia che parte un'eccezione SEH, e questo indipendentemente dal compilatore e dall'implementazione delle eccezioni C++; è sufficiente che le informazioni di debug siano in formato CodeView.
Sì, ma devi ricorrere a questi strumenti, e... devi averli anche installati. Cosa che non ti serve coi linguaggi di cui sopra: il traceback è qualcosa che hai già "aggratise". :D
La solidità è data dai compilatori. In C sono sviluppati da 30 anni. Per solidità intendo esenzione da bachi. Questo Singularity ne avrà a bizzeffe essendo nuovo.
Questa non ce l'hai nemmeno oggi e neppure un linguaggio "managed" te la può garantire. :p

cionci

22-07-2008, 09:14

che leggendo la tua firma mi chiedo se tu ritenga di essere un cretino intelligente o un intelligente cretino :asd:
hai mai considerato l'ipotesi di essere un cretino cretino? :D
sapevamo già che la tua ignoranza fosse consistente, non c'era bisogno dell'ennesima affermazione disinformata. giusto affinché i lettori non restino ingannati comunque, specifico: il kernel di Vista non è neanche lontanamente scritto in C#: è scritto interamente in C.
71104: sei sospeso per 3 gg.
Possibile che tu non riesca a confrontarti con le altre persone ? Sembra che il tuo unico scopo sia umiliarle. Non è un comportamento da tenere in un forum. Su un forum serve rispetto per le altre persone, indipendentemente dal fatto che sia abbia o meno ragione.

peppepz

22-07-2008, 11:50

come no? :)
con l'assembly e con il codice macchina puoi anche fare molto di + :)
Quindi è giusto usare l'assembly/ il codice macchina a sproposito avendo a disposizione strumenti migliori? :)

No. Ma come sto dicendo da ormai troppo tempo, con l'assembly non è ragionevole pensare di poter scrivere progetti di una complessità più che media. Inoltre l'assemblativo è strettamente legato all'architettura della macchina che lo esegue. Con il C/++ i due limiti suddetti sono ragionevolmente allentati, e quindi non è così da pazzi usarlo e impararlo (anche se è chiaro che linguaggi di livello più alto /sono migliori/).

esempi di codice C/C++ che abbia la stessa leggibilità/complessità di un codice C# equivalente a questo ad esempio? :)

Console.WriteLine("Download");
string text = new WebClient().DownloadString("http://www.gutenberg.org/dirs/etext98/grexp10.txt"); // Great Expectations
string[] words = text.Split(new char[] { ' ', '\t', '\n', '\r', '-' }, StringSplitOptions.RemoveEmptyEntries);
List<string> array = new List<string>();
Console.WriteLine("Prepare");
for (int t = 0; t < 200; t++)
{
array.AddRange(words);
}
int totalLength = array.Count;
Console.WriteLine("Start - Numero di parole che iniziano con 'a', tra un elenco di {0} parole",totalLength);
Stopwatch watch;
watch = Stopwatch.StartNew();
res = array.AsParallel().Count(t => t.StartsWith("a"));
watch.Stop();
Console.WriteLine("Funzionale Parallel: {0} ms - Res:{1}", watch.ElapsedMilliseconds,res);
Console.ReadKey();

Ti sfido a scrivere qualcosa di equivalente in C (o anche in C++ se vuoi) che mantenga una parvenza di leggibilità :)
Da notare che sfrutta automaticamente tutti i core disponibili sulla macchina grazie al semplice metodo AsParallel() :)

Non è che il codice che hai scritto sia semplice, è solo che la complessità è nascosta nelle classi Console, Stopwatch, List, String, e WebClient, che giustamente non hai unito all'esempio. Con delle classi equivalenti scritte in C++, il testo del programma sarebbe praticamente lo stesso a parte l'invocazione di AsParallel. In C++ utilizzando roba tipo l'STL o meglio ancora un toolkit tipo Qt si potrebbe tranquillamente scrivere del codice di complessità paragonabile, e qualsiasi cosa tu ne possa pensare,

si, proprio uguale uguale :)
vedi sopra :)

la /sintassi/ di C# e Java è volutamente pressoché identica a quella del C++.

vabbè... e 'sti cazzi..
il modello reale della macchina è basato sulla paginazione, non sulla segmentazione o sul modello lineare, quindi il c non ti fa vedere realmente come funziona la macchina, che è quelo che sostenevi, o sbaglio? :)

No, la paginazione serve solamente a estendere l'intervallo di indirizzi per coprire memoria virtuale anziché fisica come si farebbe con i soli indirizzi fisici. Non c'è differenza fra un programma che funziona con paginazione attiva o disattiva, salvo il fatto che con la paginazione attiva avrà a disposizione più memoria. La paginazione è intesa proprio per non essere vista dai programmi usermode (a parte l'eccezione del mmap() di cui ti ho parlato). Di conseguenza un programma /usermode/ in assembly vede lo spazio degli indirizzi virtuale proprio come un programma in C. Non ci sono due modelli di memoria differenti come sostenevi tu prima.

E dove si troverebbe *fisicamente* quest'indirizzo di memoria? :)

Dipende dalla macchina che esegue il codice. Per esempio potrei averci mappato un file di testo tramite mmap().

[col c si può usare il memory mapping]

pensa te che culo...
prestazioni che nella quasi totalità dei casi saranno inutili dato che il bottle-neck vero e proprio ce lo mostrerà il profiler e non certo una tua supposizione :)

Supposizione? Il memory mapping serve per accedere a file nella memoria più veloce possibile consentita dal sistema operativo, cioè sfruttando il suo stesso algoritmo di paging. E' utile (http://msdn.microsoft.com/en-us/library/ms810613.aspx per chi si volesse documentare).

Allora io potrei dire per assurdo che un programmatore non si può definire completo finchè non conosce ogni singolo elemnto dell'architettura di una macchina perchè è importantissimo sapere tutto quello che accade "under the hood" anche se è il compilatore che si occupa di quelle cose a basso livello :)
Quindi naturalmente deve conoscere a menadito l'architettura dei diversi processori e deve saper programmare in assembly per almeno un paio di architetture deiverse.
Occhio però che con questa definizione sono ben pochi quelli che si possono definire programmatori.

Niente affatto, perché con la conoscenza fornita dal C il programmatore sarà in grado di adattarsi a diverse architetture conoscendo i pochi dettagli che cambiano fra l'una e l'altra. Egli non dipenderà dall'esistenza di un compilatore "intelligente" per quell'architettura (esistenza che comunque sarebbe per lui un toccasana, concesso :D).

Guarda caso invece per me un bravo programmatore è chi riesce a risolvere il problema richiesto dal customer (e SOLO quello) + velocemente possibile e producendo codice dall'elevata leggibilità e qualità intrinseca, che è DI GRAN LUNGA il parametro + importante da valutare.
Visto che ci sei inoltre dimmi quanta richiesta lavorativa c'è per programmatori C# e per programmatori Assembly (che a stare a sentire te sarebbero i migliori in assoluto dato che conoscono a fondo la macchina) :)

Ma no, non ho detto che sono i migliori e bla bla eccetera. Solo che è importante sapere come funziona la macchina, perché ti rende più libero e flessibile. Insegnare a programmare un computer senza spiegare come funziona è un po' come se a scuola guida insegnassero a guidare col solo cambio automatico. Sì lo puoi fare, alla fine ma ti manca qualcosa. E magari vai in giro a dire alla gente che il mmap è efficiente per una loro supposizione :mad:.

Quindi mi aspetterei ottimisticamente almeno 30 righe di codice C++, anche se imho saranno diverse in + :)
[/QUOTE]

Dai sii ragionevole :D mi rompo a cercare delle librerie che facciano quel lavoro :-D, se proprio ti interessa mi cimento, ma ci starò a risponderti un po' più di tempo di quanto mi piace dedicarne allo svago... :mc: :D

peppepz

22-07-2008, 12:07

Le eccezioni non gestite non sono poi meglio degli errori di protezione]
Sì, c'è: il traceback con l'elenco delle chiamate effettuate e la riga di codice incriminato.

Dai, ci sono pure col C se compili le informazioni di debug.

[la segmentazione fa schifo :-)]
All'inizio la pensavo anch'io così, ma il modello segmentato ha anche i suoi pregi, che sono pure abbastanza consistenti.
Esempio: si possono tranquillamente ridimensionare strutture dinamiche come gli array senza alcuno spostamento di memoria.

Sì ma solo se consideri un segmento differente per ogni array, e nell'architettura intel i segmenti sono una risorsa scarsa :'-( .

Per inciso: con C, C++, ecc. è possibile sfruttare soltanto una parte delle istruzioni dei microprocessori, e con ciò non mi riferisco soltanto a istruzioni privilegiate / di sistema, ma anche a una banale ROL o ROR. ;)

Vabbe' se proprio stai morendo dal bisogno di usare istruzioni particolari, ti puoi abbassare a usare gli intrinseci che praticamente ogni compilatore C mette a disposizione, o addirittura blocchi di assembly inline, solo che a quel punto la portabilità se ne va a farsi benedire.

[python ha i puntatori]
In particolare con questi ultimi puoi divertirti a simulare i segmentation fault e i bug intermittenti tipici di C, C++ et similia. Così ti senti a casa. :p

:-D grandioso, a questo punto mi sa che è l'ora che mollo il Java per imparare il Python :D. No, serio.

peppepz

22-07-2008, 13:06

mi introduco un attimo nella discussione: con C++ si può fare necessariamente tutto quello che si può fare in C, e anche molto di più naturalmente.

Sì, in questa discussione stiamo facendo un po' di confusione fra C e C++ a causa del fatto che il C++ tende ad essere disponibile in tutti quei contesti dove è disponibile un compilatore C.

scrivimi in C un'applicazione basata su GDI+ :Prrr:

Si può fare, le API GDI+ sono disponibili in versione "piatta" per essere usate dal C.

http://msdn.microsoft.com/en-us/library/ms533969(VS.85).aspx

Non che sia una cosa consigliabile :-) .

[la sintassi di alto livello del C++ è identica a quella di Java e C#

1) definisci "costrutto di alto livello"
2) falsissimo in ogni caso: C++ non ha il garbage collector

1) intendevo dire, se si scrive codice più vicino alla parte "++" del C++ che non codice più vicino alla parte "C". Cioè, niente algebra dei puntatori, classi scritte per bene etc.
2) e dove lo vedi il garbage collector nella /sintassi/? Sarà che manca l'operatore delete ma mi sembra una differenza marginale rispetto alla stragrande maggioranza dei costrutti.

sono due cose completamente diverse: le eccezioni C++ vengono definite dallo standard (e non dalle specifiche del processore, come invece quelli che tu chiami "errori di protezione") ma la loro implementazione viene lasciata al compilatore, e potrebbe essere molto diversa da quella delle eccezioni del processore.

Sì ma io mi riferivo alle eccezioni generate dalla macchina, con le quali si combatte anche in C, sebbene non siano specificate da alcuno standard.

ad ogni modo non si capiva dove volevi arrivare.

Stiamo valutando quanto è più difficile programmare in C++ rispetto ai linguaggi più "moderni" come Java e C#, e in particolare valutavamo la robustezza nei confronti degli errori di programmazione. Accedere ad un indirizzo "sbagliato" (per esempio, sfondando un array) in C provoca quello che io ho chiamato "errore di protezione". Un comportamento equivalente in Java o C# produce un'eccezione. Ci stavamo domandando quanto il meccanismo dei linguaggi più moderni sia più vantaggioso per il programmatore, e la mia idea era che in fondo i vantaggi delle eccezioni non sono poi così tanti.

[il C definisce un modello di memoria?]
assolutamente no: il C non definisce nessunissimo modello di memoria; il modello di memoria dipende dall'architettura e dall'uso che il sistema operativo ne fa, ed infatti era possibile programmare in C tanto su DOS quanto su Windows 3.1 quanto su Windows 95 quanto su Windows 2000/XP/Vista, tutti sistemi che hanno tre modelli di memoria totalmente differenti; neanche la minima somiglianza, fatta eccezione per Windows 95 e Windows 2000/XP/Vista.

Infatti un programma che si basasse sulle peculiarità di uno dei sistemi di memoria che hai nominato non funzionerebbe sugli altri. Per esempio, niente memory mapping in modalità reale. Ma il C consente ai programmi scritti in esso di vedere il modello di memoria sottostante, e si può definire questo il "modello di memoria" del C. Che è specificato nello standard ISO per il C ed è una generalizzazione di tutti i modelli di memoria utilizzati praticamente da tutte le combinazioni macchina/sistema operativo conosciute.

Windows NT usa i segmenti: il segmento che permette di accedere allo user space è diverso da quello usato per accedere al kernel space.

Vabbe' grazie, allora a questo punto tutti utilizzano i segmenti, visto che la segmentazione non si può "disattivare" nell'architettura intel. Solo che i sistemi operativi settano i segmenti che assegnano per default ai programmi utente in modo da avere base a 0 e limite alla fine dello spazio degli indirizzi virtuale. Ma in questa discussione parliamo dell'ambiente visibile ai programmi /utente/. Ti risulta ad esempio che in qualche chiamata win32 si passi un puntatore completo di segmento, anche su windows NT?

*metterai, non metti; e comunque se vuoi fare il figo scegli un indirizzo più credibile :asd:

Consentimi preventivamente di esplicitare che "fare il figo" non è nei miei obiettivi, dopo di che in che senso non credi a quell'indirizzo? :-D

Aggiungo che con il C, proprio per la fisicità dei puntatori, posso sfruttare direttamente la paginazione con funzioni come mmap() per ottenere prestazioni altissime, anche in applicazioni moderne e di alto livello.

pointless; worthless; e mi sembra anche una discreta pippa mentaless.
se magari ce lo spieghi meglio...

Intendo dire che in C puoi utilizzare uno strumento come mmap() proprio perché in C gli indirizzi di memoria sono visibili e corrispondono a quelli visti dalla CPU (in user mode). E che questa possibilità è applicabile in tanti contesti che non mi sembrano per niente "legacy", di nicchia, irrilevanti come si dice in questo thread. Specialmente ora che finalmente anche sul PC abbiamo uno spazio virtuale a 64 bit (o quasi :-D).

il programmatore non è colui che risponde alla tua fantasiosa idea di programmatore, ma colui che crea programmi, punto. poi ci sono programmatori e programmatori, ma poco poco che uno piazza un JavaScript di sua creazione in una pagina HTML, tàcchete: quello è un programmatore.

ci sono programmatori di ogni genere al mondo: ci sono quelli che scrivono compilatori (e che vengono a diretto contatto con l'assembly della macchina) e quelli che scrivono sofisticate applicazioni web non senza un vasto uso di scripting; ma non vedo perché sminuire la seconda categoria nei confronti della prima (per poi ritrovarci con applicazioni web scritte di merda?).

Non mi sembra di avere dato mai una definizione di programmatore, e se l'ho fatto me ne scuso. Se è vero che esistono tanti tipi di programmatore, la mia idea è che quello che sappia meglio come funziona la macchina che programma sarà in grado più agevolmente di passare da un tipo all'altro.