C'è differenza tra C e C# ?

[grigor91]

Originariamente inviato da 71104

tra qualche anno succederà: C# è il futuro per i sistemi operativi (vedi Singularity).

a dire la verità già si sta muovendo qualcosa con seven visto che si sta sviluppando utilizzando largamente .net

Ho letto anche che Midori è derivato appunto da Singularity.

[cdimauro]

Originariamente inviato da marco.r

Ma anche no. Se guardi un sistema operativo unix appena installato una notevole quantita' del software di base e' in script vari tra shell, python, perl etc.
La quantita' di codice C/C++ e' probabilmente analoga a quella che si trova in un sistema Windows.
Se guardi poi gli ambienti grafici c'e' una certa quantita' accessori/tool scritti in linguaggi di piu' alto livello. Anzi, quando si va oltre i linguaggi mainstream (c++,vb,.net,java) c'e' piu' disponibilita' sotto unix che sotto windows.

Sì, so che esistono tante applicazioni scritte in linguaggi di più alto livello (anche Python è abbastanza diffuso), ma vedo ancora troppo utilizzo di C & co.

[71104]

Originariamente inviato da grigor91

a dire la verità già si sta muovendo qualcosa con seven visto che si sta sviluppando utilizzando largamente .net

non ho idea di come stiano realizzando Windows 7, ma non credo che ci sia del C# nel kernel: credo che sia ancora un kernel NT. ipotizzo che la rivoluzione la faranno introducendo Singularity come una nuova versione di Windows, cosa che avverrà forse già dopo Windows 7 contando che la vita media dei sistemi Windows col passare del tempo si allunga; almeno, questa è la mia impressione.

[71104]

Originariamente inviato da marco.r

Sistemato

il Windows del futuro è scritto in C# (o meglio, in Sing# stando a Wikipedia, una derivazione del C#), e Linux invece? continuerà idiotamente a mantenere la tradizione del classico kernel C POSIX-compliant, continuerà ancora più idiotamente a vantarsi di entrare su un floppy (quando già adesso iniziano ad esserci computers senza lettore floppy)?

Singularity non è l'unico tentativo di scrivere un sistema operativo in C#; vedi sulla pagina di Wikipedia che ho linkato. quando Singularity sarà una realtà quotidiana, Linux scritto in C non potrà più essere considerato un sistema operativo, non uno degno di questo nome.

[Albitexm]

Originariamente inviato da ^TiGeRShArK^

Ma se non ci si aggiorna mai si rimane sempre a lavorare per una vita con lo stesso linguaggio, e ciò imho non è mai un bene.
Un informatico dal mio punto di vista non può assolutamente essere conservatore ma deve aprire continuamente la mente a nuovi concetti che lo potrebbero aiutare a lavoro.

Questa tua affermazione è vera e non vera . Dal punto di vista generale credo
sia indubbiamente vero che bisogna "aprire continuamente la mente a nuovi concetti" , questo in tutti i campi della vita. Per quanto riguarda il lavoro , personalmente credo sia utile essere sempre aggiornati , ma non esagerare nel cercare "per forza" nuove soluzioni per risolvere dei problemi. Questo potrebbe essere controproducente.
Per quanto riguarda la situazione reale nelle aziende, l'innovazione in Italia purtroppo , non è vista molto bene . Anzi, spesso è chiaramente osteggiata . Il mondo del lavoro italiano è tradizionalista , conservatore , rigido e parentale. Il nostro è il paese in europa con il più alto numero di "consulenti" pensionati all'interno delle aziende. L'Italia ha un'età media dei lavoratori più alta del mondo (e anche dei " non lavoratori", che sono la maggioranza).
Dalla mia esperienza , introdurre un nuovo metodo di lavoro, una nuova tecnologia in azienda è spesso controproducente. E comunque possibile , solo dopo avere ottenuto il tacito consenso dei "mammasantissima aziendali". E' quasi una missione impossibile . Non per niente tutte le innovazioni tecnologiche arrivano dagli States , ed ultimamente dai paesi emergenti :
(India,Pakistan,Cina ed Est europeo). L'Italia è ormai un paese di pensionati , adatto a passare la villeggiatura e a visitare i musei e comprare vestiti alla moda (che tanto fanno in Cina, ma l'illusione del capo firmato conta) .

[RaouL_BennetH]

Mi intrometto in questa bella discussione

