View Full Version : [C] Capire il C..
rikkaidd
24-12-2009, 06:44
Dopo aver studiato alcune guide trovate in internet,sono passato alle API user,ma ancora non riesco a capire cosa posso fare di utile con il c :muro: ,visto che non conosco nessun'altro liguaggio di programmazione.
Potreste indicarmi tutto quello che posso fare con il c e cosa studiare per farlo?(sicuramente si può fare di tutto però voglio sapere i nomi delle cose da sapere)
Per fare un esempio, con le api user posso fare una forma "visuale" di programmazione (messagebox,pulsanti etc..) ma per creare/spostare file e cartelle?;Almeno saprei cosa procurarmi per studiare!!!
Cosa intendi per API user ?
Ryuzaki_Eru
24-12-2009, 11:31
Cosa intendi con "cosa si può fare"? Ci puoi fare letteralmente di tutto.
rikkaidd
24-12-2009, 13:31
per api user quelle che permettono di fare interfacce grafiche,volevo dire finestre non msgbox. Per me che non sò programmare quel tutto non vuol dire un bel niente . Quando ho finito di leggere la guida del c mi sono detto :-ma che schifo è¨ stò linguaggio che si puo eseguire solo dal cmd?;poi mi hanno detto delle api win 32 .bene dopo cosa c'è? ;e dopo ancora?
Le api win32 intendi ? Con quelle puoi fare qualsiasi cosa che si vedi su Windows. Quindi non hai assolutamente limiti di sorte. Le API Win32 non servono solo per le finestre, ma per qualsiasi altra funzionalità che vuoi dare al tuo programma.
masteryuri
24-12-2009, 15:40
Considera che il kernel linux è scritto in C...
Considera che il kernel linux è scritto in C...
Anche quello di Windows lo è stato e lo è ancora in parte.
Ryuzaki_Eru
24-12-2009, 16:29
Per me che non sò programmare quel tutto non vuol dire un bel niente
Io dire di controllarti un pochino senza essere cosi aggressivo.
Non bisogna saper programmare per capire cosa significa "ci puoi fare di tutto".
Hai presente tutto ciò che usi in un pc? Ecco, in C lo puoi fare.
Anche quello di Windows lo è stato e lo è ancora in parte.
In parte? Allora come è scritto il kernel Windows? C++?
rikkaidd
24-12-2009, 17:56
Le api win32 intendi ? Con quelle puoi fare qualsiasi cosa che si vedi su Windows. Quindi non hai assolutamente limiti di sorte. Le API Win32 non servono solo per le finestre, ma per qualsiasi altra funzionalità che vuoi dare al tuo programma.
Grazie,questo era quello che dovevo capire:come andare oltre a paragoni di stringhe,operazioni matematiche e finestrelle sullo scermo con pulsantini e scritte
Ma conosci un buon libro sulle api?
Il C è un linguaggio ad uso generico, per sua natura si presta alla scrittura di sistemi operativi, ma non per questo è relegato ad uno specifico ambito.
masteryuri
24-12-2009, 18:06
Grazie,questo era quello che dovevo capire:come andare oltre a paragoni di stringhe,operazioni matematiche e finestrelle sullo scermo con pulsantini e scritte
Ma conosci un buon libro sulle api?
Con tutto il rispetto, credo sia un po' presto per te per cominciare già ad approfondire le API.
Da quanto hai scritto su questo forum il 15 Dicembre hai cominciato a studiare il C... :mbe:
rikkaidd
24-12-2009, 18:30
Con tutto il rispetto, credo sia un po' presto per te per cominciare già ad approfondire le API.
Da quanto hai scritto su questo forum il 15 Dicembre hai cominciato a studiare il C... :mbe:
Però nella guida che stò studiando c'è scritto che non tutto il c è compatibile con le api e quasi comme fosse un linguaggio diverso.
io ho studiato da questa guida :http://www.blacklight.gotdns.org/wiki/index.php/C
da premettere che sono coscente del fatto che il c sia molto più complesso di quella semplice guida ,ma a me non interessano fare driver o lavorare sulle reti in c ,ma solo riuscire a creare programmi un pò più semplici,che spostino cartelle e file e che l'utente posso modificare le impostazioni del programma interagendo con dei pulsanti sulle finestre...tipo un programma di installazione
e sono riuscito a fare anche l' ultimo esercizio di questo pdf: http://home.dei.polimi.it/dinitto/Didattica/Info/InfoB0203/EserciziRisolti.pdf
per le api (se non ho capito male questo è solo per le api user)ho letto questo,non sembra difficile ma ancora ci devo lavorare...:http://www.aleax.it/TutWin32/tc.htm
Tempo fà (anni)avevo studiato il vb6(anch'esso da una guida)
COMUNQUE AUGURONI A TUTTI DI BUON NATALE....
Però nella guida che stò studiando c'è scritto che non tutto il c è compatibile con le api e quasi comme fosse un linguaggio diverso.
io ho studiato da questa guida :http://www.blacklight.gotdns.org/wiki/index.php/Cquesta
da premettere che sono coscente del fatto che il c sia molto più complesso di quella semplice guida ,ma a me non interessano fare driver o lavorare sulle reti in c ,ma solo riuscire a creare programmi un pò più semplici,che spostino cartelle e file e che l'utente posso modificare le impostazioni del programma interagendo con dei pulsanti sulle finestre...tipo un programma di installazione
e sono riuscito a fare anche l' ultimo esercizio di questo pdf: http://home.dei.polimi.it/dinitto/Didattica/Info/InfoB0203/EserciziRisolti.pdf
per le api (se non ho capito male questo è solo per le api user)ho letto questo,non sembra difficile ma ancora ci devo lavorare...:http://www.aleax.it/TutWin32/tc.htm
Tempo fà (anni)avevo studiato il vb6(anch'esso da una guida)
COMUNQUE AUGURONI A TUTTI DI BUON NATALE....
Io credo che a prescindere dal tipo di applicazioni che si vuole scrivere, bisognerebbe conoscere bene l'aritmetica dei puntatori, "fondamentale" per scrivere programmi in C. VB così come credo anche il C# offre un livello di astrazione molto alto, che permette di scrivere applicazioni complesse con meno codice e meno complessità, di quanto si farebbe con linguaggio di alto livello (ma relativamente, di livello più basso) come il C. In VB6 è semplice creare finestre con pulsanti e vari componenti della GUI, mentre in C è più complesso. La minore complessità nel creare applicazione, va a discapito delle prestazioni. Se hai necessità di creare applicazioni con GUI molto semplici, non ti conviene programmare in C, continua con il VB, che senza offesa, è talmente semplice da poter essere insegnato anche ad un bambino.
Teo@Unix
24-12-2009, 20:31
:rolleyes: .. mmm .. secondo me .... dovresti cominciare dai principi teorici, metodi del C che è l'ideale per cominciare a capire come "pensa il computer" ... utilizzando un buon manuale di C anche datato ... non importa...
poi fare gli esercizi che trovi alla fine di ogni capitolo e via proseguendo per un periodo di tempo abbastanza lungo direi.....
non penso che ci siano altri metodi.... o almeno io ho fatto così...
cominciare a buttare giù codice con le API così a casaccio non mi sembra un buon piano d'azione insomma...
non dico che non riusciresti .... ma rischieresti di produrre cattivo codice non utilizzando i metodi giusti....
non dico che non riusciresti .... ma rischieresti di produrre cattivo codice non utilizzando i metodi giusti....
Più che altro si troverebbe davanti a problemi enormi nell'uso delle API stesse.
rikkaidd: sai usare l'aritmetica dei puntatori ?
Una delle prime cose che si fanno quando si raggiunge un livello base nella conoscenza del C è ordinare un vettore. Hai fatto queste cose ?
morskott
25-12-2009, 15:33
... Quando ho finito di leggere la guida del c mi sono detto :-ma che schifo è¨ stò linguaggio ...
Dopo il poco che ci ho fatto son giunto alla stessa conclusione!!!
Mo non per innescare una best-programming code-war ma se sei agli inizi eviterei il C. (ma anche se non lo sei agli inizi!!!!!)
Per rimanere in topic ogni cosa che "vedi sullo schermo" può esser fatto in C, dai browsers ai vari programmi più o meno complessi. La domanda è così generica che può ammettere solo risposte generiche. (Anche se, per riallacciarmi alla frase precedente, lo si può fare anche meglio (per il programmatore, il meglio) con altri linguaggi tipi Java, python, C# etc. etc. con meno sbattimenti per chi lo scrive il codice!!!)
Teo@Unix
25-12-2009, 17:26
Mo non per innescare una best-programming code-war ma se sei agli inizi eviterei il C. (ma anche se non lo sei agli inizi!!!!!)
Non mi pare tanto giusto come ragionamento.
Le classi del C++ sono praticamente scritte in C, saper utilizzare il C a prescindere da quello che poi verrà utilizzato per la produzione di programmi veri e propri è importante.
Anzi, anche l'assembler vale la pena studiarsi almeno per sapere le principali funzioni.
Non per niente il primo linguaggio che si insegna è il C.
Una casa da da dove parti a costruirla?
Dalle fondamenta. Il C sono le fondamenta della programmazione. I linguaggi come il C++ e gli altri di più alto livello offrono un livello di astrazione più alto. Ma tutto si basa sulle stesse medesime istruzioni.
A mio avviso partendo dal C++ perderesti di vista ciò che realmente viene eseguito dal sistema operativo.
blackgin
25-12-2009, 17:49
Sono d'accordo con Teo. Il C é sicuramente di piú basso livello rispetto a linguaggi piú moderni e puó presentarsi molto ostico a chi inizia a studiarlo. Peró a mio parere il C é fondamentale per avere buone basi di programmazione. Ti fa capire a fondo cos'é la programmazione.
Il C fa schifo avete scritto. Non riesco a credere di averlo letto. Io lo trovo il miglior linguaggio di programmazione al mondo per due motivi:
1-E' fondato sul principio secondo cui il programmatore sa quello che fa.
2-Permette di tenere sotto controllo ogni aspetto dell'applicazione, permettendo di scrivere codice a basso livello (assembly).
Il SO UNIX è stato scritto in C, X è scritto in C, il kernel Linux, i compilatori della GCC sono scritti in C. Se dagli anni 80 continua ad essere largamente utilizzato un motivo c'è. Inoltre, una qualunque applicazione scritta in un linguaggio compilato è meno performante di una scritta in assembly. Se le prestazioni diminuiscono con un'applicazione in C, possiamo solo immaginare cosa accade con gli altri linguaggi di livello più alto. Ci sono ambiti (es. software di modellazione grafica) in cui un livello di astrazione alto, si rivela indispensabile, ma in tutti gli altri ambiti, il C credo sia d'obbligo.
Non credo abbia molto senso, iniziare a programmare partendo da linguaggi di scripting, o comunque con un livello di astrazione molto alto. Se non si inizia dal C, dubito che in seguito si avranno le capacità di apprendere linguaggio più complessi.
morskott
25-12-2009, 21:11
Non mi pare tanto giusto come ragionamento.
Le classi del C++ sono praticamente scritte in C, saper utilizzare il C a prescindere da quello che poi verrà utilizzato per la produzione di programmi veri e propri è importante.
Anzi, anche l'assembler vale la pena studiarsi almeno per sapere le principali funzioni.
Non per niente il primo linguaggio che si insegna è il C.
Una casa da da dove parti a costruirla?
Dalle fondamenta. Il C sono le fondamenta della programmazione. I linguaggi come il C++ e gli altri di più alto livello offrono un livello di astrazione più alto. Ma tutto si basa sulle stesse medesime istruzioni.
A mio avviso partendo dal C++ perderesti di vista ciò che realmente viene eseguito dal sistema operativo.
Che il C sia potente e ti consente se ben usato di fare in pratica quasi qualsiasi cosa non c'è dubbio. Quello che mi par molto dubbio è la sua "bellezza" come linguaggio, dove per bellezza io intendo facilità di comprensione, di scrittura e di mantenimento. Visto che è molto aderente all'architettura sottostante si è costretti più a pensare a problematiche quali tipo di architettura/compilatore su cui si sviluppa che sulla logica applicativa che si vuol progettare.
Per quanto vero nel suo ambito, la metafora che usi penso che mal si applichi nel reparto informatico, dove (sempre secondo il mio personalissimo parere) penso sia più importante risolvere il problema che ci viene posto che stare appresso a idiosincrasie di un linguaggio che penso nessun può negare sia ostico e molto error-prone.
Per queste motivazioni programmando più ad alto livello con linguaggi tipo Java o C# statisticamente si ha una maggiore efficienza (vado ad intuito dalle mie esperienze sia con Java che (in misura molto minore) con il C(++)) non nell'esecuzione ma nell'implementazione del progetto.
Se posso risolvere un problema con un attrezzo (un linguaggio non è altro che questo) che mi è più facile e mi consente di fare meno errori (non perché più potente, ma perché richiede meno "maestria" nell'utilizzarlo) userò quello!!
Ovviamente se devo risolvere un problema in cui la velocità di esecuzione o ottimizzazioni spinte siano espressamente previste nelle specifiche il C(++) penso che sia la scelta giusta.
L'attrezzo giusto per il lavoro giusto!!
Il C fa schifo avete scritto. Non riesco a credere di averlo letto. Io lo trovo il miglior linguaggio di programmazione al mondo per due motivi:
1-E' fondato sul principio secondo cui il programmatore sa quello che fa.
il che è un assunto non da poco
2-Permette di tenere sotto controllo ogni aspetto dell'applicazione,
Cosa che consentono anche linguaggi più ad alto livello, delle volte nascondono il come, ma questo fa risaltare l'algoritmo
permettendo di scrivere codice a basso livello (assembly).
Il che non è un vantaggio
Il SO UNIX è stato scritto in C, X è scritto in C, il kernel Linux, i compilatori della GCC sono scritti in C. Se dagli anni 80 continua ad essere largamente utilizzato un motivo c'è. Inoltre, una qualunque applicazione scritta in un linguaggio compilato è meno performante di una scritta in assembly. Se le prestazioni diminuiscono con un'applicazione in C, possiamo solo immaginare cosa accade con gli altri linguaggi di livello più alto. Ci sono ambiti (es. software di modellazione grafica) in cui un livello di astrazione alto, si rivela indispensabile, ma in tutti gli altri ambiti, il C credo sia d'obbligo.
Per le prestazioni siamo d'accordo, linguaggi più ad alto livello sono più lenti (ma non di molto) ma il vantaggio ad usarli rende questa non totale velocità non tanto rilevante.
Io rivolterei la tua espressione: dove è necessaria una velocità d'esecuzione o ottimizzazioni create ad hoc su architetture magari non comuni il C è d'obbligo, per tutto il resto c'è Java(C#/Python etc.) :)
Non credo abbia molto senso, iniziare a programmare partendo da linguaggi di scripting, o comunque con un livello di astrazione molto alto. Se non si inizia dal C, dubito che in seguito si avranno le capacità di apprendere linguaggio più complessi.
Di solito l'apprendimento parte dalle cose più semplici e va a finire a cose più complesse, non penso tu abbia imparato prima a correre e poi a camminare, anzi, frustrazioni derivanti da idiosincrasie del C possono fermarti dal continuare ad apprendere.
cdimauro
25-12-2009, 22:01
Non mi pare tanto giusto come ragionamento.
Le classi del C++ sono praticamente scritte in C, saper utilizzare il C a prescindere da quello che poi verrà utilizzato per la produzione di programmi veri e propri è importante.
Anzi, anche l'assembler vale la pena studiarsi almeno per sapere le principali funzioni.
Il linguaggio si chiama assembly. Assembler è il compilatore.
Non per niente il primo linguaggio che si insegna è il C.
Una casa da da dove parti a costruirla?
Dalle fondamenta. Il C sono le fondamenta della programmazione. I linguaggi come il C++ e gli altri di più alto livello offrono un livello di astrazione più alto. Ma tutto si basa sulle stesse medesime istruzioni.
A mio avviso partendo dal C++ perderesti di vista ciò che realmente viene eseguito dal sistema operativo.
Sono d'accordo con Teo. Il C é sicuramente di piú basso livello rispetto a linguaggi piú moderni e puó presentarsi molto ostico a chi inizia a studiarlo. Peró a mio parere il C é fondamentale per avere buone basi di programmazione. Ti fa capire a fondo cos'é la programmazione.
L'errore comune che viene commesso quando si parla di C et similia è che questo tipo di linguaggi rappresenti la "base" della programmazione.
Nulla di più falso. Le basi sono rappresentate dall concetto di dato, di tipo di dato, di variabile, di condizione, di iterazione, ecc.
C e i linguaggi di basso livello in generale sono, invece, più vicini ai DETTAGLI dell'architettura su cui gira il codice.
Il che, come potete capire, è tutt'altra cosa rispetto alle "basi".
Aggiungo che un linguaggio come il C, essendo abbastanza povero a livello di costrutti, costringe ad avere a che fare con dettagli di basso livello. In poche parole: lavorare con costrutti sintattici di basso livello è una necessità, perché non ha altri mezzi.
Esempio classico: non ha il passaggio per riferimento, ma soltanto per valore, per cui si fa ricorso ai puntatori per poter modificare il parametro di una funzione.
Il C fa schifo avete scritto. Non riesco a credere di averlo letto.
Schifo schifo no. Dipende da quello che ci devi fare.
Io lo trovo il miglior linguaggio di programmazione al mondo per due motivi:
1-E' fondato sul principio secondo cui il programmatore sa quello che fa.
Il che è spesso fonte di non pochi errori.
2-Permette di tenere sotto controllo ogni aspetto dell'applicazione, permettendo di scrivere codice a basso livello (assembly).
Assembly e C sono due cose diverse.
Il C non ti permette di scrivere codice di basso livello paragonabile all'assembly, a meno di non ricorrere a particolari estensioni del linguaggio che sopperiscono alle sue intrinseche limitazioni.
Il SO UNIX è stato scritto in C, X è scritto in C, il kernel Linux, i compilatori della GCC sono scritti in C.
Questo non depone certo a suo favore. :asd:
Se dagli anni 80 continua ad essere largamente utilizzato un motivo c'è.
Largamente? Non mi pare proprio. Da tempo altri linguaggi gli hanno soffiato considerevoli quote di mercato.
Inoltre, una qualunque applicazione scritta in un linguaggio compilato è meno performante di una scritta in assembly.
Falso. E non ti sto nemmeno a spiegare il perché (riflettici un po').
Se le prestazioni diminuiscono con un'applicazione in C, possiamo solo immaginare cosa accade con gli altri linguaggi di livello più alto.
Non sempre. Java e C# hanno raggiunto ottime prestazioni, spesso paragonabili al C (e a volte anche superiori).
Ci sono ambiti (es. software di modellazione grafica) in cui un livello di astrazione alto, si rivela indispensabile, ma in tutti gli altri ambiti, il C credo sia d'obbligo.
Il C è meglio usarlo quando esistono specifiche porzioni di un'applicazione che necessitano di migliori prestazioni e/o uso delle risorse.
Oppure per la programmazione di sistema.
Non credo abbia molto senso, iniziare a programmare partendo da linguaggi di scripting, o comunque con un livello di astrazione molto alto. Se non si inizia dal C, dubito che in seguito si avranno le capacità di apprendere linguaggio più complessi.
Non vedo perché. Se parliamo di imparare a programmare e, quindi, di apprendere le basi della programmazione, molto meglio iniziare con un linguaggio di più alto livello che facilita la comprensione dei concetti fondamentali.
Appresi questi e formata la giusta mentalità, passare ad altri linguaggi sarà più semplice.
Assembly e C sono due cose diverse.
Il C non ti permette di scrivere codice di basso livello paragonabile all'assembly, a meno di non ricorrere a particolari estensioni del linguaggio che sopperiscono alle sue intrinseche limitazioni.
il C permette di scrivere codice assembly, se presente in blocchi di istruzioni delimitate da asm {} . Non si tratta di un'estensione aggiunta da qualche compilatore, ma di un'opzione offerta proprio dal linguaggio stesso.
Questo non depone certo a suo favore. :asd:
l'ho scritto in riferimento al fatto che il C è un linguaggio ad uso generico, chiedersi cosa ci si può fare, non ha semplicemente senso.
Falso. E non ti sto nemmeno a spiegare il perché (riflettici un po').
Sicuramente non ho le tue conoscenze e potrei sbagliarmi, ma non vedo come un'applicazione scritta in un linguaggio compilato, possa essere più veloce di una scritta in Assembly. Per prima cosa le istruzioni vengono tradotto in Assembly e quelle risultanti, non rispecchiano quelle che si scriverebbero se si programmasse direttamente in Assembly. Inoltre, i compilatori non traducono le istruzioni del linguaggio ad alto livello con le istruzioni più adatte del set d'istruzioni del processore in uso; mi spiego, Intel ha introdotto il set d'istruzioni SSE4, e non tutte le istruzioni vengono utilizzate, ad esempio da GCC, nonostante permettano di fare operazioni con meno cicli macchina di quanti ne siano necessari utilizzando serie di istruzioni con funzioni analoghe. Forse il compilatore Intel, traduce codice in C sfruttando ogni singola istruzione del set d'istruzioni, ma in ogni caso, non sempre il compilatore tradurrà il codice con le rispettive istruzioni Assembly adatte allo scopo.
Per il resto, sono opinioni personali, e non mi permetto di contraddire nessuno ;)
blackgin
26-12-2009, 10:53
L'errore comune che viene commesso quando si parla di C et similia è che questo tipo di linguaggi rappresenti la "base" della programmazione.
Nulla di più falso. Le basi sono rappresentate dall concetto di dato, di tipo di dato, di variabile, di condizione, di iterazione, ecc.
C e i linguaggi di basso livello in generale sono, invece, più vicini ai DETTAGLI dell'architettura su cui gira il codice.
Il che, come potete capire, è tutt'altra cosa rispetto alle "basi".
Quello che volevo dire io non é che il C insegna il livello base. Ma che con il C si capiscono a fondo i meccanismi di programmazione
Sicuramente non ho le tue conoscenze e potrei sbagliarmi, ma non vedo come un'applicazione scritta in un linguaggio compilato, possa essere più veloce di una scritta in Assembly.
Ha assolutamente ragione, a meno che tu non sia un guru dell'assembly ;)
Generati il sorgente assembly da un compilatore come il GCC utilizzando le ottimizzazioni per architettura e quelle generiche -O3 e poi mi saprai dire.
Il compilatore sa:
- quali istruzioni sono più efficienti da utilizzare su una data architettura (quelle in microcodice o quelle hard-wired ad esempio)
- allocare le unità di esecuzioni e maniera efficiente
- ottimizzare in un passo successivo il codice assembly generato togliendo le istruzioni superflue
- vettorizzare il codice
Nel 90% dei programmi la complessità del codice porta spesso ad utilizzare per una grande percentuale del tempo solamente piccole parti di un programma. Se si cercano le prestazioni la parte eventualmente da provare a scrivere in assembly è quella che viene eseguita più frequentemente. Scrivere le altre parti non ha senso perché non porta a vantaggi apprezzabili.
Inserendo una piccola parte in assembly inline al posto della parte interessata (può essere anche meno di 15 righe di assembly a volte) non è comunque assicurato di ottenere prestazioni maggiore della versione originale ottenuta dal compilatore. La sostituzione ovviamente deve essere mantenuto solo se si ottengono vantaggi.
Quello che volevo dire io non é che il C insegna il livello base. Ma che con il C si capiscono a fondo i meccanismi di programmazione
Il funzionamento di una macchina e i meccanismi della programmazione sono cose completamente diverse.
Dal canto mio credo che il C sia fondamentale nelle conoscenze di un programmatore e che non ci si possa definire tali se non lo si conosce.
Però sono fortemente contrario ad iniziare con il C. Ci sono tanti altri linguaggi più adatti del C per iniziare.
cdimauro
26-12-2009, 13:59
il C permette di scrivere codice assembly, se presente in blocchi di istruzioni delimitate da asm {} . Non si tratta di un'estensione aggiunta da qualche compilatore, ma di un'opzione offerta proprio dal linguaggio stesso.
Si tratta sempre di estensioni del linguaggio.
l'ho scritto in riferimento al fatto che il C è un linguaggio ad uso generico, chiedersi cosa ci si può fare, non ha semplicemente senso.
Non ha nemmeno senso la tua precisazione, perché è applicabile a qualunque linguaggio.
Per il resto, sono opinioni personali, e non mi permetto di contraddire nessuno ;)
Sui gusti non si discute, ci mancherebbe. Sulle questioni prettamente tecniche, invece, il forum nasce apposta per parlarne. :D
Su tutto il resto concordo con Riccardo. ;)
rikkaidd
26-12-2009, 16:23
Più che altro si troverebbe davanti a problemi enormi nell'uso delle API stesse.
rikkaidd: sai usare l'aritmetica dei puntatori ?
Una delle prime cose che si fanno quando si raggiunge un livello base nella conoscenza del C è ordinare un vettore. Hai fatto queste cose ?
Si ho studiato(sempre limitatamente alle guide internet) l'aritmetica dei puntatori e come assegnare un valore ad una variabile tramite puntatore.
Raga,io sono ingnorante riguardo alla programmazione,ok!!!;ma perchè state tutti valorizzando stò C?
Quando è nato il C , sicuramente qualcuno ha scritto l'interprete in assembly, e se questa persona non lo avesse fatto il c non sarebbe nemmeno esistito,come tutti gli altri linguaggi.(ma non è che per caso fate parte della setta del C?)
Meglio il c il vb?;da ignorante dico che dipende da quello che devi fare,se il vb è una scorciatoia per creare la tua applicazione sicuramente ,in quel caso,è meglio del C.
Come dicono sia cionici che cdimauro,è molto meglio iniziare con linguaggi che abbiano molti "automatismi"(vb ,phyton ecc..),per riuscire prima a capire,senza confondersi,cosa sono le costanti e le variabili ,i tipi di dati ,il controllo del flusso di un programma ecc..ecc...(che poi queste cose che ho elencato sono comuni a tutti i linguaggi di programmazione,e se non le avessi già studiate con il vb,col cavolo che le capivo nel manuale del c)
Poi i linguaggi umani ad alto livello c,c++ vb,java etc..,a differenza dell'assembly che è un linguaggio umano ma a basso livello,sono stati inventati per rendere la programmazione a portata di tutti,quindi l'affermazione che i linguaggi con molti automatismi siano inferiori al c è del tutto sbagliata,cosammai sono superiori al c,anche se molti sono stati derivati dal c stesso.
Come dice cionici è anche vero che una persona per definirsi un programmatore deve saper scrivere tutto il codice partendo da zero,senza aver bisogno di "automatismi".(come se uno dicesse:- si conosco l'html,però la pagina internet la sò costruire solo se uso dreamweaver)
Comunque rigrazio tutti,e ci tengo a precisare che sono completamente d'accordo con cionici e cdimauro
Andate tutti a questo indirizzo e guardate cosa è successo: http://www.blacklight.gotdns.org/ ,conteneva manuali di programmazione e hacking
cdimauro
26-12-2009, 18:31
Veramente mi sembra che sei stato proprio tu che sei partito col C aprendo questo thread. :D
Sì, cominciare col C è una pratica da evitare assolutamente. Meglio puntare su un linguaggio di altissimo livello e apprendere le nozioni basilari.
Per farsi del male col C (se necessario) c'è sempre tempo e, soprattutto, con una buona esperienza alle spalle certe cose si affrontano meglio. ;)
rikkaidd
26-12-2009, 20:09
Veramente mi sembra che sei stato proprio tu che sei partito col C aprendo questo thread. :D
Sì, cominciare col C è una pratica da evitare assolutamente. Meglio puntare su un linguaggio di altissimo livello e apprendere le nozioni basilari.
Per farsi del male col C (se necessario) c'è sempre tempo e, soprattutto, con una buona esperienza alle spalle certe cose si affrontano meglio. ;)
Io voglio imparare il C perchè sono masochista!!!!":sbonk:
grigor91
26-12-2009, 20:43
Esempio classico: non ha il passaggio per riferimento, ma soltanto per valore, per cui si fa ricorso ai puntatori per poter modificare il parametro di una funzione.
Io sapevo che nemmeno java e c# hanno il passaggio per riferimento :confused:
rikkaidd
26-12-2009, 21:38
Comunque vi lascio ancora con i miei aguri di buon natale in c:
#include <stdio.h>
int main (void) {
int a=12;
int d=26;
int e=25;
int b;
int c;
do {
printf ("scrivi in che giorno siamo: ");
scanf ("%d", &c);
}while ( c > 0 && c < 0 );
printf ("scrivi in che mese siamo: ");
scanf ("%d",&b);
if(b==a && c==d) {
printf ("Allora, Buon Natale");
} else
if(c==e && b==a) {
printf ("Allora, Buon Natale");
} else
printf ("Ma sei sicuro?");
}
Appositamente senza identazione,e purtroppo ancora eseguibili da linea di comando;ma quando scorpirò i celati misteri delle API ve li manderò anche in formato finestrella :D
X adesso li posso mandare solo con output
#define STRICT
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
int WINAPI
WinMain(HINSTANCE hInst, HINSTANCE hPrevInst,
LPSTR lpCmdLine, int nCmdShow)
{
MessageBox(0, "Buon Natale!", //sto msgbox mi sà di vb :D
"Auguri a tutti", MB_OK);
return 0;
}
||ElChE||88
26-12-2009, 21:54
Io sapevo che nemmeno java e c# hanno il passaggio per riferimento :confused:
Java non ce l'ha.
C# ne ha due tipi: ref e out.
cdimauro
26-12-2009, 22:02
Io voglio imparare il C perchè sono masochista!!!!":sbonk:
Con queste inclinazioni è meglio il linguaggio macchina. :stordita:
Io sapevo che nemmeno java e c# hanno il passaggio per riferimento :confused:
A ||ElChE||88 aggiungo soltanto che era un esempio di funzionalità assente in C, ma non in altri linguaggi staticamente tipati (es: il Pascal).
rikkaidd
26-12-2009, 22:20
Con queste inclinazioni è meglio il linguaggio macchina. :stordita:
Quello nemmeno Neo di matrix lo conosce!!!:ot: lol
cdimauro
27-12-2009, 04:41
Vuol dire che l'eletto non è lui. :cool:
grigor91
27-12-2009, 12:00
Java non ce l'ha.
C# ne ha due tipi: ref e out.
Comunque anche lui di default permette solo il passaggio per valore
A ||ElChE||88 aggiungo soltanto che era un esempio di funzionalità assente in C, ma non in altri linguaggi staticamente tipati (es: il Pascal).
Con Pascal come avviene ciò?
cdimauro
27-12-2009, 12:47
program Prova;
var
x: Integer;
procedure Inc(var Outer: Integer; Value : Integer);
begin
Outer := Outer + Value;
end;
begin
x := 0;
Inc(x, 10);
writeln('x now is: ', x);
end.
Come vedi non c'è da manipolare puntatori et similia.
Il che non significa che non ci siano o che non lo si faccia mai, ma capisci bene che avendo la possibilità di passare parametri per riferimento (preponendo la keyword "var", come dall'esempio), se ne riduce l'uso esclusivamente nei casi in cui è necessario manipolare strutture dati allocate dinamicamente, con enormi vantaggi sia in termini di leggibilità del codice che di sicurezza (tra l'altro il Pascal è fortemente tipizzato, per cui ti spezza le ditine se provi a passare qualsiasi cosa non sia esattamente del tipo che si aspetta come parametro). ;)
grigor91
27-12-2009, 13:04
program Prova;
var
x: Integer;
procedure Inc(var Outer: Integer; Value : Integer);
begin
Outer := Outer + Value;
end;
begin
x := 0;
Inc(x, 10);
writeln('x now is: ', x);
end.
Come vedi non c'è da manipolare puntatori et similia.
Il che non significa che non ci siano o che non lo si faccia mai, ma capisci bene che avendo la possibilità di passare parametri per riferimento (preponendo la keyword "var", come dall'esempio), se ne riduce l'uso esclusivamente nei casi in cui è necessario manipolare strutture dati allocate dinamicamente, con enormi vantaggi sia in termini di leggibilità del codice che di sicurezza (tra l'altro il Pascal è fortemente tipizzato, per cui ti spezza le ditine se provi a passare qualsiasi cosa non sia esattamente del tipo che si aspetta come parametro). ;)
Quindi tramite la keyword var riconosce che la variabile è passata per riferimento e quindi si comporta di conseguenza?
cdimauro
27-12-2009, 13:18
Sì, e se provi a scrivere roba come
Inc(0, 10);
oppure:
var
x: Real;
begin
Inc(x, 10);
end.
Il compilatore ti fucila seduta stante. :D
grigor91
27-12-2009, 13:22
Sì, e se provi a scrivere roba come
Inc(0, 10);
oppure:
var
x: Real;
begin
Inc(x, 10);
end.
Il compilatore ti fucila seduta stante. :D
Come è giusto che sia :D
||ElChE||88
27-12-2009, 13:33
Comunque anche lui di default permette solo il passaggio per valore
Eh?
È esattamente come il C++... se vuoi passare per riferimento ci aggiungi una keyword (& in C++, ref o out in C#).
rikkaidd
27-12-2009, 14:31
Eh?
È esattamente come il C++... se vuoi passare per riferimento ci aggiungi una keyword (& in C++, ref o out in C#).
:eek: Qua mi fate confondere!!!????
Io sapevo che "&" non è una parola riservata come if o else,ma un puntatore
||ElChE||88
27-12-2009, 14:47
:eek: Qua mi fate confondere!!!????
Io sapevo che "&" non è una parola riservata come if o else,ma un puntatore
Dipende dove lo usi...
int a;
int* b = &a
void faiqualcosa(int& boh)
{
return;
}
Nel primo spezzone serve a ottenere l'indirizzo in memoria (puntatore) della variabile a, nel secondo indica che la variabile boh viene passata per riferimento.
Edit: Come detto da me sopra e da cionci sotto questo è C++, non C.
:eek: Qua mi fate confondere!!!????
Io sapevo che "&" non è una parola riservata come if o else,ma un puntatore
Tu stai studiando C e non C++.
& in C è l'operatore di reference, ritorna l'indirizzo di una variabile ed anche l'operatore di and bit a bit.
In C++ serve anche per identificare un parametro passato per riferimento e per dichiarare gli alias.
rikkaidd
27-12-2009, 15:03
:D Insomma stò c++ è più incasinato del C!!!!
Cinonici mi spieghi una cosa che non ho capito:
Prendendo l'esempio di EICHE
int a;
int *b;
b=&a;
*b=100;
mi fai vedere come si utilizza la funzione malloc() per l'allocazione dinamica che non l'ho capita..
:D Insomma stò c++ è più incasinato del C!!!!
Il mio parere è che puoi iniziare e continuare ad approfondire il C che ti darà soddisfazioni e imparerai più da vicino come funziona la macchina, ma comprati un libro o cercalo online, non affidarti solo a dei tutorial scritti in fretta e (forse) male :)
:D Insomma stò c++ è più incasinato del C!!!!
Probabilmente C++ è il linguaggio con più regole di sempre :asd:
Il che ovviamente, non è affatto un bene.
cdimauro
27-12-2009, 17:14
Il mio parere è che puoi iniziare e continuare ad approfondire il C che ti darà soddisfazioni e imparerai più da vicino come funziona la macchina, ma comprati un libro o cercalo online, non affidarti solo a dei tutorial scritti in fretta e (forse) male :)
Ti sei perso un po' di messaggi (e, soprattutto, thread) precedenti: il C è molto meglio lasciarlo perdere per iniziare a programmare.
Probabilmente C++ è il linguaggio con più regole di sempre :asd:
Il che ovviamente, non è affatto un bene.
Attendiamo il C++0x per qualcosa di peggio. :asd:
Certo non è dal numero di regole che si può definire un linguaggio più o meno valido. Al massimo più o meno facile da imparare completamente sì.
:D Insomma stò c++ è più incasinato del C!!!!
Cinonici mi spieghi una cosa che non ho capito:
Prendendo l'esempio di EICHE
int a;
int *b;
b=&a;
*b=100;
mi fai vedere come si utilizza la funzione malloc() per l'allocazione dinamica che non l'ho capita..
Io ho studiato il C con il K&R, e per certi versi, nonostante non sia un linguaggio di grandi dimensioni, ha delle regole abbastanza intricate (es. regole nidificate contenenti ##). Il C++ è molto più complesso e preferisco non studiarlo, in quanto, credo che un programmatore dovrebbe concentrarsi sul problema e non sul linguaggio (che è il mezzo e non il fine). Tenere a mente molte regole è complicato (trovo difficile ricordare persino le regole di associatività degli operatori e le rispettive precedenze), solo con molto esercizio ed esperienza si riesce a gestire una simile complessità (salvo poi gli aggiornamenti del linguaggio). Se vuoi un consiglio, studia il C, il Python, ma non C++.
PS: cionici->cionci in realtà
Se vuoi un consiglio, studia il C, il Python, ma non C++.
Che hanno campi d'uso notoriamente molto simili... :D
domenico88
27-12-2009, 18:10
Ti sei perso un po' di messaggi (e, soprattutto, thread) precedenti: il C è molto meglio lasciarlo perdere per iniziare a programmare.
Attendiamo il C++0x per qualcosa di peggio. :asd:
Scusate se mi intrometto forse non è piacevole però come state dicendo allora io che sto studiando un esame di programmazione in C sto perdendo tempo?boh....
X cionci : Ho capito finalmente la ricorsione......Grazie per la pazienza!!!:D
Scusate se mi intrometto forse non è piacevole però come state dicendo allora io che sto studiando un esame di programmazione in C sto perdendo tempo?boh....
Dal punto di vista didattico vale come qualsiasi altro linguaggio, anzi, imparerai molto più regore e ad essere più preciso. Solo che ci metterai più tempo ;)
Che hanno campi d'uso notoriamente molto simili... :D
Sono entrambi linguaggi ad uso generico, il fatto che Python venga utilizzato prevalentemente come linguaggio di scripting, non lo relega solo a determinati campi.
Sono entrambi linguaggi ad uso generico, il fatto che Python venga utilizzato prevalentemente come linguaggio di scripting, non lo relega solo a determinati campi.
Non lo relega, ma lo si preferisce in quei campi. Evidentemente qualche motivo ci sarà...
Cioè...posso capire consigliare di imparare Python prima del C++, ma non posso capire il consigliare Python al posto del C++.
Cioè...posso capire consigliare di imparare Python prima del C++, ma non posso capire il consigliare Python al posto del C++.
Intendevo, essendo neofita, di optare per Python/C, invece di C++, per poi, magari, impararlo in futuro.
rikkaidd
27-12-2009, 19:15
Ho trovato questa guida che studierò subito: http://www.science.unitn.it/~fiorella/guidac/indexc.html
Si ma io quà sto impazzendo,è impossibile studiare la base senza avere una visione del "tutto".Mi spacco il culo per capire argomenti senza poi nemmeno sapere il loro valore e il loro scopo o a cosa servono;(intendo nella creazione di un programma...spiegatemi voi come io posso associare il calcolo del fattoriale di un numero fatto in C ,x fare un esempio,con un programma d'installazione o masterizzazione)
magari voi che lo studiate all'università e diverso,ma per me che lo stò facendo da autodidatta è una tortura psicologica..per questo voglio studiare subito le api ,appunto per vedere qualcosa di concreto,se poi non capisco qualcosa ritorno al manuale-libro del c..
secondo me ,il miglior modo di insegnare è far vedere un programma completo (intendo un grosso programma) e poi spiegarlo passo passo.
Ho trovato questa guida che studierò subito: http://www.science.unitn.it/~fiorella/guidac/indexc.html
Si ma io quà sto impazzendo,è impossibile studiare la base senza avere una visione del "tutto".Mi spacco il culo per capire argomenti senza poi nemmeno sapere il loro valore e il loro scopo o a cosa servono;(intendo nella creazione di un programma)
magari voi che lo studiate all'università e diverso,ma per me che lo stò facendo da autodidatta è una tortura psicologica..per questo voglio studiare subito le api ,appunto per vedere qualcosa di concreto,se poi non capisco qualcosa ritorno al manuale-libro del c..
secondo me ,il miglior modo di insegnare è far vedere un programma completo (intendo un grosso programma) e poi spiegarlo passo passo.
Il K&R (The C Programming Language Dennis Ritchie & Brian Kernighan) si basa proprio su questo, programmi utili per far comprendere i vari spetti del linguggio. Se devi creare un programma con GUI, devi avere la pazienza e la costanza di studiare interamente il linguaggio, per poi studiare la documentazione legata alle API. Dubito che riusciresti a comprendere a fondo un programma che facesse utilizzo di API, senza prima conoscere il linguaggio in se.
secondo me ,il miglior modo di insegnare è far vedere un programma completo (intendo un grosso programma) e poi spiegarlo passo passo.
No, non è possibile, te lo assicuro. Certe volte è già difficile capire cosa fa un programma grosso per chi lo ha creato qualche anno prima, figurati per chi non conosce il linguaggio di programmazione.
Secondo me andare sulle API non ha senso in questo momento, ha più senso invece affrontare e risolvere problemi semplici, di stile matematico e statistico ad esempio. Oppure risolvere piccoli problemi, diciamo, quotidiani.
Tra quelli matematici e statistici:
- trovare media, mediana, frequenze e varianza in un vettore
- risolvere l'equazione caratteristica di un polinomio di secondo grado
- trovare l'intersezione di due rette
- generare tutte le possibili combinazioni, permutazioni di una serie di numeri
- etc etc, ce ne sono a bizzeffe
Altro tipo di problemi:
- gestire un rubrica telefonica
- gestire una biblioteca
- rubrica appuntamenti
Puoi implementare l'algoritmo quicksort per ordinare un vettore, magari tramite l'uso di puntatori.
rikkaidd
27-12-2009, 20:11
Puoi implementare l'algoritmo quicksort per ordinare un vettore, magari tramite l'uso di puntatori.
:confused:
Il C fa schifo avete scritto. é troppo semplice: quando programmo in C io francamente mi sento castrato, non c'é niente rispetto a qualunque altro linguaggio moderno.
1-E' fondato sul principio secondo cui il programmatore sa quello che fa. questa frase non vuol dire niente a meno che tu non abbia qualcosa con cui spiegarla meglio.
2-Permette di tenere sotto controllo ogni aspetto dell'applicazione, permettendo di scrivere codice a basso livello (assembly). assolutamente no: __asm e costrutti simili non sono standard ed il C non é assolutamente legato ad una particolare architettura.
Il SO UNIX è stato scritto in C, e fa schifo
il kernel Linux, e fa schifo
i compilatori della GCC sono scritti in C. e fanno schifo. dei tre esempi il primo é un sistema operativo di 40 anni fa (é normale che 40 anni fa si usassero strumenti schifosi, 40 anni sono un'eternitá in questo settore, pensa che prima di Unix i sistemi operativi si scrivevano in assembly e funzionavano su una sola macchina), il secondo ha un codice ingestibile ed immanutenibile per ammissione degli stessi sviluppatori ed il terzo purtroppo non ho argomentazioni valide ma so che soffre dello stesso problema per sentito dire :D (anzi, per aver letto su questo forum, casomai provo a cercare il post).
Se dagli anni 80 continua ad essere largamente utilizzato un motivo c'è. si, l'inerzia tecnologica. non é che dall'oggi al domani si puó passare al .NET purtroppo.
Inoltre, una qualunque applicazione scritta in un linguaggio compilato è meno performante di una scritta in assembly. dimostrazione formale prego; e mi raccomando rigore, grazie.
cominciamo col definire l'assembly di quale macchina.
Se le prestazioni diminuiscono con un'applicazione in C, possiamo solo immaginare cosa accade con gli altri linguaggi di livello più alto. perché non ce lo dici tu?
io so che in linea di principio i programmi garbage-collected a volte hanno prestazioni molto superiori agli altri perché rimandano le operazioni di deallocazione a momenti di maggiore disponibilitá di risorse di calcolo.
Ci sono ambiti (es. software di modellazione grafica) in cui un livello di astrazione alto, si rivela indispensabile, ma in tutti gli altri ambiti, il C credo sia d'obbligo. argomentare, grazie.
Non credo abbia molto senso, iniziare a programmare partendo da linguaggi di scripting, o comunque con un livello di astrazione molto alto. Se non si inizia dal C, dubito che in seguito si avranno le capacità di apprendere linguaggio più complessi. avrai di che stupirti allora: un giorno il C neanche esisterá piu, e non ne avremo un bel ricordo.
ma per curiositá: a che titolo ci dispensi perle a carattere didattico come ad esempio il fatto che per imparare a programmare bisogna per forza partire dal C? hai mai provato ad insegnare a programmare? l'hai mai fatto dovendo insegnare il C come linguaggio? forse sbaglio ma non credo proprio... sbaglio?
Dal canto mio credo che il C sia fondamentale nelle conoscenze di un programmatore e che non ci si possa definire tali se non lo si conosce. quindi un giorno non esisteranno piu programmatori? stento a credere che il C avrá vita eterna.
e fa schifo
e fa schifo
e fanno schifo. dei tre esempi il primo é un sistema operativo di 40 anni fa (é normale che 40 anni fa si usassero strumenti schifosi, 40 anni sono un'eternitá in questo settore, pensa che prima di Unix i sistemi operativi si scrivevano in assembly e funzionavano su una sola macchina), il secondo ha un codice ingestibile ed immanutenibile per ammissione degli stessi sviluppatori ed il terzo purtroppo non ho argomentazioni valide ma so che soffre dello stesso problema per sentito dire :D (anzi, per aver letto su questo forum, casomai provo a cercare il post).
Scusa, ma posso ridere ? Credi che il sorgente di Windows sia più facile da manutenere ? Ricordo che è scritto parte in C e parte in C++.
Ma metti un bel "a me" davanti alle tue affermazioni, altrimenti qualcuno potrebbe davvero crederti :D
é troppo semplice: quando programmo in C io francamente mi sento castrato, non c'é niente rispetto a qualunque altro linguaggio moderno.
Perché tu stai semplicemente cercando nel C quello che nel C non c'è. Cioè un framework. Ecco perché secondo me la gente si abitua male con la pappa pronta :D Non dico che linguaggi con framework immensi siano il male, il male è la gente che non è abituata a spremersi le meningi quando non c'è a disposizione un framwork ampio.
Comincia ad usare qualche libreria esterna e vedrai che con il C avrai a disposizione già pronta qualsiasi funzionalità tu desideri.
cdimauro
28-12-2009, 07:17
il terzo purtroppo non ho argomentazioni valide ma so che soffre dello stesso problema per sentito dire :D (anzi, per aver letto su questo forum, casomai provo a cercare il post).
Qualche anno fa postai alcuni spezzoni di codice presi dal GCC, ma se non ricordo male era nella sezione News (non qui in Programmazione).
La mia impressione è quella di un prodotto fatto veramente male. Qualità del codice scarsa.
Tanto che quelli *BSD hanno rispolverato un vecchio compilatore C e lo stanno riadattando per usarlo al posto di GCC, che a loro dire fa veramente pena.
Scusa, ma posso ridere ? Credi che il sorgente di Windows sia più facile da manutenere ? Ricordo che è scritto parte in C e parte in C++.
Questo non è importante ai fini della manutenibilità.
Comunque quando, tempo fa, fuoriuscì una parte dei sorgenti di Windows (2000, con alcune parti di XP) diedi un'occhiata ad alcuni file e li trovai scritti molto bene.
Perché tu stai semplicemente cercando nel C quello che nel C non c'è. Cioè un framework. Ecco perché secondo me la gente si abitua male con la pappa pronta :D Non dico che linguaggi con framework immensi siano il male, il male è la gente che non è abituata a spremersi le meningi quando non c'è a disposizione un framwork ampio.
Comincia ad usare qualche libreria esterna e vedrai che con il C avrai a disposizione già pronta qualsiasi funzionalità tu desideri.
Non è questo il punto. E' che sintatticamente il codice lo scriverai sempre allo stesso modo.
Tanto per fare un esempio, se hai una libreria che ti gestisce gli hash/mappe/dizionari, non è che puoi utilizzarla come faresti in C++ (o in altri linguaggi). Continuerai a richiamare funzioni e passargli parametri.
Sintatticamente il C è un linguaggio povero. E tale rimarrà.
Ti sei perso un po' di messaggi (e, soprattutto, thread) precedenti: il C è molto meglio lasciarlo perdere per iniziare a programmare.
A prescindere dal numero dei messaggi io ho espresso la mia opinione.
Se qualcuno vuole imparare a programmare con il C per me è una soluzione come un'altra. I suoi primi giochi con strutture di controllo, funzioni e qualche libreria di manipolazione di immagini che li faccia con C, con python o con perl poco cambia.
Poi a seconda di quello che interessa ci si può muovere in una direzione o in un'altra...
Ho trovato questa guida che studierò subito: http://www.science.unitn.it/~fiorella/guidac/indexc.html
Si ma io quà sto impazzendo,è impossibile studiare la base senza avere una visione del "tutto".Mi spacco il culo per capire argomenti senza poi nemmeno sapere il loro valore e il loro scopo o a cosa servono;(intendo nella creazione di un programma...spiegatemi voi come io posso associare il calcolo del fattoriale di un numero fatto in C ,x fare un esempio,con un programma d'installazione o masterizzazione)
Un passo alla volta ci arrivi! Spulcia nelle dispense di varie università, ad esempio qui:
Library to create, read and write true-color bitmap files (.BMP, 24 bits/pixel, uncompressed), with few examples : http://web.diegm.uniud.it/pierluca/public_html/teaching/fpac/strumenti/librerie/bmplib/
capisci come interagire con una immagine bitmap tramite una semplicissima libreria, che ti fa toccare con mano qualcosa di più utile di un fattoriale. Poi prosegui :)
cdimauro
28-12-2009, 08:24
Mi spiace, ma non concordo assolutamente. Cambia, e pure molto, l'approccio a seconda del linguaggio.
Esempio pratico: in Python non hai i puntatori e non avrai a che fare con segmentation fault, double delete, e bug a intermittenza tipici dei problemi di gestione della memoria.
Viceversa, data la povertà sintattica del C, sarai costretto a utilizzare molto spesso i puntatori e a scontrarti con queste problematiche.
Imparare a programmare col C è decisamente frustrante. Molto meglio affidarsi a un linguaggio che permetta di concentrarti sui concetti di base (che ho elencato qualche messaggio fa) senza doverti scontrare con roba come questa (che è intrinsecamente legata al linguaggio, appunto).
Mi spiace, ma non concordo assolutamente. Cambia, e pure molto, l'approccio a seconda del linguaggio.
Esempio pratico: in Python non hai i puntatori e non avrai a che fare con segmentation fault, double delete, e bug a intermittenza tipici dei problemi di gestione della memoria.
Viceversa, data la povertà sintattica del C, sarai costretto a utilizzare molto spesso i puntatori e a scontrarti con queste problematiche.
Imparare a programmare col C è decisamente frustrante. Molto meglio affidarsi a un linguaggio che permetta di concentrarti sui concetti di base (che ho elencato qualche messaggio fa) senza doverti scontrare con roba come questa (che è intrinsecamente legata al linguaggio, appunto).
Ok, ho letto e capisco le tue argomentazioni e ovviamente non pretendo che nessuno sia d'accordo con me :)
Riportavo la mia visione della cosa, preferendo un approccio un po' più "violento" all'inizio rispetto all'affidarsi a maggiori astrazioni.
blackgin
28-12-2009, 11:07
e fa schifo
e fa schifo
e fanno schifo.
Non pensavo questo fosse un topic di barzellette
Ecco un'altra delle migliaia discussioni sul C/C++ contro tutti. Come ho detto un sacco di volte,non ha senso comparare il C con Python o Java o C#. E' più vecchio di 30 anni, è NORMALE che non abbia tutte le meraviglie che ci sono adesso. Non ha il minimo senso fare un confronto.
Detto questo, migliaia di applicazioni fondamentali sono scritte in C/C++ ad esempio svariati kernel, protocolli di rete, drivers ecc.ecc. Questo sia per ragioni storiche che di efficienza. Perché si, il C fa schifo sintatticamente, ma è estremamente veloce se scritto bene, non c'è paragone con gli altri. Anche a livello di memoria utilizzata. Ad esempio, nel mio lavoro devo usare anche Fortran perché la velocità di esecuzione nel mio contesto è fondamentale. Ma per avere queste differenze bisogna fare ottimizzazioni molto spinte sia a livello di kernel di calcolo che a livello di compilatore. Ma vi garantisco che fatto questo non c'è storia. Altrimenti non è detto. Il mio però è un caso molto particolare che non si applica a tutti i contesti. Però ad esempio Fortran mi fa schifo e scommetto che quasi tutti in questo forum neanche lo hanno mai visto :D
Ogni linguaggio ha il suo campo. Non userei mai Fortran per fare un applicativo web ( anzi, penso che sia impossible :D ) Come non userei mai Python o C# per fare un kernel di calcolo davvero spinto. Questo pur essendo d'accordissimo sulla bontà di questi linguaggi.
Quello che si inizia a vedere nel mio campo sono wrapper scritti in Python di kernel di calcolo fatti in C/C++. Ecco, in questo caso è davvero utile Python, però il cuore del programma resta in C/C++. In questo modo utilizzi le meraviglie di Python con la pura potenza di calcolo di C/C++, o Fortran
Se l'alternativa a C è .NET mi tatuo il K&R sulla pelata.
cdimauro
28-12-2009, 13:50
PGI, anche tu? :mad:
.NET NON è un linguaggio!
Ryuzaki_Eru
28-12-2009, 13:57
Lo sapevo che dovevo venire qua se mi volevo divertire qualche minuto :asd:
morskott
28-12-2009, 14:26
Lo sapevo che dovevo venire qua se mi volevo divertire qualche minuto :asd:
Perché qualcuno si ostina ancora a dire che il C è un ottimo linguaggio, da santificare subito e chi non lo conosce deve spararsi (un K&K) in bocca!!!
Perché qualcuno si ostina ancora a dire che il C è un ottimo linguaggio, da santificare subito e chi non lo conosce deve spararsi (un K&K) in bocca!!!
C non è un ottimo linguaggio comparato agli attuali linguaggi OO, ma rimane in ogni caso il più usato linguaggio non OO attualmente, anche molto più di altri linguaggi OO. Di conseguenza deve essere nel bagaglio culturale di un programmatore (come Java, C#, C++ e una minima conoscenza di ASM).
Inoltre ti mette davanti a certe situazioni che altrimenti non affronteresti e di conseguenza è altamente formante in questi frangenti.
PGI, anche tu? :mad:
Una parola: piattaforma.
rikkaidd
28-12-2009, 19:04
Un passo alla volta ci arrivi! Spulcia nelle dispense di varie università, ad esempio qui:
Library to create, read and write true-color bitmap files (.BMP, 24 bits/pixel, uncompressed), with few examples : http://web.diegm.uniud.it/pierluca/public_html/teaching/fpac/strumenti/librerie/bmplib/
capisci come interagire con una immagine bitmap tramite una semplicissima libreria, che ti fa toccare con mano qualcosa di più utile di un fattoriale. Poi prosegui :)
GRAZIE!. Magari tutti fossero come te!!!Anziché aiutarmi o mandarmi materiale da studiare stanno generando una specie di flame war,tra la fazione del C e la fazione dell'anti C.. a me stò C non sò perchè mi ricorda un pò la juve di Moggi....
Scusa, ma posso ridere ? Credi che il sorgente di Windows sia più facile da manutenere ? Ricordo che è scritto parte in C e parte in C++.
Ma metti un bel "a me" davanti alle tue affermazioni, altrimenti qualcuno potrebbe davvero crederti :D primo, io gli IMHO non li uso mai perché non ho una bassa considerazione della mia opinione e perché se qualcosa la scrivo io é chiaro che é perché la penso io.
secondo, chi ha parlato di Windows? tu che naturalmente ne hai letto i sorgenti?
terzo, per la cronaca ho avuto anche io un'esperienza simile a quella di cdimauro: mi pare che fosse nel 2003 che trovai un famoso grosso pezzo di kernel NT leakato su qualche rete di P2P.
Perché tu stai semplicemente cercando nel C quello che nel C non c'è. si, il concetto mi era chiaro, era proprio quello di cui mi lamentavo... troppe cose mancano in un linguaggio di 40 anni fa.
Cioè un framework. e invece a quanto pare sei tu quello che non ha chiaro il concetto: non l'ho esplicitato ma io mi stavo limitando al solo linguaggio, le carenze che il C accusa sono svariate: la gestione della memoria deve essere fatta manualmente, il sistema dei tipi non prevede classi, non prevede generics o templates, e non é possibile associare la vita di una risorsa allo scope di una variabile. poi certo, anche l'assenza di un framework decente é una carenza grave: niente collection classes, fantastico; non si contano le volte che ho dovuto realizzare a mano delle hash tables (e dovró farlo ancora purtroppo), c'é da spararsi.
Ecco perché secondo me la gente si abitua male con la pappa pronta :D Non dico che linguaggi con framework immensi siano il male, il male è la gente che non è abituata a spremersi le meningi quando non c'è a disposizione un framwork ampio. facciamo finta che queste frasi non siano mai state scritte... :mc:
Comincia ad usare qualche libreria esterna e vedrai che con il C avrai a disposizione già pronta qualsiasi funzionalità tu desideri. purtroppo a volte ci sono delle specifiche ben precise che non mi lasciano cosi tante libertá (faccio l'universitá) e quando in futuro non avró piu queste specifiche puó darsi che non abbia mai piu ad usare il C in tutta la mia vita.
Questo non è importante ai fini della manutenibilità. appunto, tra l'altro.
Comunque quando, tempo fa, fuoriuscì una parte dei sorgenti di Windows (2000, con alcune parti di XP) diedi un'occhiata ad alcuni file e li trovai scritti molto bene. fosse anche solo per la nomenclatura, guarda. io giuro che non capisco cosa ci guadagnano certi dementi a chiamare una funzione printf, fgets, recv, fork, sync, mkdir, utime, ... a pronunciarle uno sembra malato.
Come ho detto un sacco di volte,non ha senso comparare il C con Python o Java o C#. E' più vecchio di 30 anni, è NORMALE che non abbia tutte le meraviglie che ci sono adesso. Non ha il minimo senso fare un confronto. infatti, anche secondo me; peró la gente che pensa che il C dovrebbe sostituire linguaggi piu moderni e completi ancora campa. c'é gente che non capisce che ormai il C praticamente puó essere relegato esclusivamente a contesti legacy, cioé contesti dove non ci sono alternative.
Perché si, il C fa schifo sintatticamente, ma è estremamente veloce se scritto bene, non c'è paragone con gli altri. il C é solo un linguaggio, cioé un mucchio di regole, e pertanto non ha senso stimarne le performance. semmai é possibile dire che i compilatori C e C++ ormai sono strumenti molto maturi e quindi riescono a generare codice assembly estremamente efficiente, ma da questo discorso non escluderei il C++.
Se l'alternativa a C è .NET mi tatuo il K&R sulla pelata. senti eh: mi riesce difficile credere che qualcuno sulla terra abbia una produttivitá mediamente maggiore col C che con un qualunque linguaggio basato su .NET :D
io non ho mai provato un fenomeno simile, nel senso che non sono mai riuscito a fare qualcosa (qualunque cosa) col C in meno tempo che con C#. innumerevoli volte peró é successo l'opposto, cioé ho impiegato eternitá (sostantivo plurale) a scrivere in C qualcosa che in C# avrei fatto in pochi minuti. ritengo che sia un'esperienza estremamente comune.
rikkaidd
28-12-2009, 22:55
C'è qualcuno che sà indicarmi una guida sulla funzione system,ho trovato poche cose in rete e se non ho capito male permette di usare i comandi dos.
serve a lanciare un comando della shell del sistema.
http://www.linuxmanpages.com/man3/system.3.php
aveva senso quando i sistemi non avevano la shell grafica e avevano una sola shell di testo.
primo, io gli IMHO non li uso mai perché non ho una bassa considerazione della mia opinione e perché se qualcosa la scrivo io é chiaro che é perché la penso io.
Tu hai detto che Unix, Linux e Gcc fanno schifo. Non come manutenibilità, ma in generale. Renditi bene conto delle tue affermazioni.
Non usare i "secondo me" è un ottimo modo per prendere delle belle cantonate, te lo assicuro. Ricordati che c'è sempre qualcuno che è più bravo di te e che ha più esperienza di te su questa terra.
e invece a quanto pare sei tu quello che non ha chiaro il concetto: non l'ho esplicitato ma io mi stavo limitando al solo linguaggio, le carenze che il C accusa sono svariate
Sono tutte cose perfettamente accettabili, anzi necessarie, per gli usi che il linguaggio ha e dovrà avere in futuro.
purtroppo a volte ci sono delle specifiche ben precise che non mi lasciano cosi tante libertá (faccio l'universitá) e quando in futuro non avró piu queste specifiche puó darsi che non abbia mai piu ad usare il C in tutta la mia vita.
Quando avrai finito di seguire quelle specifiche probabilmente ti sarai reso conto di aver imparato qualcosa. C'è sempre da imparare qualcosa da chi ha più esperienza di te.
Forse ce l'hai così tanto con il C perché hai dei problemi a scriverci codice corretto. Magari proprio perché sei abituato troppo "bene" con linguaggi di più alto livello ?
Ti sfido a dire che il C non è formante, anche per chi conosce già C#, Java e Python.
il C é solo un linguaggio, cioé un mucchio di regole, e pertanto non ha senso stimarne le performance. semmai é possibile dire che i compilatori C e C++ ormai sono strumenti molto maturi e quindi riescono a generare codice assembly estremamente efficiente, ma da questo discorso non escluderei il C++.
Non è così, sono proprio le regole imposte dallo standard a farne un linguaggio efficiente.
senti eh: mi riesce difficile credere che qualcuno sulla terra abbia una produttivitá mediamente maggiore col C che con un qualunque linguaggio basato su .NET :D
Però ci sono cose che in C# non si possono fare, mentre in C sì ;)
Tu releghi troppo la tua esperienza informatica al solo Windows.
sempre le solite guerre,io trovo che ogni linguaggio è specifico nel proprio ambito, utilizzo abitualmente c++ e c# e trovo c# nettamente più veloce nel caso serva scrivere una qualunque applicazione per windows,
riguardo al c, sto iniziando a studiarlo in questi giorni perchè devo lavorare con degli atmega 128 e lo trovo parecchio arcaico (ps se conoscete una buona guida / manuale da consigliarmi mandatemi un pm)
detto questo trovo il c non il linguaggio ideale per formare, meglio partire con qualcosa di più semplice per insegnare le basi e poi passare direttamente agli oo magari con il c++ che da sempre è una buona scuola ma solo dopo che si ha una certa esperienza altrimenti sei bloccato al primo segmentation fault XD
riguardo al c, sto iniziando a studiarlo in questi giorni perchè devo lavorare con degli atmega 128 e lo trovo parecchio arcaico (ps se conoscete una buona guida / manuale da consigliarmi mandatemi un pm)
Però non glielo dire a fero86 che i microcontrollori non si possono programmare in C# ;)
detto questo trovo il c non il linguaggio ideale per formare
Perfettamente d'accordo.
Per gli amanti di Python ricordo che lo stesso Python è scritto in C ;)
Anche Java se non ricordo male. Chiedetevi come mai sono stati scritti in C e non con altro. Performances forse? Mah...
Quindi, anche se il C vi fa schifo, potete scriverci roba potentissima e poi utilizzare quelle anziché direttamente il C.
C# non so con cosa sia stato scritto, ma non mi stupirei se anche quello fosse stato scritto in C.
Riguardo alla mantenibilità del codice, questa dipende in gran parte dal programmatore stesso. Puoi scrivere roba illeggibile con qualsiasi linguaggio.
grigor91
29-12-2009, 11:32
Riguardo alla mantenibilità del codice, questa dipende in gran parte dal programmatore stesso. Puoi scrivere roba illeggibile con qualsiasi linguaggio.
Certo,ma con il C è facile scrivere codice illeggibile, con altri linguaggi bisogna impegnarsi...
Per gli amanti di Python ricordo che lo stesso Python è scritto in C ;)
Anche Java se non ricordo male. Chiedetevi come mai sono stati scritti in C e non con altro. Performances forse? Mah...
Quindi, anche se il C vi fa schifo, potete scriverci roba potentissima e poi utilizzare quelle anziché direttamente il C.
C# non so con cosa sia stato scritto, ma non mi stupirei se anche quello fosse stato scritto in C.
Riguardo alla mantenibilità del codice, questa dipende in gran parte dal programmatore stesso. Puoi scrivere roba illeggibile con qualsiasi linguaggio.
Scrivere un linguaggio non ha molto senso, se parli dell'implementazione, allora è un altro paio di maniche.
Inoltre, se l'implementazione di linguaggi come Java e Python sia stata realizzata in C, non significa che il C sia più potente. Per implementare un linguaggio devi utilizzare un altro linguaggio, così come per scrivere un compilatore hai bisogno di un altro compilatore. E' una sorta di bootstrap.
Certo,ma con il C è facile scrivere codice illeggibile, con altri linguaggi bisogna impegnarsi...
Questo è molto relativo, se ti riferisci a costrutti come goto (utilizzati impropriamente) allora hai ragione. Se ti riferisci all'aspetto grafico del linguaggio, allora no, in quanto:
1-Il linguaggio è indipendente dall'aspetto grafico e non vedo come linguaggi diversi possano evitare di scrivere codice offuscato.
2-La maggior parte degli IDE attualmente, implementa editor di testo che indentano e completano automaticamente le istruzioni, il che rende difficile scrivere codice di difficile comprensione.
Scrivere un linguaggio non ha molto senso, se parli dell'implementazione, allora è un altro paio di maniche.
Inoltre, se l'implementazione di linguaggi come Java e Python sia stata realizzata in C, non significa che il C sia più potente. Per implementare un linguaggio devi utilizzare un altro linguaggio, così come per scrivere un compilatore hai bisogno di un altro compilatore. E' una sorta di bootstrap.
Si fanno due cose quando si scrive un linguaggio (e questa è storia), si scrive il compilatore con un linguaggio preesistente e dopo si scrive il compilatore stesso nel linguaggio appena creato compilandolo con il vecchio compilatore.
Per quale motivo il compilatore Python non viene riscritto in Python ? Evidentemente qualche motivazione ci sarà ;)
Con questo non voglio dire che il C sia meglio di Python, ma voglio ribadire che ogni linguaggio debba essere usato per gli scopi per cui il suo utilizzo è ottimale.
Questo è molto relativo, se ti riferisci a costrutti come goto (utilizzati impropriamente) allora hai ragione. Se ti riferisci all'aspetto grafico del linguaggio, allora no, in quanto:
Forse si riferisce alla comprensibilità. In tal caso sicuramente quella del C dipende molto dalla volontà e dalla bravura del programmatore, molto di più che in altri linguaggi.
Per quale motivo il compilatore Python non viene riscritto in Python ? Evidentemente qualche motivazione ci sarà ;)
A dir la verità, googlando un pò, vedo che stanno riscrivendo Python in Python:
http://codespeak.net/pypy/dist/pypy/doc/
Ma non penso che avrà le stesse performances :stordita:
Scrivere un linguaggio non ha molto senso, se parli dell'implementazione, allora è un altro paio di maniche.
Inoltre, se l'implementazione di linguaggi come Java e Python sia stata realizzata in C, non significa che il C sia più potente. Per implementare un linguaggio devi utilizzare un altro linguaggio, così come per scrivere un compilatore hai bisogno di un altro compilatore. E' una sorta di bootstrap.
Non dico che sia più potente, ma perché Python non lo hanno scritto che so, in Java? Perché proprio in C? Principalmente per problemi di performances, è ovvio ;)
Certo,ma con il C è facile scrivere codice illeggibile, con altri linguaggi bisogna impegnarsi...
No, basta iniziare a scrivere conoscendo poco il linguaggio in esame, o addirittura conoscendo poco la programmazione.. E non sono pochi, credimi.
Non dico che sia più potente, ma perché Python non lo hanno scritto che so, in Java? Perché proprio in C? Principalmente per problemi di performances, è ovvio ;)
Quindi, sei d'accordo con fero86, riguardo all'utilizzo del C solo nei contesti legacy. Giusto?
Quindi, sei d'accordo con fero86, riguardo all'utilizzo del C solo nei contesti legacy. Giusto?
Certo, ad ogni linguaggio il proprio campo. Lo dico dal primo intervento in questo thread :p
Come ho scritto prima, nel mio campo, dove la velocità di esecuzione ha la priorità assoluta, è d'obbligo usare C e FORTRAN (:eek: :eek: )
Già con il C++ storcono il naso.
A dir la verità, googlando un pò, vedo che stanno riscrivendo Python in Python:
http://codespeak.net/pypy/dist/pypy/doc/
Ma non penso che avrà le stesse performances :stordita:
Chiaramente ;)
Ripeto, il primo passo che sì fa non appena si è creato il compilatore/interprete per un dato linguaggio è proprio riscrivere il compilatore/interprete stesso. Non l'hanno fatto subito proprio per le prestazioni.
Quindi, sei d'accordo con fero86, riguardo all'utilizzo del C solo nei contesti legacy. Giusto?
Sai vero cosa si intende per contesti legacy ?
Perché nessuno degli ultimi esempi che abbiamo visto (compilatori/interpreti e microcontrollori) è un contesto legacy ;)
I contesti legacy sono quelli legati alla manutenzione e aggiornamento di software e sistemi preesistenti.
Chiaramente ;)
Ripeto, il primo passo che sì fa non appena si è creato il compilatore/interprete per un dato linguaggio è proprio riscrivere il compilatore/interprete stesso. Non l'hanno fatto subito proprio per le prestazioni.
Figata! Per i compilatori capisco, ma per gli interpreti non è ricorsivo? :D
Figata! Per i compilatori capisco, ma per gli interpreti non è ricorsivo? :D
In effetti :doh:
Poi dipende cosa si va ad interpretare. Quando questi linguaggi interpretati hanno veri e propri compilatori JIT la cosa diventa più che interessante.
Metti caso che il linguaggio interpretato abbia una virtual machine di riferimento, si può benissimo scrivere il codice della virtual machine in linguaggio di basso livello, mentre il compilatore JIT che genera codice per la virtual machine si può scrivere nel linguaggio interpretato.
Sai vero cosa si intende per contesti legacy ?
Perché nessuno degli ultimi esempi che abbiamo visto (compilatori/interpreti e microcontrollori) è un contesto legacy ;)
I contesti legacy sono quelli legati alla manutenzione e aggiornamento di software e sistemi preesistenti.
Infatti no, non lo sapevo :asd:
Comunque il discorso era quello del linguaggio legato ad un certo ambito, infatti, Unrue, ha poi spiegato il suo pensiero ;)
Comunque il discorso era quello del linguaggio legato ad un certo ambito, infatti, Unrue, ha poi spiegato il suo pensiero ;)
Ogni linguaggio è legato al proprio ambito di utilizzo ;)
B|4KWH|T3
29-12-2009, 19:06
fosse anche solo per la nomenclatura, guarda. io giuro che non capisco cosa ci guadagnano certi dementi a chiamare una funzione printf, fgets, recv, fork, sync, mkdir, utime, ... a pronunciarle uno sembra malato.
Tu ti rendi conto di che tipo di calcolatore (o terminale) si aveva a disposizione quando 40 anni fa sono state ideati quegli strumenti?
Ovvero: sai di cosa stai parlando?
rikkaidd
29-12-2009, 19:27
Ringrazio ancora tutti dei buoni consigli ricevuti,però ho ancora bisogno di un altro aiuto.
Ho deciso di comprare un libro sul C ed uno ,premesso che si trovi, sulle api di windows(naturalmente utilizzate con il C); ma non ho la più pallida idea di cosa comprare.
Se cortesemente mi volete indirizzare su dei buoni libri tenendo ,per quanto possibile , in cosiderazione questi quattro punti:
1)Userò esclusivamente windows(di conseguenza la parte linux ,o la compatibilità del codice con quest'ultimo,non mi interessa;ma non perchè considero linux inferiore a windows)
2)Già il solo studiare il C mi fà venire il malditesta,figuriamoci se il libro è in inglese.
3) Che all'interno del libro non sia dato niente per scontato e non ci siano delle frasi come:
a) non hanno per ora importanza
b) fortunatamente possiamo rimandare la siegazione di questo elemento al capitolo x
(perchè perdo il filo e non ci capisco più una mazza,quindi preferisco codice-spiegazione diretta)
4)Che a vostro parere sia sintetico e comprensibile,e soprattutto che non si perda in vani sproloqui e inutili considerazioni personali..
Scusate se chiedo troppo!:D
Consiglio: imparati prima il C e dopo le API. Dal mio punto di vista le API di Windows sono sicuramente interessanti da un punto di vista didattico, ma attualmente di gente che programma le interfacce con le API di Windows ce n'è veramente, ma veramente poca. Già erano pochi 5-6 anni fa.
Con gli strumenti attuali (editor RAD, .Net, Qt) e i linguaggi attuali (C++, C#, Vb.Net, Java, Python) non c'è rimasto più nessuno che le usa. I motivi sono ovvi: per fare quello che si fa con un framework di alto livello in due istruzioni, con le API ti ci vogliono 10 istruzioni, 5 handle, 2 messaggi e la gestione degli stessi.
Le API vengono ora utilizzate per fare compiti specifici, magari dove il framework in uso non arriva. Per risolvere questi problemi puoi tranquillamente andare a cercare le varie API dedicate al momento in cui ne avrai bisogno.
Io a suo tempo mi trovai sul Kernighan & Ritchie, ma molti dicono che non si sono trovati bene. Poi ovviamente è un libro vecchio, anche se trovo il metodo di apprendimento apprezzabile.
cdimauro
30-12-2009, 09:04
fosse anche solo per la nomenclatura, guarda. io giuro che non capisco cosa ci guadagnano certi dementi a chiamare una funzione printf, fgets, recv, fork, sync, mkdir, utime, ... a pronunciarle uno sembra malato.
Non posso che concordare. Più che di fantasia parliamo di perversione mentale.
Per gli amanti di Python ricordo che lo stesso Python è scritto in C ;)
A me lo dici? http://code.google.com/p/wpython2/ :D
P.S. A breve la versione 1.1 sulla quale sto lavorando (la notte, principalmente).
Anche Java se non ricordo male. Chiedetevi come mai sono stati scritti in C e non con altro. Performances forse? Mah...
Indubbiamente le performance (velocità di esecuzione e/o ) sono la variabile principale.
A dir la verità, googlando un pò, vedo che stanno riscrivendo Python in Python:
http://codespeak.net/pypy/dist/pypy/doc/
Ma non penso che avrà le stesse performances :stordita:
Al momento no, ma promette molto bene. Hanno fatto dei passi da gigante. Tra l'altro da quando hanno incluso un compilatore JIT nativo x86, PyPy supera anche CPython a livello prestazionale. E PyPy è, appunto, scritto interamente in Python (RPython per la precisione, che ne è un sottoinsieme).
Tu ti rendi conto di che tipo di calcolatore (o terminale) si aveva a disposizione quando 40 anni fa sono state ideati quegli strumenti?
Ovvero: sai di cosa stai parlando?
Penso di sì. Bisogna essere mentalmente deviati per inventarsi dei nomi così.
Consiglio: imparati prima il C e dopo le API. Dal mio punto di vista le API di Windows sono sicuramente interessanti da un punto di vista didattico, ma attualmente di gente che programma le interfacce con le API di Windows ce n'è veramente, ma veramente poca. Già erano pochi 5-6 anni fa.
Con gli strumenti attuali (editor RAD, .Net, Qt) e i linguaggi attuali (C++, C#, Vb.Net, Java, Python) non c'è rimasto più nessuno che le usa. I motivi sono ovvi: per fare quello che si fa con un framework di alto livello in due istruzioni, con le API ti ci vogliono 10 istruzioni, 5 handle, 2 messaggi e la gestione degli stessi.
Le API vengono ora utilizzate per fare compiti specifici, magari dove il framework in uso non arriva. Per risolvere questi problemi puoi tranquillamente andare a cercare le varie API dedicate al momento in cui ne avrai bisogno.
Perfettamente d'accordo.
Io a suo tempo mi trovai sul Kernighan & Ritchie, ma molti dicono che non si sono trovati bene. Poi ovviamente è un libro vecchio, anche se trovo il metodo di apprendimento apprezzabile.
Non lo consiglierei, come non consiglio lo Stroustrup per il C++. Diciamo che questi libri sono la bibbia dei rispettivi linguaggi in quanto ne rappresentano la guida di riferimento. Quindi per programmatori già "svezzati".
Non lo consiglierei, come non consiglio lo Stroustrup per il C++. Diciamo che questi libri sono la bibbia dei rispettivi linguaggi in quanto ne rappresentano la guida di riferimento. Quindi per programmatori già "svezzati".
Io li trovo molto diversi, all'interno del K&R c'è almeno un percorso di apprendimento ben definito. Sullo Stroustrup portano ad esempio l'implementazione delle varie classi della STL, un bel casotto quindi. Poi oggettivamente il paradigma ad oggetti ha bisogno di essere spiegato meglio di quello procedurale.
Io sono 23 anni che cerco di capire il C.
Il libro di Ritchie è buono ma come dice Cesare è un 'documento' più che un libro.
Per quanto riguarda le parole riservate/funzioni del C è normale, lo spazio in memoria un tempo era ridicolo e risparmiavano su questo.
Mi ricordo di aver 'studiato' altri linguaggi del tempo e ci sono cose decisamente peggiori :D
Io sono 23 anni che cerco di capire il C.
Te ci scherzi, ma il mio primo programma in C l'ho fatto con carta e penna 20 anni fa :D All'epoca non avevo nemmeno il PC...andavo sull'Amiga di un mio amico per provarli (Lattice C !!!)
Te ci scherzi, ma il mio primo programma in C l'ho fatto con carta e penna 20 anni fa :D All'epoca non avevo nemmeno il PC...andavo sull'Amiga di un mio amico per provarli (Lattice C !!!)
LOL io avevo 11 anni ed ero su una SuSE 7.3 se non ricordo male :D
Ryuzaki_Eru
30-12-2009, 12:52
A me lo dici? http://code.google.com/p/wpython2/
P.S. A breve la versione 1.1 sulla quale sto lavorando (la notte, principalmente).
Mi sale sempre una cosa quando vedo questo progetto :eek:
Te ci scherzi, ma il mio primo programma in C l'ho fatto con carta e penna 20 anni fa All'epoca non avevo nemmeno il PC...andavo sull'Amiga di un mio amico per provarli (Lattice C !!!)
Che programma era? :stordita:
Che programma era? :stordita:
Erano gli esercizi del K&R ;)
Erano gli esercizi del K&R ;)
Io volevo farli tutti durante le vacanze, ma conoscendo bene il linguaggio, ed essendo fatti proprio per far apprendere il linguaggio, quando ho visto quanto sono semplici (e alcuni del tutto inutili) mi è passata la voglia :asd:
Comunque conto di farli prima o poi, tu li hai completati tutti a suo tempo? :D
Comunque conto di farli prima o poi, tu li hai completati tutti a suo tempo? :D
E chi se lo ricorda...si tratta di 20 anni fa :D Non li facevo sicuramente tutti, anche perché non avevo il PC per compilarli (avevo uno scrauso Olivetti PC Prodest 128 sul quale mi divertivo con Basic).
E chi se lo ricorda...si tratta di 20 anni fa :D Non li facevo sicuramente tutti, anche perché non avevo il PC per compilarli (avevo uno scrauso Olivetti PC Prodest 128 sul quale mi divertivo con Basic).
Hai iniziato a programmare a 10 anni? :eek:
Hai iniziato a programmare a 10 anni? :eek:
E che c'è di male? Io a 11 anni ho iniziato circa... :D
Hai iniziato a programmare a 10 anni? :eek:
In Basic anche prima dei 10 anni, il C l'ho iniziato a 12 anni.
Vincenzo1968
30-12-2009, 15:56
Ringrazio ancora tutti dei buoni consigli ricevuti,però ho ancora bisogno di un altro aiuto.
Ho deciso di comprare un libro sul C ed uno ,premesso che si trovi, sulle api di windows(naturalmente utilizzate con il C); ma non ho la più pallida idea di cosa comprare.
Se cortesemente mi volete indirizzare su dei buoni libri tenendo ,per quanto possibile , in cosiderazione questi quattro punti:
1)Userò esclusivamente windows(di conseguenza la parte linux ,o la compatibilità del codice con quest'ultimo,non mi interessa;ma non perchè considero linux inferiore a windows)
2)Già il solo studiare il C mi fà venire il malditesta,figuriamoci se il libro è in inglese.
3) Che all'interno del libro non sia dato niente per scontato e non ci siano delle frasi come:
a) non hanno per ora importanza
b) fortunatamente possiamo rimandare la siegazione di questo elemento al capitolo x
(perchè perdo il filo e non ci capisco più una mazza,quindi preferisco codice-spiegazione diretta)
4)Che a vostro parere sia sintetico e comprensibile,e soprattutto che non si perda in vani sproloqui e inutili considerazioni personali..
Scusate se chiedo troppo!:D
Per le API di Windows, il miglior libro in assoluto, per i principianti, è Programmare Windows di Charles Petzold:
http://www.unilibro.it/find_buy/Scheda/libreria/autore-petzold_charles/sku-559479/programmare_windows_.htm
http://www.unilibro.it/find_buy/copertine/g/8825607210g.jpg
Purtroppo è fuori catalogo. Ti consiglio(caldamente) di procurartelo di seconda mano.
;)
Vincenzo1968
30-12-2009, 16:04
Altro libro da non perdere, ma a un livello molto più avanzato, Windows via C/C++ di Jeffrey Richter:
http://www.amazon.com/Windows-via-Pro-Jeffrey-Richter/dp/0735624240
http://ecx.images-amazon.com/images/I/41Ob15OytzL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg
;)
Per le windows api lascia stare la GUI, per quella c'è visual studio.
Guardati se vuoi un po' questo:
http://ecx.images-amazon.com/images/I/51IQWD-J2EL._SL500_AA240_.jpg
ma ti avverto che le windows api fanno veramente schifo, pieno di funzioni che ricevono 10 o più parametri metà dei quali va settata a NULL perchè riservati! :O
Che genietti :D
di necessità virtù all'epoca non esistevano sistemi operativi floppy hdd ecc ecc, collegavi il calcolatore alla macchina e dovevi iniziare a programmare o caricare da cassetta e via di basic ma di un basic talmente di basso livello che non riconosceva neanche le parole chiave inserite in forma testuale (aka c'era un tasto / combinazione per ogni parola chiave)
Ryuzaki_Eru
30-12-2009, 20:35
di necessità virtù all'epoca non esistevano sistemi operativi floppy hdd ecc ecc, collegavi il calcolatore alla macchina e dovevi iniziare a programmare o caricare da cassetta e via di basic ma di un basic talmente di basso livello che non riconosceva neanche le parole chiave inserite in forma testuale (aka c'era un tasto / combinazione per ogni parola chiave)
Quello che ho scritto nel topic del sistema operativo. Anzi oggi comunque ci sono ragazzini che iniziano alle elementari grazie all'esistenza di linguaggi come Python.
cdimauro
31-12-2009, 07:35
Meglio. Perché cominciare con un BASIC ridotto all'osso e zeppo di GOTO e GOSUB, passando magari al linguaggio macchina con le tabelle degli opcode da imparare a memoria per scrivere poi sfilze di astrusi numeri esadecimali, non lo auguro proprio a nessuno...
Meglio. Perché cominciare con un BASIC ridotto all'osso e zeppo di GOTO e GOSUB, passando magari al linguaggio macchina con le tabelle degli opcode da imparare a memoria per scrivere poi sfilze di astrusi numeri esadecimali, non lo auguro proprio a nessuno...
Programmazione in binario, fatta anche questa su x86 ma con fini didattici
riguardo al basic non si faceva per scelta c'era o quello o quello
Al momento no, ma promette molto bene. Hanno fatto dei passi da gigante. Tra l'altro da quando hanno incluso un compilatore JIT nativo x86, PyPy supera anche CPython a livello prestazionale. E PyPy è, appunto, scritto interamente in Python (RPython per la precisione, che ne è un sottoinsieme).
Però presumo che nel frattempo stiamo migliorando anche la versione di Python scritta in C. Quindi il gap prestazionale dovrebbe rimanere più o meno inalterato. Correggimi se sbaglio.
Meglio. Perché cominciare con un BASIC ridotto all'osso e zeppo di GOTO e GOSUB, passando magari al linguaggio macchina con le tabelle degli opcode da imparare a memoria per scrivere poi sfilze di astrusi numeri esadecimali, non lo auguro proprio a nessuno...
Si, però qualcuno deve sapere quelle cose. Se tutti partono da linguaggi di alto livello, chi scrive più compilatori, codici per microcontrollori, drivers e tutto il resto del codice a stretto contatto con la macchina ecc ecc ? :D
cdimauro
31-12-2009, 09:56
Programmazione in binario, fatta anche questa su x86 ma con fini didattici
Mumble. Quindi hai assemblato pezzi codice ricorrendo direttamente agli opcode delle istruzioni?
riguardo al basic non si faceva per scelta c'era o quello o quello
Eh, lo so! :D
Però presumo che nel frattempo stiamo migliorando anche la versione di Python scritta in C. Quindi il gap prestazionale dovrebbe rimanere più o meno inalterato. Correggimi se sbaglio.
Attualmente col JIT PyPy risulta mediamente superiore a CPython, pur con tutte le migliorie di quest'ultimo (vedi anche il mio progetto, wpython, che ha come obiettivo proprio il miglioramento delle prestazioni).
Ma a CPython manca ancora un JIT "ufficiale", e quando arriverà la bilancia dovrebbe tornare nuovamente a favore di questo progetto, anche se in tutta onestà vedo che PyPy si difende molto bene. E tra l'altro, essendo scritto sostanzialmente in Python, è molto più facile da gestire, estendere e sperimentare. Non hai idea delle cose che mi debbo inventare con wpython per migliorare di qualche punto percentuale le prestazioni...
Si, però qualcuno deve sapere quelle cose. Se tutti partono da linguaggi di alto livello, chi scrive più compilatori, codici per microcontrollori, drivers e tutto il resto del codice a stretto contatto con la macchina ecc ecc ? :D
Chi si vuol dedicare a questa nicchia di mercato, che ci sarà sempre anche in futuro, per ovvi motivi.
Ma oggi la programmazione di sistema, dell'hardware, ecc. non va più di moda e non è necessaria per poter realizzare delle applicazioni. Detto in altri termini: un programmatore potrebbe tranquillamente farne a meno anche per il resto della vita, pur lavorando a progetti di spessore / non banali.
Poi è chiaro che se uno non è un programmatore da due soldi, che lo fa solo per lavoro e basta, ma è anche uno smanettone, non mancherà mai l'interesse a imparare cose nuove, ivi comprese quelle di più basso livello. ;)
Ma oggi la programmazione di sistema, dell'hardware, ecc. non va più di moda e non è necessaria per poter realizzare delle applicazioni.
Secondo me attualmente c'è proprio il boom della programmazione di microcontrollori. Boom ovviamente con le dovute proporzioni, sempre limitato, sia chiaro. Rispetto ad una decina di anni fa sono sicuramente aumentate di un ordine di grandezza le persone che programmano a basso livello. Prendi un qualsiasi oggetto elettronico e all'interno ci sarà un microcontrollore. Tutte le cose più banali che prima si facevano con le porte logiche ora si fanno con i microcontrollori. Persino nei giochini per bambini è pieno di microcontrollori. Poi chiaramente non tiro in ballo il settore automotive, dove l'impennata dell'elettronica nella gestione di tutto quanto riguarda la macchina, ma anche per gli accessori, è sicuramente più che decuplicata.
Ma anche la scrittura di driver è aumentata. Guarda i palmari e le periferiche per i palmari: lettori di codici a barre, lettori rfid, lettori di smartcard, applicazioni custom.
Invece sono diminuite nettamente le piccole realtà che realizzavano software gestionale di alto livello con relative conseguenze per il mercato del lavoro.
Si, però qualcuno deve sapere quelle cose. Se tutti partono da linguaggi di alto livello, chi scrive più compilatori, codici per microcontrollori, drivers e tutto il resto del codice a stretto contatto con la macchina ecc ecc ? :D
C'è differenza nel programmare un microcontrollore, con un set d'istruzioni ridotto, e programmare in Assembly con un moderno processore. Nel primo caso (anche se è possibile programmare, ad esempio in C), si può programmare in Assembly dopo aver imparato 30/70 istruzioni; nel secondo caso, non ci voglio neanche pensare :eek:
grigor91
31-12-2009, 13:05
Mumble. Quindi hai assemblato pezzi codice ricorrendo direttamente agli opcode delle istruzioni?
L'anno scorso io ho dovuto farlo perchè l'assembler del simulatore dello z80 non era compatibile con vista.
Alla fine non era neanche difficile: avevo le tabelle che ti dicevano quali erano i bit da inserire.
Mumble. Quindi hai assemblato pezzi codice ricorrendo direttamente agli opcode delle istruzioni?
Eh, lo so! :D
Attualmente col JIT PyPy risulta mediamente superiore a CPython, pur con tutte le migliorie di quest'ultimo (vedi anche il mio progetto, wpython, che ha come obiettivo proprio il miglioramento delle prestazioni).
Ma a CPython manca ancora un JIT "ufficiale", e quando arriverà la bilancia dovrebbe tornare nuovamente a favore di questo progetto, anche se in tutta onestà vedo che PyPy si difende molto bene. E tra l'altro, essendo scritto sostanzialmente in Python, è molto più facile da gestire, estendere e sperimentare. Non hai idea delle cose che mi debbo inventare con wpython per migliorare di qualche punto percentuale le prestazioni...
Chi si vuol dedicare a questa nicchia di mercato, che ci sarà sempre anche in futuro, per ovvi motivi.
Ma oggi la programmazione di sistema, dell'hardware, ecc. non va più di moda e non è necessaria per poter realizzare delle applicazioni. Detto in altri termini: un programmatore potrebbe tranquillamente farne a meno anche per il resto della vita, pur lavorando a progetti di spessore / non banali.
Poi è chiaro che se uno non è un programmatore da due soldi, che lo fa solo per lavoro e basta, ma è anche uno smanettone, non mancherà mai l'interesse a imparare cose nuove, ivi comprese quelle di più basso livello. ;)
praticamente si, programma in assembly e convertito in binario istruzione per istruzione, ovviamente per puro fine didattico a scuola (sistemi di trasmissione ed elaborazione delle informazioni 4° anno itis parecchio tempo fà)
B|4KWH|T3
31-12-2009, 14:22
Penso di sì. Bisogna essere mentalmente deviati per inventarsi dei nomi così.
Credo che molta di quella roba sia un'eredità di tempi in cui bisognava risparmiare anche sul singolo carattere
cdimauro
31-12-2009, 22:33
Secondo me attualmente c'è proprio il boom della programmazione di microcontrollori. Boom ovviamente con le dovute proporzioni, sempre limitato, sia chiaro. Rispetto ad una decina di anni fa sono sicuramente aumentate di un ordine di grandezza le persone che programmano a basso livello. Prendi un qualsiasi oggetto elettronico e all'interno ci sarà un microcontrollore. Tutte le cose più banali che prima si facevano con le porte logiche ora si fanno con i microcontrollori. Persino nei giochini per bambini è pieno di microcontrollori. Poi chiaramente non tiro in ballo il settore automotive, dove l'impennata dell'elettronica nella gestione di tutto quanto riguarda la macchina, ma anche per gli accessori, è sicuramente più che decuplicata.
Ma anche la scrittura di driver è aumentata. Guarda i palmari e le periferiche per i palmari: lettori di codici a barre, lettori rfid, lettori di smartcard, applicazioni custom.
Invece sono diminuite nettamente le piccole realtà che realizzavano software gestionale di alto livello con relative conseguenze per il mercato del lavoro.
Non ci sono solo i gestionali. Comunque sono sostanzialmente d'accordo con te. A mio avviso, però, c'è da riflettere su un paio di cose.
Prima i microcontrollori si programmavano esclusivamente in assembly. Da un bel po' di anni è il C a farla da padrone. Negli ultimi tempi si usa anche il C++. In futuro... chissà.
Questo perché il software dei sistemi embedded diventa sempre più complesso, e inoltre bisogna far fronte alle continue innovazioni della tecnologia.
Secondo me sono segnali molto importanti di cui si deve tener conto nel dare il giusto peso alle scelte effettuate, e che si faranno in futuro.
Detto in altri termini, non mi scandalizzerei di certo se in futuro (nemmeno troppo remoto) in questi aggeggi vedremo girare un virtual machine che esegue codice managed. E magari un s.o. managed. ;)
L'anno scorso io ho dovuto farlo perchè l'assembler del simulatore dello z80 non era compatibile con vista.
Alla fine non era neanche difficile: avevo le tabelle che ti dicevano quali erano i bit da inserire.
Il difficile è avere a che fare col calcolo dei salti, siano essi relativi o assoluti.
Capita che se devi fare una modifica in una parte del codice, sei costretto ad effettuare un po' di ricalcoli per queste istruzioni, ed è veramente una palla colossale.
praticamente si, programma in assembly e convertito in binario istruzione per istruzione, ovviamente per puro fine didattico a scuola (sistemi di trasmissione ed elaborazione delle informazioni 4° anno itis parecchio tempo fà)
Questo era già molto più semplice. :D Lo facevo anch'io nell'87 col Turbo Pascal 3.0, dove c'era solo l'istruzione inline per inserire codice macchina, ma prima lo compilavo col TASM e anziché creare il codice oggetto facevo generare il listato con sorgente preceduto dagli esadecimali degli opcode, che ricopiavo all'interno della inline.
Ma quando ho cominciato con linguaggio macchina (per Commodore 64) non c'era nulla di tutto ciò. Non avevo nemmeno il SuperMon, che trovai soltanto dopo un bel po'.
Per cui l'unica strada era mettermi davanti alla tabella degli opcode (che poi imparai quasi del tutto a memoria, a forza di usarla :D) e generare a mano tutta la sequenza di valori esadecimali da infilare nelle lunghe sequenze DATA del BASIC.
Mi vengono gli incubi se ci penso ancora. Per fortuna che poi arrivano strumenti che aiutavano e semplificavano molto la vita.
Credo che molta di quella roba sia un'eredità di tempi in cui bisognava risparmiare anche sul singolo carattere
Se quest'esigenza fosse stata reale, avremmo avuto md al posto di mkdir e rd al posto di rmdir, tanto per fare un paio di esempi noti.
E' difficile capire cosa passasse per la mente di certa gente. In questo libro (http://web.mit.edu/~simsong/www/ugh.pdf) è riportata una frase che mi ha fatto ridere molto:
“Two of the most famous products of Berkeley are LSD and Unix.
I don’t think that is a coincidence.”
e forse non ha tutti i torti. :p
Comunque fra meno di mezz'ora saremo nel 2010: sono passati ormai più di 40 anni da quando la prima versione di Unix è stata rilasciata.
Dobbiamo ancora risparmiare sul singolo carattere? Dobbiamo ancora portarci dietro la sua eredità (che fa pure ridere, se consideriamo che da anni il Male Assoluto viene tacciato di badare troppo alla "retrocompatibilità")? A quando un s.o. moderno e, soprattutto, pensato per gli esseri umani? ;)
grigor91
01-01-2010, 09:42
Capita che se devi fare una modifica in una parte del codice, sei costretto ad effettuare un po' di ricalcoli per queste istruzioni, ed è veramente una palla colossale.
Ovviamente erano programmi da una decina di istruzioni assembly, niente di che; dovevo solo verificarne il funzionamento.
Dobbiamo ancora risparmiare sul singolo carattere? Dobbiamo ancora portarci dietro la sua eredità (che fa pure ridere, se consideriamo che da anni il Male Assoluto viene tacciato di badare troppo alla "retrocompatibilità")? A quando un s.o. moderno e, soprattutto, pensato per gli esseri umani? ;)
Il Male Assoluto ci sta già pensando (http://it.wikipedia.org/wiki/Microsoft_Midori) ;)
Questo perché il software dei sistemi embedded diventa sempre più complesso, e inoltre bisogna far fronte alle continue innovazioni della tecnologia.
Secondo me sono segnali molto importanti di cui si deve tener conto nel dare il giusto peso alle scelte effettuate, e che si faranno in futuro.
Detto in altri termini, non mi scandalizzerei di certo se in futuro (nemmeno troppo remoto) in questi aggeggi vedremo girare un virtual machine che esegue codice managed. E magari un s.o. managed. ;)
Io lo spero, ma credo di più in un framework event driven di alto livello. Ovviamente le procedure da eseguire dovrebbero essere comunque scritte in un linguaggio di basso livello.
Purtroppo quando si ha a che fare sistemi real time diventa problematico garantire deadline di esecuzione con così tanti livelli di software. Più che altro diventa difficile dimostrare la possibilità di stare dentro alle deadline. Considera poi che un garbage collector inserirebbe una variabilità ulteriore ai tempo di esecuzione.
Magari vedo più possibile la creazione di compilatori dal linguaggio ad alto livello al linguaggio macchina del microcontrollore.
Comunque fra meno di mezz'ora saremo nel 2010: sono passati ormai più di 40 anni da quando la prima versione di Unix è stata rilasciata.
Dobbiamo ancora risparmiare sul singolo carattere? Dobbiamo ancora portarci dietro la sua eredità (che fa pure ridere, se consideriamo che da anni il Male Assoluto viene tacciato di badare troppo alla "retrocompatibilità")? A quando un s.o. moderno e, soprattutto, pensato per gli esseri umani? ;)
Eh ma non è mica facile buttare tutto e riscrivere da capo milioni di righe di codice :D Tanto per fare un esempio che esula dal software, tempo fa ho letto che i processori Intel, per mantenere compatibilità con il set di istruzioni x'86, perdono il 30% del proprio tempo per risolvere gli indirizzi di memoria :eek: E anche un bel 30% dei transistor che lo compongono servono solo a mantenere la retrocompatibilità. Se ritrovo l'articolo ve lo posto. Così aggiungo qualche dettaglio tecnico che al momento non ricordo.
Spesso non è solo questione di retrocompatibilità. Se ho un codice che gira da 30 anni e il suo dovere lo fa bene, vale davvero la pena riscriverlo da zero? Per fare un esempio, a volte mi capitano dei kernel di calcolo enormi scritti 30 anni fa in Fortran '66(!!!!!!) , ma siccome svolgono egregiamente il proprio lavoro, nessuno si sogna di riscriverli.
Energy++
01-01-2010, 11:24
Eh ma non è mica facile buttare tutto e riscrivere da capo milioni di righe di codice :D Tanto per fare un esempio che esula dal software, tempo fa ho letto che i processori Intel, per mantenere compatibilità con il set di istruzioni x'86, perdono il 30% del proprio tempo per risolvere gli indirizzi di memoria :eek: E anche un bel 30% dei transistor che lo compongono servono solo a mantenere la retrocompatibilità. Se ritrovo l'articolo ve lo posto. Così aggiungo qualche dettaglio tecnico che al momento non ricordo.
Spesso non è solo questione di retrocompatibilità. Se ho un codice che gira da 30 anni e il suo dovere lo fa bene, vale davvero la pena riscriverlo da zero? Per fare un esempio, a volte mi capitano dei kernel di calcolo enormi scritti 30 anni fa in Fortran '66(!!!!!!) , ma siccome svolgono egregiamente il proprio lavoro, nessuno si sogna di riscriverli.
i processori intel (e quindi anche amd) implementano al loro interno, per via della retrocompatibilità, svariate isa tra cui l'originale 8086, le sue evoluzioni successive (almeno 80486, pentiumpro, pentium), l'x86_64 e le svariate estensioni mmx, 3dnow, e sse.
E' vero che il decoder di queste cpu sia quindi enormemente complesso, ma è anche vero che questo oggi sia allo stato dell'arte.
Quindi l'impatto sulle prestazioni non so fino a che punto sia significativo e anche l'impatto sui transistor non è così spaventoso in confronto a quelli necessari a mettere tutta quella cache onboard :D
http://www.chip-architect.org/news/Intel_Core_family_picture.jpg
Quindi l'impatto sulle prestazioni non so fino a che punto sia significativo e anche l'impatto sui transistor non è così spaventoso in confronto a quelli necessari a mettere tutta quella cache onboard :D
http://www.chip-architect.org/news/Intel_Core_family_picture.jpg
Si ma un conto è mettere qualche milionata di transistor per la cache, un altro è essere costretti a metterli per garantire la retrocompatibilità :D
Il Male Assoluto ci sta già pensando (http://it.wikipedia.org/wiki/Microsoft_Midori) ;)
Io ho sempre odiato Windows, ma un SO riscritto da zero, anche se MS, è ben accetto, se porta miglioramenti tangibili. Speriamo che MS faccia un buon lavoro.
B|4KWH|T3
01-01-2010, 13:29
Comunque fra meno di mezz'ora saremo nel 2010: sono passati ormai più di 40 anni da quando la prima versione di Unix è stata rilasciata.
Dobbiamo ancora risparmiare sul singolo carattere? Dobbiamo ancora portarci dietro la sua eredità (che fa pure ridere, se consideriamo che da anni il Male Assoluto viene tacciato di badare troppo alla "retrocompatibilità")? A quando un s.o. moderno e, soprattutto, pensato per gli esseri umani? ;)
No no, ma su questo sono assolutamente daccordo ;)
Alla fine il costo su singola istruzione è di 2-3 stage nella pipeline.
cdimauro
01-01-2010, 16:30
Io lo spero, ma credo di più in un framework event driven di alto livello. Ovviamente le procedure da eseguire dovrebbero essere comunque scritte in un linguaggio di basso livello.
Purtroppo quando si ha a che fare sistemi real time diventa problematico garantire deadline di esecuzione con così tanti livelli di software. Più che altro diventa difficile dimostrare la possibilità di stare dentro alle deadline. Considera poi che un garbage collector inserirebbe una variabilità ulteriore ai tempo di esecuzione.
Magari vedo più possibile la creazione di compilatori dal linguaggio ad alto livello al linguaggio macchina del microcontrollore.
E' una visione per larga parte condivisibile, viste le problematiche che si porta dietro un sistema embedded.
Per quanto riguarda i GC, ne esistono di diversi tipi ed è possibile anche disattivarlo, attivarlo, o invocarlo in alcune VM (su quella di Python, ad esempio).
Eh ma non è mica facile buttare tutto e riscrivere da capo milioni di righe di codice :D Tanto per fare un esempio che esula dal software, tempo fa ho letto che i processori Intel, per mantenere compatibilità con il set di istruzioni x'86, perdono il 30% del proprio tempo per risolvere gli indirizzi di memoria :eek: E anche un bel 30% dei transistor che lo compongono servono solo a mantenere la retrocompatibilità. Se ritrovo l'articolo ve lo posto. Così aggiungo qualche dettaglio tecnico che al momento non ricordo.
Non sono d'accordo. Ho scritto diversi articoli in cui ho toccato l'argomento, che t'invito a leggere (in sequenza):
ARM vs Intel: I cut the power! (http://www.appuntidigitali.it/4375/arm-vs-intel-i-cut-the-power/)
Riflessioni sull’architettura ARM (http://www.appuntidigitali.it/4786/riflessioni-sullarchitettura-arm/)
Con Thumb-2 ARM tradisce i RISC e ritorna… ai CISC! (http://www.appuntidigitali.it/4947/con-thumb-2-arm-tradisce-i-risc-e-ritorna-ai-cisc/)
La “guerra” dell’ISA x86: l’impatto su decoder, compilatori, e implicazioni varie (http://www.appuntidigitali.it/5393/la-guerra-dellisa-x86-limpatto-su-decoder-compilatori-e-implicazioni-varie/)
In particolare l'ultimo che tratta esplicitamente dell'argomento.
Spesso non è solo questione di retrocompatibilità. Se ho un codice che gira da 30 anni e il suo dovere lo fa bene, vale davvero la pena riscriverlo da zero? Per fare un esempio, a volte mi capitano dei kernel di calcolo enormi scritti 30 anni fa in Fortran '66(!!!!!!) , ma siccome svolgono egregiamente il proprio lavoro, nessuno si sogna di riscriverli.
Se hai i sorgenti sì. Ma Linux mica è nato dai sorgenti della prima versione di Unix rilasciata 41 anni fa. ;)
i processori intel (e quindi anche amd) implementano al loro interno, per via della retrocompatibilità, svariate isa tra cui l'originale 8086, le sue evoluzioni successive (almeno 80486, pentiumpro, pentium), l'x86_64 e le svariate estensioni mmx, 3dnow, e sse.
E' vero che il decoder di queste cpu sia quindi enormemente complesso, ma è anche vero che questo oggi sia allo stato dell'arte.
Quindi l'impatto sulle prestazioni non so fino a che punto sia significativo e anche l'impatto sui transistor non è così spaventoso in confronto a quelli necessari a mettere tutta quella cache onboard :D
http://www.chip-architect.org/news/Intel_Core_family_picture.jpg
Concordo.
Si ma un conto è mettere qualche milionata di transistor per la cache, un altro è essere costretti a metterli per garantire la retrocompatibilità :D
Vero, ma bisogna contestualizzare. Ci sono casi in cui il peso del decoder più complicato si fa sentire, altri no.
Alla fine il costo su singola istruzione è di 2-3 stage nella pipeline.
Esattamente. E anche a livello di transistor e consumi, dipende strettamente dall'implementazione dell'architettura.
Ryuzaki_Eru
01-01-2010, 18:52
Niente libertà di parola. Mea culpa.
Energy++
01-01-2010, 19:50
Chissà come sarebbe il confronto tra la vecchia generazione e la nuova. Io personalmente ho iniziato tardi, ma se devo essere sincero non ho ancora capito se questo possa essere un grosso svantaggio o no. A volte in giro vedo cose assurde, in positivo e in negativo. :muro:
io mi chiedo invece perché vai sempre e dico SEMPRE OT
rikkaidd
01-01-2010, 20:28
Ri_auguroni a tutti.
Allora,per quanto riguarda il c, ho trovato un pdf online di 203 paginuzze,e mi accontenterò di questo;Poi mi avete consigliato di studiare un linguaggio basato sulla piattaforma net.framework, ma quale e da quale libro?
Per il libruzzo di c c'è qualcosa che non ho capito:
1) cos'è il "foo"
2)visto che il libro da solo questa spiegazione,e per ottenere lo stesso risultato basta solo un printf,né capisco il risultato ma non l'utilità di questa funzione:
Funzioni di callback
La conseguenza immediata dei puntatori a funzione sono le funzioni di callback.
Ovvero, nulla mi impedisce, a questo punto, di passare come parametro di una
funzione un puntatore a funzione, e la funzione richiamata può richiamare la
funzione passata come argomento. Esempio:
#include <stdio.h>
void print () {
printf ("Ciao\n");
}
int foo(void (*f)(void)) {
f();
}
main() {
foo(print);
}
foo è il nome che dai ad una variabile/funzione negli esempi, per evitare di essere troppo fantasiosi :)
http://en.wikipedia.org/wiki/Foobar
Ryuzaki_Eru
02-01-2010, 01:34
io mi chiedo invece perché vai sempre e dico SEMPRE OT
Preferisco non rispondere in modo da non dare nè soddisfazione nè stare al suo gioco (visto che non è la prima volta).
Ricordo che esistono i moderatori.
io mi chiedo invece perché vai sempre e dico SEMPRE OT
Ma non ti sembra già abbastanza OT questa discussione ? Non vedo perché tu debba riprendere qualcuno.
^TiGeRShArK^
02-01-2010, 16:58
uff...
e mi sono perso il flame di natale.. :sob:
Ryuzaki_Eru
02-01-2010, 17:02
uff...
e mi sono perso il flame di natale.. :sob:
Credo sia un tantino esagerato definirlo flame ;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.