Mi sembra chiaro che le idee che ciascuno espone, siano dettate dall'ambito e dalle circostanze in cui si trova. Per esempio, l'ottimo TigerShark in qualità di "studente" e in qualità di insaziabile curioso informatico (nel senso migliore del termine beninteso!) dà un giusto suggerimento per quanto riguarda il tenersi aggiornati, quantomeno di sapere quali nuovi strumenti esistano sul mercato etc..

Da un punto di vista però meramente lavorativo, in genere (e aggiungo purtroppo), non funziona proprio così. Molto difficilmente in un'azienda sarà lasciata al programmatore la facoltà di scegliere gli strumenti giusti per risolvere dei problemi, ma si utilizzeranno gli strumenti che l'azienda ha a disposizione, anche quando sono insufficienti o inadeguati per risolvere quel determinato problema. E questo spiegherebbe anche la quantità notevole di software scritto alla meno peggio e non sempre per colpa del/dei programmatore/i.

Vorrei sottolineare che io NON sono un programmatore, ma lavorando fianco a fianco con un ottimo programmatore che frequentava questo forum, mi sono potuto fare un'idea di come funzionano le cose.

Diverso è il discorso dove un'azienda che non ha un settore it interno, si rivolge all'esterno per farsi realizzare un programma ad hoc, e, in questo caso, torna utile il modo di vedere di TigerShark e degli altri come lui che è fondamentale tenersi aggiornati.

Mi è capitato invece di assistere personalmente a questa cosa:

Un'azienda del sud, molto grande, ha richiesto all'azienda del mio amico di cui sopra di realizzare un determinato software. Quest'azienda ha al suo interno un settore it. Bene, il settore it come pre-requisiti necessari, ha chiesto e ordinato che il software venisse sviluppato in VB6 e Access 97 come base dati. Alla richiesta di motivazioni, è stata fornita la spiegazione che siccome il personale interno che gestisce l'it dell'azienda, come know-how acquisito ha soltanto quello relativo ai suddetti strumenti. Non c'è stato verso di fargli cambiare opinione visto che poi, successivamente al rilascio, dovrà essere il personale interno ad occuparsi di manutenere il software.

Per quanto possa sembrare strano, ci sono molte aziende che ragionano in questo modo, lasciando uno scenario informatico italiano a livelli alquanto scadenti.

[k0nt3]

Originariamente inviato da 71104

Singularity non è l'unico tentativo di scrivere un sistema operativo in C#; vedi sulla pagina di Wikipedia che ho linkato. quando Singularity sarà una realtà quotidiana, Linux scritto in C non potrà più essere considerato un sistema operativo, non uno degno di questo nome.

non metto in dubbio che ciò accada, ma sviando il discorso in questo senso sembra che questo implica che C diventerà (per qualcuno "è") un linguaggio "inutile".
questo non accadrà mai, al massimo si potrà dire che sarà un linguaggio poco usato e magari per questo non verrà nemmeno insegnato nelle scuole (siamo molto lontani da questo scenario tuttavia).
sarebbe inutile se quello che si impara usando C fosse da buttare via una volta passati a un altro linguaggio, ma questo non è vero come ho già avuto modo di spiegare senza che nessuno riuscisse a portare argomentazioni diverse da: "no perchè no"

ps. riguardo a linux penso che quando ci sarà la reale necessità di qualcosa di diverso, si evolverà in qualche maniera o verrà sostituito da un altro kernel (sicuramente non GNU HURD), in ogni caso non è affatto legato mani e piedi a C, ad esempio dove c'è stata la necessità si sono creati moduli come FUSE che permettono di usare un linguaggio qualsiasi per interfacciarsi alle funzionalità del kernel.

[k0nt3]

Originariamente inviato da cdimauro

Legacy: la chiave di tutto sta qui. C'è troppo codice che lo utilizza e che... dev'essere anche mantenuto.

Inoltre ci sono s.o. come Unix che si sono legati mani e piedi a C: programmare su sistemi Unix-like è praticamente equivalente a lavorare in C.

C'è molta difficoltà, e anche un giusto timore in alcuni casi, a "svecchiare" gli strumenti.

No, c'è anche il linguaggio:

#include <stdio.h>
 
int main(void) {
  int n;
  while (scanf("%d", n) == 1)
    printf ("%d\n", n);
  return 0;
}

Prova a fare la stessa cosa in Pascal, che è un linguaggio tanto procedurale quanto il C, e per giunta pure più vecchio.

E questo è solo un esempio.

non ci vedo niente di "inutile" nel codice che hai postato
per il resto sono daccordo che per sviluppare un progetto al giorno d'oggi C deve essere considerata l'ultima spiaggia, non vorrei che crediate che io programmi in C nel tempo libero

[gugoXX]

Posso buttare qualche differenza tra C++ e C#.
Poi quelle tra C e C++ per chiudere il cerchio le lascio a qualcun altro, dato che praticamente non ho mai programmato in C per motivi commerciali.
Tenete anche conto che ho smesso di usare il C++ per fini commerciali prima dell'inserimento delle standard library. Non so neppure se sono uno standard o meno.
E' quindi probabile che alcune delle differenze siano meno marcate di quanto pensi.

Ho diviso i punti in Pro e Contro, come puro sentore personale. Alcune cose che sono dei Pro potrebbero essere contro per qualcuno e viceversa.
Se non vi piace questa classificazione, mettete tutto insieme e consideratele differenze e basta.

Pro:
1. Garbage collection e non necessita' dell'uso di puntatori e di distruttori
2. Reflection, per conoscere a Runtime le proprieta'/metodi degli oggetti ed eventualmente richiamarli
3. No file di Header, nessun problema relativo ad obblighi di dichiarazioni di classi prima di altre. Nessun problema di dipendenze circolari.
4. Pure object oriented: tutto deriva da un singolo oggetto.
5. Un solo modo di allocazione memoria mediante la keyword new.
6. Supporto nativo al Multithread e alla sincronizzazione
7. Interfacce: Se un oggetto utente implementa un interfaccia potra' essere passato ad una funzione anche di terze parti che richiede quell'interfaccia come input.
8. Classi annidate con diverse visibilita'
9. No funzioni globali o costanti. Tutto e' fortemente orientato agli oggetti e appartiene ad una classe.
10. Array e stringhe posseggono nativamente proprieta' come Length e hanno nativamente i controlli di boundary checking
11. L'operatore . (punto) viene usato dappertutto. Eliminata la necessita' di distinguere tra . -> :: per accedere a membri di classe.
12. null e bool sono keyword
13. Tutti i valori sono forzatamente inizializzati prima dell'uso
14. Un valore intero non governa gli if. Gli if sono governati solo da booleani.
15. il costrutto try puo' avere un finally
16. La compilazione risulta in un file indipendente dalla macchina. E' sufficiente avere una virtual machine sul SO e il file, gia' compilato, funzionera' anche solo copiandolo semplicemente da SO a SO.
17. Supporto alla creazione di Template (Generics) fortemente tipizzati
18. Lambda expression, lambda function e programmazione Funzionale
19. Supporto nativo al parallelismo.
20. Eventuale supporto nativo al parallelismo senza necessita' di governare esplicitamente i thread.
21. Supporto ai database uniformato.
22. Supporto nativo di trasformazione di un database relazionale ad un database ad oggetti. Il database puo' essere visto come una collezione di array interdipendenti. (LINQ to SQL, simile a NIbernate)
23. Un solo tipo di string.
24. Alcune ottimizzazioni vengono risolte a RunTime. La macchina virtuale impara durante l'esecuzione del programma. P.Es. alcune funzioni vengono trasformate a funzioni inline al volo.
25. Esistenza dei delegate, che realizzano un type-safe nella dichiarazione dei puntatori a funzione del C++.
26. Lazy evaluation. Mediante la programmazione funzionale e' possibile far valutare espressioni solo se veramente necessario
27. Mediante le Lambda Function e' possibile passare pezzi di codice come parametro, scritti in modo conciso e strong-typed.
28. Il costrutto switch non permette il fall-trought tra i case, sovente sorgente di errori.
29. Supporto nativo alle Properties, con piu' facile incapsulamento e controllo delle variabili
30. Aggiunta di attributi e metadati al codice, leggibili e usabili anche a Runtime
31. Integrazione completa con la documentazione, per la scrittura automatica di documenti e per il supporto all'intellisense.
32. Dispone gia' da standard di Enumeratori e Collezioni fortemente tipizzati.
33. Libreria (Framework .net) con utility per quasi tutte le esigenze.
34. Estensore di classi. E' possibile estendere una classe, costruita da qualcun altro, con nuovi metodi. (Si deve pero' fare uso di sole proprieta'/metodi pubblici, logico per preservare il paradigma object oriented)
35. Una funzione (raramente usate) che accetta un parametro di tipo out, per modificarlo, e' obbligata a farlo.
36. Si possono governare progetti complessi, con l'integrazione Project Server e Visual Soursafe, tutto dall'unico ambiente di sviluppo Visual Studio.
37. Direttamente da Visual Studio esistono estensioni e template Standard per la creazione di progetti di svariati tipi, come i Web Services, architetture SOA, WF (Windows Workflow), WPF (Windows Presentation Foundation), WCF (Windows Communication Foundation), ASP.net (website), ASP.net+AJAX.net, ...
38. Se Il C# non dovesse piacere per qualche componente, e' possibile utilizzare VB.net o C++.net e usare tutto da una stessa soluzione.
39. E' possibile richiamare in modo molto semplice pezzi di codice C++, purche' non facciano uso di parametri di tipo particolare. Per parametri piu' complessi la situazione non e' cosi' agevole. E' comunque possibile mediante Marshaling.
40. Se non si sa qualcosa il piu' delle volte e' sufficiente premere F1, senza dover navigare troppo sul Web. La maggior parte della documentazione e' tutta concentrata nella risorsa MSDN.

Contro:
1. E' generalemente piu' lento. Il motivo principale e' che gli array in ambienti managed vengono acceduti mediante CALL invece che con un paio di accessi diretti a zone di memoria
2. La virtual machine completa c'e' solo per ambiente Windows. Per ambiente Linux e' piu' indietro (e probabilmente sara' sempre un passo indietro rispetto alla Windows). Per altri ambienti non esiste.
3. Non e' fattibile un controllore fortemente sincrono per ambienti RealTime. Anche il C++ non e' la soluzione migliore.
4. Mancanza di derivazione multipla (voluta).
5. Impossibilita' di utilizzare operatori matematici all'interno di Generics, che deriva dalla impossibilita' di forzare un operatore mediante interfaccia
6. E' progettato, mantenuto ed espanso da una compagnia privata, la Microsoft. La community e' pero' aperta e l'atmosfera che vi si respira non e' dissimile dalle community open-source. Se la Microsoft dovesse lasciarci le penne e' probabile che il C# fara' la stessa fine.
7. Il C# e' giovane, non si sa cosa succedera'

[cdimauro]

Originariamente inviato da k0nt3

non metto in dubbio che ciò accada, ma sviando il discorso in questo senso sembra che questo implica che C diventerà (per qualcuno "è") un linguaggio "inutile".

Come linguaggio lo è, infatti: ubi maior minor cessat dicevano gli antichi latini...

Se sai cosa vuol dire, saprai anche cosa intendo per maior.

questo non accadrà mai, al massimo si potrà dire che sarà un linguaggio poco usato e magari per questo non verrà nemmeno insegnato nelle scuole (siamo molto lontani da questo scenario tuttavia).

Il solo fatto di non insegnarlo sarebbe già una gran cosa.

sarebbe inutile se quello che si impara usando C fosse da buttare via una volta passati a un altro linguaggio,

Questo è proprio banalissimo da smentire: dal C passa a SmallTalk e vedi se continuerai a programmare allo stesso modo.

ma questo non è vero come ho già avuto modo di spiegare senza che nessuno riuscisse a portare argomentazioni diverse da: "no perchè no"

Ne abbiamo già discusso e non ci siamo limitati soltanto ai "perché no", ma abbiamo AMPIAMENTE ARGOMENTATO, e continuare a riportare la solita litania non ti darà automaticamente ragione.

Tra l'altro ti avevo anche riproposto di riuppare i vecchi thread e di continuare la discussione, ma ti sei tirato indietro.

Io sono disponibile a riprendere la discussione SE E SOLO SE ti deciderai a portarla a termine, perché non voglio più tornarci. Quindi fino a quando alla domanda: "è utile insegnare/imparare il C?" non si darà una risposta secca; un bel SI' oppure NO.
Così mi segno il thread e te lo rispiattello senza commenti alla prossima occasione che tirerai fuori nuovamente l'argomento.

ps. riguardo a linux penso che quando ci sarà la reale necessità di qualcosa di diverso, si evolverà in qualche maniera o verrà sostituito da un altro kernel (sicuramente non GNU HURD), in ogni caso non è affatto legato mani e piedi a C, ad esempio dove c'è stata la necessità si sono creati moduli come FUSE che permettono di usare un linguaggio qualsiasi per interfacciarsi alle funzionalità del kernel.

Poca roba rispetto a tutto il resto.

Originariamente inviato da k0nt3

non ci vedo niente di "inutile" nel codice che hai postato

Più che di codice inutile si tratta di codice errato.

per il resto sono daccordo che per sviluppare un progetto al giorno d'oggi C deve essere considerata l'ultima spiaggia, non vorrei che crediate che io programmi in C nel tempo libero

Ma come? Il C non era utile come linguaggio? Perché non lo usi?

[dupa]

Originariamente inviato da ^TiGeRShArK^

..a parte che sti Criteria così ad occhio mi fanno schifo..
SQL è pensato proprio per lavorare sui DB tant'è vero che ha una potenza espressiva inferiore a quasi tutti gli altri linguaggi.
Per me, tornando all'esempio di cui sopra, sarebbe MOLTO + chiaro scrivere:

var result = (from c in categories
              where c.name.StartsWith("F")
              orderby c.name, c.age descending
              select c).Take(50);

Quello che hai scritto tu in Java si fa con JPA QL (o HQL in hibernate)

con i criteria puoi in modo elegante e object oriented costruire interrogazioni al DB in modo dinamico.
se certi condizioni sono verificate, aggiungi una restriction al tuo criteria, oppure effettui una join e applichi una restriction alla join ecc.

in ogni caso se conosci i criteria, ciò non vuol dire che te ne puoi fregare di JDBC o SQL nativo.

allo stesso modo per comprendere C# o Java è utile avere studiato C su un libro didattico come il K&R, altrimenti finiresti con usare funzioni già belle pronte, ad esempio il sort suggerito da Unrue, senza allenare la mente a certi ragionamenti logici.

[cdimauro]

Originariamente inviato da dupa

allo stesso modo per comprendere C# o Java è utile avere studiato C

Assolutamente in disaccordo, visto che con C# si tende a programmare a oggetti, con un po' di programmazione funzionale, e il C è quanto di più lontano da tutto ciò.

su un libro didattico come il K&R,

Ti è stato già detto che il K&R NON è un libro didattico.

altrimenti finiresti con usare funzioni già belle pronte, ad esempio il sort suggerito da Unrue, senza allenare la mente a certi ragionamenti logici.

Sono due cose che non c'entrano niente. Gli algoritmi prescindono dal linguaggio e servono per allenare la mente.

Col C, invece, dopo aver allenato la mente a risolvere problemi con una certa mentalità poi impiegheresti altro tempo per disimparare lavorando con linguaggi come C#, Java, Python, ma anche il C++ stesso.

[dupa]

Originariamente inviato da cdimauro

Assolutamente in disaccordo, visto che con C# si tende a programmare a oggetti, con un po' di programmazione funzionale, e il C è quanto di più lontano da tutto ciò.

Ma lo capirete prima o poi che quando si programma in Java o in C# sia usa sia programmazione strutturata, sia programmazione funzionale, sia programmazione a oggetti?!?!

[71104]

gugoXX, ti faccio qualche precisazione sul C++:

Originariamente inviato da gugoXX

7. Interfacce: Se un oggetto utente implementa un interfaccia potra' essere passato ad una funzione anche di terze parti che richiede quell'interfaccia come input.

embè...? anche in C++
per essere pignoli in C++ non esistono interfacce, ma non esistono solo perché non ce n'è bisogno: basta dichiarare una classe contenente solo metodi astratti.

8. Classi annidate con diverse visibilita'

si possono fare anche in C++ da quanto mi risulta

12. null e bool sono keyword

bool, true e false sono keywords anche in C++.

15. il costrutto try puo' avere un finally

anche in C++ perdindirindina!

17. Supporto alla creazione di Template (Generics) fortemente tipizzati

purtroppo non so bene cosa voglia dire "fortemente tipizzati", comunque i template ci sono anche in C++ e sono molto potenti.

23. Un solo tipo di string.

e perché, in C++ quanti ce ne sono scusa?
se intendi dire che in C++ oltre a std::string c'è anche char* allora ti rispondo che gli array di caratteri li puoi fare anche in C#.

26. Lazy evaluation. Mediante la programmazione funzionale e' possibile far valutare espressioni solo se veramente necessario

non ne sono certo a causa del fatto che lo standard del C++ non è gratis, ma credo che la lazy evaluation non sia un'ottimizzazione dei compilatori C++, ma che faccia proprio parte dello standard.

28. Il costrutto switch non permette il fall-trought tra i case, sovente sorgente di errori.

ma in questo modo non permette neanche di reagire allo stesso modo in più casi.

29. Supporto nativo alle Properties, con piu' facile incapsulamento e controllo delle variabili

le STL includono una classe map; non conoscendo bene Properties non so se è paragonabile.

32. Dispone gia' da standard di Enumeratori e Collezioni fortemente tipizzati.

anche il C++; si potrebbe obiettare che in certi casi quelli del C++ fanno un po' schifo (non scherzo).

40. Se non si sa qualcosa il piu' delle volte e' sufficiente premere F1, senza dover navigare troppo sul Web. La maggior parte della documentazione e' tutta concentrata nella risorsa MSDN.

la documentazione sul C++ d'altra parte è tutt'altro che difficilmente reperibile: esistono ottimi siti come www.cplusplus.com e www.cppreference.com, ed inoltre esiste una versione della documentazione anche su MSDN stessa.

[grigor91]

Originariamente inviato da cdimauro

Col C, invece, dopo aver allenato la mente a risolvere problemi con una certa mentalità poi impiegheresti altro tempo per disimparare lavorando con linguaggi come C#, Java, Python, ma anche il C++ stesso.

Mi sembra strano che per imparare un nuovo linguaggio bisogna disimpararne un'altro; al massimo si accantona.

[VICIUS]

Originariamente inviato da dupa

allo stesso modo per comprendere C# o Java è utile avere studiato C su un libro didattico come il K&R,

Se per didattico intendi che insegna a programmare mi trovi in disaccordo. Lo scopo del k&r è quello di spiegare le caratteristiche del linguaggio C e una panoramica della sua libreria standard e niente più. Per imparare le basi i sono altri testi.

Originariamente inviato da dupa

altrimenti finiresti con usare funzioni già belle pronte, ad esempio il sort suggerito da Unrue, senza allenare la mente a certi ragionamenti logici.

Il fatto che C# o altri linguaggi forniscano già una enormità di funzioni già pronte non significa che il programmatore non imparerà mai a scrivere un algoritmo. Se seguissimo alla lettera questo ragionamento anche il C non andrebbe bene perché fornisce funzioni già pronte per ordinamento e ricerca molto generali non avrebbe senso scriverle ogni volta.

Io trovo che se si vuole studiare per bene un argomento come gli algoritmi sia più facile usare un linguaggio come python/ruby in cui puoi evitare di pensare a tantissimi problemi di basso livello e concentrarti su quello che vuoi realmente imparare.

[dupa]

Originariamente inviato da cdimauro

Assolutamente in disaccordo, visto che con C# si tende a programmare a oggetti, con un po' di programmazione funzionale, e il C è quanto di più lontano da tutto ciò.

Ti è stato già detto che il K&R NON è un libro didattico.

Sono due cose che non c'entrano niente. Gli algoritmi prescindono dal linguaggio e servono per allenare la mente.

Col C, invece, dopo aver allenato la mente a risolvere problemi con una certa mentalità poi impiegheresti altro tempo per disimparare lavorando con linguaggi come C#, Java, Python, ma anche il C++ stesso.

dai un po' un occhiata al repository del tuo amato Python...

http://svn.python.org/view/python/trunk/Parser/

(file) node.c 64114 2 months gregory.p.smith Merge in release25-maint r60793: Added checks for integer overflows, contribut...
(file) parser.c 61953 4 months christian.heimes Patch #2477: Added from __future__ import unicode_literals The new PyParser_*Ex...
(file) parser.h

Sti infedeli programmano in C.

[VICIUS]

Originariamente inviato da grigor91

Mi sembra strano che per imparare un nuovo linguaggio bisogna disimpararne un'altro; al massimo si accantona.

Non il linguaggio come i puntatori, struct ed enum ma il modo di pensare e risolvere i problemi. C è procedurale e porta a trovare soluzioni in modo completamente diverso da linguaggi ad oggetti.

[cdimauro]

Originariamente inviato da dupa

Ma lo capirete prima o poi che quando si programma in Java o in C# sia usa sia programmazione strutturata, sia programmazione funzionale, sia programmazione a oggetti?!?!

Certo: proprio il modo giusto per lavorare con quei linguaggi...

Originariamente inviato da grigor91

Mi sembra strano che per imparare un nuovo linguaggio bisogna disimpararne un'altro; al massimo si accantona.

E' questione di mentalità: i problemi li si affronta in maniera molto diversa.

Spesso passando da C a un linguaggio a oggetti si continua a sviluppare il codice in maniera strutturata.

Originariamente inviato da dupa

dai un po' un occhiata al repository del tuo amato Python...

http://svn.python.org/view/python/trunk/Parser/

(file) node.c 64114 2 months gregory.p.smith Merge in release25-maint r60793: Added checks for integer overflows, contribut...
(file) parser.c 61953 4 months christian.heimes Patch #2477: Added from __future__ import unicode_literals The new PyParser_*Ex...
(file) parser.h

Sti infedeli programmano in C.

Ho i sorgenti di CPython 2.6b2 aperti proprio qui davanti a me in questo momento, e so benissimo cosa significa.

Sei tu che non ti sei preso la briga di controllare un'altra utile paginetta. Questa: http://www.python.org/dev/implementations/

Da notare le ALTRE implementazioni di Python che... non sono scritte in C. Chissà perché: spiegamelo tu, dai, visto che ti sei preso la briga di googlare e riportare quelle 3 informazioni di cui sopra.

[gugoXX]

Provo a replicare su qualche punto.
Alla fine aggiustero' la lista, per evitare futuri errori.

12. null e bool sono keyword

bool, true e false sono keywords anche in C++.

Una volta non lo erano.
Neppure byte lo era, ora che mi ricordo. E non avevo mai capito il perche', dato che gia' dal C il linguaggio si fregiava di essere abbastanza a basso livello.
Non dico WORD o keyword simili, effettivamente platform dependent.
Ma almeno byte e bool (o bit). Bit c'era addirittura in Pascal se non erro...

_________________________________

Quote:
15. il costrutto try puo' avere un finally

anche in C++ perdindirindina!

Anche questo non c'era nel C++ fino al 2000 almeno.
Sei sicuro che ci sia oggi nel C++ standard? Ho sentito parlare della sua mancanza non piu' di 2 anni fa.
Ma magari la persona che me ne ha parlato non era effettivamente aggiornata.

__________________________________________

17. Supporto alla creazione di Template (Generics) fortemente tipizzati

purtroppo non so bene cosa voglia dire "fortemente tipizzati", comunque i template ci sono anche in C++ e sono molto potenti.

Lo so che ci sono anche in C++. La differenza sta nell'istante di creazione del template/generic. Riporto qui un pezzo esplicativo
The big difference between C# generics and C++ templates shows up in when the type checking occurs and how the instantiation occurs. First of all, C# does the instantiation at runtime. C++ does it at compile time, or perhaps at link time. But regardless, the instantiation happens in C++ before the program runs. That's difference number one. Difference number two is C# does strong type checking when you compile the generic type. For an unconstrained type parameter, like List<T>, the only methods available on values of type T are those that are found on type Object, because those are the only methods we can generally guarantee will exist. So in C# generics, we guarantee that any operation you do on a type parameter will succeed.

C++ is the opposite. In C++, you can do anything you damn well please on a variable of a type parameter type. But then once you instantiate it, it may not work, and you'll get some cryptic error messages. For example, if you have a type parameter T, and variables x and y of type T, and you say x + y, well you had better have an operator+ defined for + of two Ts, or you'll get some cryptic error message. So in a sense, C++ templates are actually untyped, or loosely typed. Whereas C# generics are strongly typed.


______________________________________

23. Un solo tipo di string.

e perché, in C++ quanti ce ne sono scusa?
se intendi dire che in C++ oltre a std::string c'è anche char* allora ti rispondo che gli array di caratteri li puoi fare anche in C#.

Intendevo anche le BSTR, le WCHAR*, le TCHAR*, le OLECHAR*
elementi con cui devi fare conoscenza se vuoi costruire un programma internazionale.
A meno che le cose siano cambiate anche in questa direzione...
Per non parlare poi delle varianti, come TUCHAR, LPSTR, LPCSTR, PWSTR, LPCWSTR, OLECHAR FAR* (!!!!! mavaff)

_______________________________________

Quote:
26. Lazy evaluation. Mediante la programmazione funzionale e' possibile far valutare espressioni solo se veramente necessario

non ne sono certo a causa del fatto che lo standard del C++ non è gratis, ma credo che la lazy evaluation non sia un'ottimizzazione dei compilatori C++, ma che faccia proprio parte dello standard.

Intendevo un pezzo di codice come questo

int pippo(int test, int val)
{
   if (test>100) return val;
   return 0;
}

....
int valore=pippo(5, metodolento(a,b,c) );
...

Dove metodolento e' un metodo lento... che ritorna un intero.
In C++ metodolento e' eseguito anche se non servira' dato che test varra' 5.
In C#, in programmazione funzionale, il metodolento non verra' eseguito affatto.

________________________________________

28. Il costrutto switch non permette il fall-trought tra i case, sovente sorgente di errori.

ma in questo modo non permette neanche di reagire allo stesso modo in più casi.

In C# il fall-trought e' permesso tra casi equivalenti, a patto di non mettere codice tra di essi.
Es:

switch(parametro)
{
   case 0:
   case 1:
   case 2:
      qualcosa
      break
   case 3:
   case 4:
      altro
      break;
   default:
   ....
}

Cosa che non si puo' fare e' mettere codice tra un case e l'altro, senza usare un break. Il break, se si e' scritto del codice, e' obbligatorio.

_______________________________

29. Supporto nativo alle Properties, con piu' facile incapsulamento e controllo delle variabili

le STL includono una classe map; non conoscendo bene Properties non so se è paragonabile.

Non so neppure io, come dicevo le STL non le ho usate in ambito commerciale.
Le properties sono la possiblita' di trasformare una variabile in 2 metodi, uno per il SET e uno per il GET, con codice eseguito ogni volta che si legge o si scrive tale variabile.
Vengono chiamate proprieta' per distinguerle dalle variabili normali, e sono un metodo di controllo di flusso davvero utile, sopratutto per trasformare in modo indolore un codice contenente quella che era una variabile, alla quale si e' dovuto associare in seguito un pezzo di codice da eseguire ogni volta quella variabile e' stata usata.

private int i_pippo;

public int pippo{
get
{
   return  ModificoIlValoreDi(i_pippo);
}
set
{
   Log.Write("Valore pippo settato a %d",value);
   i_pippo=value;
}

...

pippo = 75;
int y=pippo-15;

pippo viene usato esternamente come variabile, ma ogni volta che si legge o si scrive si fa uso indirettamente di un pezzo di codice.

_____________________________________

32. Dispone gia' da standard di Enumeratori e Collezioni fortemente tipizzati.

anche il C++; si potrebbe obiettare che in certi casi quelli del C++ fanno un po' schifo (non scherzo).

Eh, non lo so, come detto non conosco le STL. (Non so neppure se fanno parte dello standard)

________________________________________

40. Se non si sa qualcosa il piu' delle volte e' sufficiente premere F1, senza dover navigare troppo sul Web. La maggior parte della documentazione e' tutta concentrata nella risorsa MSDN.

la documentazione sul C++ d'altra parte è tutt'altro che difficilmente reperibile: esistono ottimi siti come www.cplusplus.com e www.cppreference.com, ed inoltre esiste una versione della documentazione anche su MSDN stessa.

P.es. se voglio far suonare in modo asincrono un po' di musica techno in backgorund durante l'esecuzione di un mio programma, posso piazzare questo pezzo di codice qui:

WindowsMediaPlayer wmp = new WMPLib.WindowsMediaPlayer();
wmp.URL = "mms://wstream5a.di.fm/harddance";

A parte il numero di classi, di righe di codice, di ore di scrittura e di test necessarie per fare la stessa cosa in C++, anche utilizzando componenti gia' fatti come le librerie VLC o simili.
Per sapere come funziona un compontente come WindowsMediaPlayer, da dentro l'ambiente di programmazione schiaccio F1 sulla parola WindowsMediaPlayer si apre la guida e leggo.

Certo, mi potresti dire che il componente WindowsMediaPlayer e' in realta' una libreria scritta a sua volta in C++, circondata da chiamate managed per poter essere integrata a sua volta in C#.

E io rispondo che sono tanto felice di poter sfuttare a mia volta l'esperienza e la fatica di qualcuno,senza neppure virtualmente sapere come RTP, RSTP o MMS sono fatti (anche se in realta' RTP e RSTP li ho dovuti conoscere).
Anche chi usa il C++ o il C a sua volta sfrutta la fatica e l'esperienza di qualcuno, se non altro di chi ha scritto il compilatore o di chi ha scritto le librerie che si sono utilizzate.