Programmare sotto Linux

[nico159]

Troppa fatica leggere prima di flammare?

con|te|stu|a|liz|zà|re
v.tr.
CO inserire in un contesto: c. una parola | considerare un fenomeno riferendolo al contesto nel quale è maturato e si è manifestato

Non è stato solo, ed è partito da Minix...

"Se ho visto più lontano, è perché stavo sulle spalle di giganti"

PulseAudio? Mi fai l'elenco di tutte librerie per la gestione dell'audio che sono state sviluppate per Linux?

http://www.gstreamer.net
Tu non hai bisogno di conoscere altro
Comunque non si parlava di come usare demoni sonori sia una cattiva scelta? :°)

[jappilas]

Originariamente inviato da nico159

con|te|stu|a|liz|zà|re
v.tr.
CO inserire in un contesto: c. una parola | considerare un fenomeno riferendolo al contesto nel quale è maturato e si è manifestato

http://www.gstreamer.net
Tu non hai bisogno di conoscere altro

un po' meno supponenza e frasi fatte, per favore

anche perchè se proprio si parla di contesto, faccio notare che la discussione ne sta andando avanti completamente fuori ...

un conto è se si afforntano le problematiche inerenti all' architettura e allo stato corrente, dell' OS, dal punto di vista tecnico e in ottica appunto di SW design e programmazione - un altro conto è se questo dà adito all' ennesimo flame condito da polemica personale, allora non è più accettabile

se vedrò ancora messaggi di questo tenore (da parte di chiunque) provvederò a chiudere il thead in via provvisoria e a segnalarlo al collega di sezione che valuterà se -eventualmente- riaprirlo

[Pixel452]

Finalmente ci sono riuscito, Ho installato Eclipse(la versione del sito) e sono riuscito a compilare un "HelloWorld". Per rimuovere quella vecchia come devo fare? Io sono andato nel Synaptic e l'ho rimossa da li, solo che non mi ha rimosso tutti i pacchetti figli che mi aveva installato all'inizio. Cmq nella directory /usr/local/ io non posso scrivere, suppongo a causa dei permessi, come faccio a scrivere in questa cartella?
Un ultima cosa, sul sito dell'NVIDIA dicono che CUDA non funziona su Ubuntu 8.04 perchè si appoggia al nuovo compilatore gcc non so che versione, c'è modo per selezionare che compilatore usare e quindi far andare CUDA anche con questa versione?

Grazie di tutto.

[arara]

Originariamente inviato da Pixel452

Per rimuovere quella vecchia come devo fare? Io sono andato nel Synaptic e l'ho rimossa da li, solo che non mi ha rimosso tutti i pacchetti figli che mi aveva installato all'inizio. Cmq nella directory /usr/local/ io non posso scrivere, suppongo a causa dei permessi, come faccio a scrivere in questa cartella?

Non devi metterlo per forza la, puoi anche lasciarlo nella tua home, cosi è anche piu comodo aggiornarlo e installare plugin.
Per cancellare le dipendenze che non servono piu usa deborphan.

[khelidan1980]

ma comunque basta che si metta il workspace nella home,i plugin,i progetti ecc vengono salvati lì anche se eclipse è in /usr

[cdimauro]

Originariamente inviato da k0nt3

1- non è incompatibile con un bel niente dato che tutto ciò che era stato fatto prima funziona con l'emulazione OSS

Che ha dei problemi.

2- usare OSS è una pessima scelta anche se l'obiettivo è la portabilità, ci sono librerie che non solo funzionano su tutti i sistemi unix-like, ma anche su quelli non unix-like. tra l'altro OSS non funziona nemmeno su OSX

Ricordavo funzionasse. Mi documenterò.

pulseAudio è l'evoluzione di esd, un server sonoro. ma possono anche averne scritte 10000 di librerie, tanto su linux tutte si appoggiano a alsa in qualche modo e quindi non c'è nessun problema.

A parte l'enorme spreco di risorse. Al solito.

Originariamente inviato da nico159

con|te|stu|a|liz|zà|re
v.tr.
CO inserire in un contesto: c. una parola | considerare un fenomeno riferendolo al contesto nel quale è maturato e si è manifestato

Già fatto ampiamente nel thread in questione, come avevo già detto, e che ti consiglio nuovamente di leggere.

Eventualmente se hai qualcosa da aggiungere a quanto già scritto il thread è ancora aperto.

http://www.gstreamer.net
Tu non hai bisogno di conoscere altro
Comunque non si parlava di come usare demoni sonori sia una cattiva scelta? :°)

Ne ignoravo l'esistenza. N-esimo progetto che reinventa la ruota, sprecando risorse.

[khelidan1980]

Originariamente inviato da cdimauro

A parte l'enorme spreco di risorse. Al solito.

PulseAudio non è uno spreco,anzi è forse la via più praticabile che porterà ad uno standard in fatto di audio in user space

Originariamente inviato da cdimauro

Ne ignoravo l'esistenza. N-esimo progetto che reinventa la ruota, sprecando risorse.

Ma gstreamer è un backend per la riproduzione audio e video,funziona indistintamente che sotto ci sia alsa o oss,quello che forse intendeva lui è che per sviluppare un app audio o video ti basta conoscere quelle librerie(che poi non è l'unica ma ci sono anche xine,mplayer) senza interessarti se a livello del kernel ci sia oss o alsa o altro!

[mindwings]

Originariamente inviato da cdimauro

Ne ignoravo l'esistenza. N-esimo progetto che reinventa la ruota, sprecando risorse.

La pluralità è un bene mai un male
se un sistema è decisamente più potente verrà adottato
dalla maggioranza delle distro... Su questo non ci piove

[dacav]

Prima di tutto saluto tutti. Sono nuovo qui... Sono stato indirizzato su questa discussione da un amico, ed ho pensato di iscrivermi, appositamente per dire la mia.

Sono uno studente di informatica, e ormai da anni utilizzo GNU/Linux in modo stabile e definitivo. Personalmente lo considero la migliore piattaforma su cui programmare ed apprendere la nobile arte della programmazione, per quanto riguarda sia gli strumenti che la varietà di linguaggi che si possono utilizzare.

Leggendo questo thread mi sono soffermato su alcuni post interessanti, che desidero commentare... Spero di poter dare il mio contributo alla discussione, o se non altro riportarla in carreggiata.

1. Parliamo di C e C++
   

   Originariamente inviato da cdimauro

   Pensi male, visto che il C++ è un SUPERSET del C, per cui puoi fare ALMENO le stesse cose del C, e... di più, se se ne sfruttano le caratteristiche peculari.
   
   In soldoni: non c'è alcun motivo per preferire il C al C++.

   
   Questo discorso è in parte vero: il C++ è stato progettato per essere retrocompatibile, dunque si può facilmente costruire una libreria C ed inglobarla in un programma C++ semplicemente giocando con il preprocessore.
   
   Benché esistano numerosi esempi di ottimi software scritti in C++, in generale la mia preferenza va al C. A mio avviso, buona parte delle astrazioni che il C++ ha introdotto portano ad una gestione del codice potente ma sfruttata in modo macchinoso. Ovviamente vado ad argomentare, visto che detta così la mia considerazione è buona solo per le flame!
   

   1. Gestione degli stream

      
      Il concetto di stream era già presente nella standard library del C. Con il C++ esso presenta un'interfaccia progettata in modo discutibile. Si pensi ad un'operazione di output a video:
      

      cout << "Hello, World\n";

      L'operatore "<<" è nato per essere uno shift bitwise. L'idea di usare l'overloading di questo operatore ha specificato una sintassi comune per due operazioni (quella di interazione con l'utente e quella di shift logico) che sono, a livello semantico, totalmente separate.
      

   2. Puntatori e referenze

      
      Tanti dicono che il C è nato per essere il migliore degli assembly. Ha la possibilità di mettere le mani nel singolo byte, dunque è assolutamente indispensabile poter gestire i puntatori.
      
      In linguaggi di alto livello (come potrebbero essere java o il mio adorato python) il concetto di puntatore non è così marcato, ma credo di trovare molti consensi nel dire che un programmatore esperto nell'usare i puntatori saprà gestire molto più consapevolmente un linguaggio con un alto livello di astrazione!
      
      Una scelta progettuale del C++ è stata quella di fornire retrocompatibilità con il C pur cercando di astrarre il comportamento del puntatore: di qui nascono le referenze, che putroppo sono una fonte naturale di errori e difficoltà di comprensione del codice. Ecco alcuni esempi:

      1. Passaggio parametri

         
         Il seguente codice potrebbe destare qualche perplessità in un eventuale lettore:
         

         int n,m;
         m = gargamella(n);

         Il lettore dovrebbe andare a controllare la firma della funzione "gargamella" per capire che si tratta di una referenza:
         

         int gargamella (int & x);

         La mia prima reazione ad una simile chiamata a funzione sarebbe "Wow! Quella variabile non è stata inizializzata". Indubbiamente l'uso del puntatore è molto più chiaro, visto che chi legge il codice prende atto immediatamente della possibilità di un side effect sul parametro! In un contesto più complicato del nostro gargamella, questo problema si farebbe sentire!
         

      2. Doppie variabili

         
         Si osservi ora questo codice:
         

         int aldo = 14;
         printf("%d\n", aldo);
         int & giovanni = aldo;
         printf("%d\n", giovanni);
         giovanni = 59;
         printf("%d\n%d\n", aldo, giovanni);

         Questo codice stampa in sequenza i valori 14, 14, 59, 59. Questo uso delle referenze è legale quanto rischioso: ancora una volta l'uso di un puntatore elargisce al programmatore una maggiore consapevolezza.
         

      3. Inaudito

         E' possibile fare questa cosa:
         

         int & minore (int & a, int & b)
         {
             a < b ? a : b;
         }
         
         int v1 = 3, v2 = 9;
         minore(v1,v2) = 5;

         Potente quanto una funzione che restituisce un puntatore. Ma non ci costruirei un design pattern: semanticamente parlando, una chiamata a funzione come l-value è un concetto piuttosto imbarazzante!

      Quindi il concetto di puntatore copre già abbondantemente tutte le esigenze.
      Come poi diceva l'utente -Slash (in fondo al post #24 di questo thread) il pivello medio della programmazione parte all'università con un C travestito da C++. Al primo giorno gli insegnano le referenze... da li in avanti farà una gran confusione tra indirizzi e puntatori... alla luce di questo, le referenze sono ridondanti e dannose.

   
   

   Ed ora l'altro piatto della bilancia. Secondo me l'unica cosa che tangibilmente manca nel C nativo è la programmazione ad oggetti. OO è indubbiamente un gran bel paradigma.
   
   Ad ogni modo, il fatto che la sintassi del C non fornisca tale opportunità non impedisce al programmatore di ragionare in termini di object oriented. Utilizzando header concepiti ad hoc con tipi opachi e funzioni statiche nelle implementazioni, si ottengono gli stessi vantaggi.
   
   Perfino il polimorfismo può essere gestito in C grazie ad un uso sapiente dei puntatori a funzione! Si pensi al concetto di callback (http://en.wikipedia.org/wiki/Callbac...ter_science%29)!
   
   Esistono dei framework interessanti a tal proposito: ultimamente, per portare un esempio, sono rimasto stupito nel vedere la potenza di GObject (http://library.gnome.org/devel/gobject/stable/).
   
   

2. Sull'implementazione del kernel in C++
   

   Originariamente inviato da jappilas

   più che "massa di incompetenti" .... forse "massa eterogenea di programmatori ognuno con la propria visione della situazione e il proprio livello e campo di competenze e magari qualche paraocchi" è più appropriato
   
   non ricordo bene quello che è successo sulla mailing list di linux, ricordo però alcuni episodi su quella di freebsd, tra cui quello riassunto e linkato qui, in cui si spaziava tra ( riassumendo)
   - "sviluppando in C si possono ottenere gli stessi risultati senza perdere in prestazioni";
   - le prestazioni del compilatore C++ rispetto a quello per il plain C
   - "C++ è un linguaggio dalla complessità tropo elevata per il kernel"; da questo derivano a loro volta altre argomentazioni:
   - - pochi degli attuali kernel developers, potrebbero continuare a contribuire in caso di migrazione ad un diverso linguaggio ;
   - - il Runtime da integrare nel kernel necessario per supportare le feature del linguaggio sarebbe troppo:
   - - - complesso ( oneroso per quanto concerne svilluppo e integrazione)
   - - - ingombrante
   - - - oneroso computazionalmente
   - - in virtù anche di questo, piuttosto di usare un subset del linguaggio, "tanto vale usare il C" - o un linguaggio ad hoc (DSL) (vedi appunto la proposta di adottare K )
   
   

   
   Qualche tempo fa ho lavorato su un kernel scritto in C++. Il mio obiettivo era quello di aggiungere il supporto per i mutex real-time, che dovevano essere implementati come system call. Per passare in modalità kernel è ovviamente necessario utilizzare gli interrupt software, cosa che si può fare solo mediante del codice assembly. Ho avuto modo di constatare la differenza tra il codice assembly prodotto dal C e quello prodotto dal C++. Il mio era C++. Posso dire per esperienza che è una grossa perdita di tempo.
   
   Tanto per rincarare la dose, in questo periodo sto mettendo mano in applicazioni embedded. Per la precisione mi trovo ad aggiungere un device driver ad un piccolo kernel, in modo da poter comunicare su un'interfaccia seriale RS485.
   
   Il mio sistema ha a disposizione la bellezza di 16 kb di memoria RAM... Morale della favola: le procedure devono essere scattanti, ma soprattutto non devono occupare inutilmente memoria, visto che si tratta di una risorsa preziosissima.
   
   Incredibile a dirsi, tutto questo discorso suggerisce un'interessante concetto: ad ognuno il suo compito. In my humble opinion il kernel va fatto in C.
   

3. Parlando di IDE
   

   Originariamente inviato da marco.r

   Eviterei sistemi di build integrati nell'IDE, perche' ti legano all'ambiente di sviluppo. Meglio uno esterno, che tanto di solito non e' difficile integrarlo con l'editor.

   
   Quoto in pieno, ed estendo.
   
   Nei miei oscuri trascorsi didattici posso vantare anche delle ore di lezione passate a programmare in Visual Basic. Ebbene lo ammetto. Trascurando le flame sull'usabilità dell'IDE che in quel periodo impestava lo scenario, parliamo un attimo della dipendenza del programmatore dall'ambiente: a quanto ricordo non era possibile portare il codice da una versione all'altra dello stesso visual basic. Salute!
   
   Ora, in questo thread stiamo parlando di programmazione in ambiente GNU/Linux... qualunque utente GNU/Linux sufficientemente rodato da aver compilato un pacchetto sorgente vi potrà dire le tre paroline magiche:
   

   configure && make && make install

   Ah, i bei tempi in cui giravo in Slackware senza sistemi di pacchettizzazione...
   
   Io sono un convinto utente VI. Nessuno riusirà mai a convincermi della potenza di un IDE, poiché VI è il mio editor, non manco di nulla. Tuttavia ho messo le mani in anjuta e in kdevelop... e anche se non l'ho fatto in modo approfondito, posso dire con un buon livello di certezza che entrambi utilizzino automake/autoconf e amici. Ok, ho barato: per kdevelop l'ho letto un minuto fa. :P
   
   Ovviamente questi non sono gli unici modi di gestire il codice sorgente, e forse nemmeno i più comodi, ma di certo sono i più diffusi. Anche se non posso vantare grandi conoscenze nel campo del loro utilizzo (so usare make in modo sufficientemente approfondito, ma al momento non ho tempo per apprendere altro) mi sento di consigliarne la lettura del sacro manuale: è sicuramente molto più formativo dell'utilizzo di un tool di building automatico! Per contro si tratta di un investimento in tempo.
   
   A coloro che sono interessati all'argomento segnalo l'esistenza di Scons (http://www.scons.org), un ottimo sistema di buld in cui mi sono imbattuto ultimamente... è molto più comodo di automake/autoconf.
   

OK! Credo di aver scritto più di quanto credevo di scrivere... mi sa che verrò bannato immediatamente per verbosità...
Spero quanto meno di aver contribuito in modo costruttivo alla discussione.

Saluti a tutti.

[cdimauro]

Originariamente inviato da khelidan1980

PulseAudio non è uno spreco,anzi è forse la via più praticabile che porterà ad uno standard in fatto di audio in user space

Ma gstreamer è un backend per la riproduzione audio e video,funziona indistintamente che sotto ci sia alsa o oss,quello che forse intendeva lui è che per sviluppare un app audio o video ti basta conoscere quelle librerie(che poi non è l'unica ma ci sono anche xine,mplayer) senza interessarti se a livello del kernel ci sia oss o alsa o altro!

Originariamente inviato da mindwings

La pluralità è un bene mai un male
se un sistema è decisamente più potente verrà adottato
dalla maggioranza delle distro... Su questo non ci piove

Ma son daccordo, eh! E' lo stesso principio dell'evoluzione che ci ha portato a quello che siamo: con milioni e milioni di tentativi, migliorando qualche specie e sbagliandone qualche milionata, prima o poi a qualche progetto "ben fatto" si arriva.

Non serve concentrare le forze per realizzare fin dall'inizio UN progetto "ben fatto": l'approccio "evolutivo" garantisce di arrivare ugualmente alla soluzione, prima o poi...

Originariamente inviato da dacav

Prima di tutto saluto tutti. Sono nuovo qui... Sono stato indirizzato su questa discussione da un amico, ed ho pensato di iscrivermi, appositamente per dire la mia.

Sono uno studente di informatica, e ormai da anni utilizzo GNU/Linux in modo stabile e definitivo. Personalmente lo considero la migliore piattaforma su cui programmare ed apprendere la nobile arte della programmazione, per quanto riguarda sia gli strumenti che la varietà di linguaggi che si possono utilizzare.

Per quanto mi riguarda gli ambienti di sviluppo "migliori" li trovo (da parecchi d'anni) per Windows (il mio prediletto è Delphi).

Leggendo questo thread mi sono soffermato su alcuni post interessanti, che desidero commentare... Spero di poter dare il mio contributo alla discussione, o se non altro riportarla in carreggiata.

1. Parliamo di C e C++
   
   

   
   Questo discorso è in parte vero: il C++ è stato progettato per essere retrocompatibile, dunque si può facilmente costruire una libreria C ed inglobarla in un programma C++ semplicemente giocando con il preprocessore.
   
   Benché esistano numerosi esempi di ottimi software scritti in C++, in generale la mia preferenza va al C. A mio avviso, buona parte delle astrazioni che il C++ ha introdotto portano ad una gestione del codice potente ma sfruttata in modo macchinoso. Ovviamente vado ad argomentare, visto che detta così la mia considerazione è buona solo per le flame!
   

   1. Gestione degli stream

      
      Il concetto di stream era già presente nella standard library del C. Con il C++ esso presenta un'interfaccia progettata in modo discutibile. Si pensi ad un'operazione di output a video:
      

      cout << "Hello, World\n";

      L'operatore "<<" è nato per essere uno shift bitwise. L'idea di usare l'overloading di questo operatore ha specificato una sintassi comune per due operazioni (quella di interazione con l'utente e quella di shift logico) che sono, a livello semantico, totalmente separate.
      

1. 1. Sulla scelta dell'operatore << se ne potrebbe discutere da qui all'eternità. Penso sia più che altro una questione di gusti. Ad esempio io avrei preferito questo:
      

      cout += "Hello, World\n";

      Ma poi per la lettura l'uso dell'operatore -= mi farebbe storcere il naso.
      
      In ogni caso l'overloading degli operatori è uno strumento molto utile, che tante volte aiuta a risolvere i problemi in maniera elegante e funzionale.
      
      Il fatto che a volte possa essere usato in maniera impropria o macchinosa, nulla toglie allo strumento. Alla fine è sempre colpa del programmatore.
      

      Puntatori e referenze

      
      Tanti dicono che il C è nato per essere il migliore degli assembly. Ha la possibilità di mettere le mani nel singolo byte, dunque è assolutamente indispensabile poter gestire i puntatori.
      
      In linguaggi di alto livello (come potrebbero essere java o il mio adorato python) il concetto di puntatore non è così marcato, ma credo di trovare molti consensi nel dire che un programmatore esperto nell'usare i puntatori saprà gestire molto più consapevolmente un linguaggio con un alto livello di astrazione!

      
      Di questo ne abbiamo ampiamente discusso in passato, ma essendo nuovo non puoi sapere. Non sono assolutamente d'accordo: la conoscenza dei puntatori non porta nulla di nuovo / buono a un linguaggio con un elevato livello di astrazione.
      
      In Python non ci sono puntatori e il fatto di sapere che ogni oggetto è rappresentato internamente come puntatore a una struttura di tipo PyObject non m'è mai servito in questi 3 anni e mezzo in cui lavoro stabilmente con questo linguaggio.
      Non trovo un solo esempio nelle diverse applicazioni che ho scritto in cui posso dire che la conoscenza dei puntatori abbia apportato il benché minimo contributo. E ne ho scritto di codice...
      

      Una scelta progettuale del C++ è stata quella di fornire retrocompatibilità con il C pur cercando di astrarre il comportamento del puntatore: di qui nascono le referenze, che putroppo sono una fonte naturale di errori e difficoltà di comprensione del codice. Ecco alcuni esempi:

      1. Passaggio parametri

         
         Il seguente codice potrebbe destare qualche perplessità in un eventuale lettore:
         

         int n,m;
         m = gargamella(n);

         Il lettore dovrebbe andare a controllare la firma della funzione "gargamella" per capire che si tratta di una referenza:
         

         int gargamella (int & x);

         La mia prima reazione ad una simile chiamata a funzione sarebbe "Wow! Quella variabile non è stata inizializzata". Indubbiamente l'uso del puntatore è molto più chiaro, visto che chi legge il codice prende atto immediatamente della possibilità di un side effect sul parametro! In un contesto più complicato del nostro gargamella, questo problema si farebbe sentire!
         

      1. Anche qui non sono d'accordo: provenendo da Pascal & derivati, col C ho sempre sofferto la mancanza della possibilità di poter passare variabili per riferimento anziché per valore. L'introduzione delle reference in questo senso è stata una vera benedizione.
         
         Il problema che porti è certamente reale, sia chiaro, ma penso che la bilancia penda verso i vantaggi dei reference (pensa poi, a linguaggi come Java e Python, che usano i reference per le strutture complesse: gli effetti collaterali sono indispensabili per poterle usare, e mi sembra ci si riesca benissimo senza alcun "marcatore" che ne identifica la "modificabilità").
         
         Il contesto si può anche complicare, ma è anche vero che la tendenza DEVE ESSERE quella di scrivere codice semplice, pulito, corto (no a funzioni chilometriche) e autoesplicativo.
         

         Doppie variabili

         
         Si osservi ora questo codice:
         

         int aldo = 14;
         printf("%d\n", aldo);
         int & giovanni = aldo;
         printf("%d\n", giovanni);
         giovanni = 59;
         printf("%d\n%d\n", aldo, giovanni);

         Questo codice stampa in sequenza i valori 14, 14, 59, 59. Questo uso delle referenze è legale quanto rischioso: ancora una volta l'uso di un puntatore elargisce al programmatore una maggiore consapevolezza.
         

         Idem come sopra. Mi sembra di notare che il problema qui è sempre il programmatore, piuttosto che il linguaggio.
         

         Inaudito

         E' possibile fare questa cosa:
         

         int & minore (int & a, int & b)
         {
             a < b ? a : b;
         }
         
         int v1 = 3, v2 = 9;
         minore(v1,v2) = 5;

         Potente quanto una funzione che restituisce un puntatore. Ma non ci costruirei un design pattern: semanticamente parlando, una chiamata a funzione come l-value è un concetto piuttosto imbarazzante!

      Anche qui, mi sembra un caso di cattivo utilizzo, che nulla toglie alla bontà dello strumento di per sé.
      

      Quindi il concetto di puntatore copre già abbondantemente tutte le esigenze.
      Come poi diceva l'utente -Slash (in fondo al post #24 di questo thread) il pivello medio della programmazione parte all'università con un C travestito da C++. Al primo giorno gli insegnano le referenze... da li in avanti farà una gran confusione tra indirizzi e puntatori... alla luce di questo, le referenze sono ridondanti e dannose.

      Col Pascal non è morto nessuno usando i parametri var.
      
      Portare dei singoli casi in cui l'uso delle reference porti più danni che benefici non ti consente, logica alla mano, di generalizzare il concetto e bocciare lo strumento, che di per sé è utile (e comodo).
      

   Ed ora l'altro piatto della bilancia. Secondo me l'unica cosa che tangibilmente manca nel C nativo è la programmazione ad oggetti. OO è indubbiamente un gran bel paradigma.
   
   Ad ogni modo, il fatto che la sintassi del C non fornisca tale opportunità non impedisce al programmatore di ragionare in termini di object oriented. Utilizzando header concepiti ad hoc con tipi opachi e funzioni statiche nelle implementazioni, si ottengono gli stessi vantaggi.
   
   Perfino il polimorfismo può essere gestito in C grazie ad un uso sapiente dei puntatori a funzione! Si pensi al concetto di callback (http://en.wikipedia.org/wiki/Callbac...ter_science%29)!
   
   Esistono dei framework interessanti a tal proposito: ultimamente, per portare un esempio, sono rimasto stupito nel vedere la potenza di GObject (http://library.gnome.org/devel/gobject/stable/).

   Anche di questo ne abbiamo già ampiamente parlato: è una porcata immane. Dai un'occhiata alla definizione e uso di un "oggetto" in C e prova a tradurlo in C++: noteresti una LEGGERA differenza fra i due approcci.
   
   In soldoni: se si deve programmatore a oggetti non ha senso affidarsi a dei surrogati soltanto perché si cerca di coprire (malamente e orribilmente) le carenze di un linguaggio di programmazione vecchio e anacronistico, che viene ancora usato o per "tradizione" (essendo fra i più diffusi) oppure per incapacità della gente di impararne di "migliori" (come il C++).
   
   Si passa a un linguaggio che offra il paradigma a oggetti in maniera nativa, e amen. Non ha senso complicarsi la vita con soluzioni come quelle adottata dal team di Gnome, che fanno venire l'orticaria soltanto a guardare il codice. E' la fiera del non-sense e dell'idiozia umana quello che hanno fatto: il museo degli orrori della programmazione (a "oggetti").
   

   Sull'implementazione del kernel in C++
   

   
   Qualche tempo fa ho lavorato su un kernel scritto in C++. Il mio obiettivo era quello di aggiungere il supporto per i mutex real-time, che dovevano essere implementati come system call. Per passare in modalità kernel è ovviamente necessario utilizzare gli interrupt software, cosa che si può fare solo mediante del codice assembly. Ho avuto modo di constatare la differenza tra il codice assembly prodotto dal C e quello prodotto dal C++. Il mio era C++. Posso dire per esperienza che è una grossa perdita di tempo.

   
   Ancora una volta (come già detto in passato) il problema è nella bontà del compilatore usato, non del linguaggio in sé.
   

   Tanto per rincarare la dose, in questo periodo sto mettendo mano in applicazioni embedded. Per la precisione mi trovo ad aggiungere un device driver ad un piccolo kernel, in modo da poter comunicare su un'interfaccia seriale RS485.
   
   Il mio sistema ha a disposizione la bellezza di 16 kb di memoria RAM... Morale della favola: le procedure devono essere scattanti, ma soprattutto non devono occupare inutilmente memoria, visto che si tratta di una risorsa preziosissima.
   
   Incredibile a dirsi, tutto questo discorso suggerisce un'interessante concetto: ad ognuno il suo compito. In my humble opinion il kernel va fatto in C.

   Fai ancora assunzioni sul fatto che il C++ richiederebbe più memoria rispetto al C. Al solito, dipende da come lo si utilizza e dalla bontà del compilatore.
   

   Parlando di IDE
   
   

   
   Quoto in pieno, ed estendo.
   
   Nei miei oscuri trascorsi didattici posso vantare anche delle ore di lezione passate a programmare in Visual Basic. Ebbene lo ammetto. Trascurando le flame sull'usabilità dell'IDE che in quel periodo impestava lo scenario, parliamo un attimo della dipendenza del programmatore dall'ambiente: a quanto ricordo non era possibile portare il codice da una versione all'altra dello stesso visual basic. Salute!
   
   Ora, in questo thread stiamo parlando di programmazione in ambiente GNU/Linux... qualunque utente GNU/Linux sufficientemente rodato da aver compilato un pacchetto sorgente vi potrà dire le tre paroline magiche:
   

   configure && make && make install

   Ah, i bei tempi in cui giravo in Slackware senza sistemi di pacchettizzazione...
   
   Io sono un convinto utente VI. Nessuno riusirà mai a convincermi della potenza di un IDE, poiché VI è il mio editor, non manco di nulla. Tuttavia ho messo le mani in anjuta e in kdevelop... e anche se non l'ho fatto in modo approfondito, posso dire con un buon livello di certezza che entrambi utilizzino automake/autoconf e amici. Ok, ho barato: per kdevelop l'ho letto un minuto fa. :P
   
   Ovviamente questi non sono gli unici modi di gestire il codice sorgente, e forse nemmeno i più comodi, ma di certo sono i più diffusi. Anche se non posso vantare grandi conoscenze nel campo del loro utilizzo (so usare make in modo sufficientemente approfondito, ma al momento non ho tempo per apprendere altro) mi sento di consigliarne la lettura del sacro manuale: è sicuramente molto più formativo dell'utilizzo di un tool di building automatico! Per contro si tratta di un investimento in tempo.
   
   A coloro che sono interessati all'argomento segnalo l'esistenza di Scons (http://www.scons.org), un ottimo sistema di buld in cui mi sono imbattuto ultimamente... è molto più comodo di automake/autoconf.

   
   Anche qui sono in totale disaccordo: la produttività di ambienti di sviluppo come Visual Studio & CBuilder per C/C++, il mio adorato Delphi per Pascal, ed Eclipse per Java (di cui ADORO le innumerevoli possibilità di rifattorizzazione del codice), SPE per Python (anche se mancano ancora alcuni strumenti, come la rifattorizzazione) ecc. è INARRIVABILE col classico editor.
   
   Anzi, usare un editor esterno mi riporta ai tempi bui della programmazione. Poi arrivò il Turbo Pascal con editor e compilatore integrato, e... fiat lux.
   
   L'evoluzione ha portato grandi cose: non capisco perché continuare a farsi del male rifiutandola.
   
   Per inciso, con Linux preferisco usare joe: vi non l'ho mai digerito.
   

OK! Credo di aver scritto più di quanto credevo di scrivere... mi sa che verrò bannato immediatamente per verbosità...
Spero quanto meno di aver contribuito in modo costruttivo alla discussione.

Saluti a tutti.

Guarda, se dovessero bannare te per questo tuo post, io avrei già dovuto esser buttato fuori da anni.

Ciao

[tomminno]

Il mio sistema ha a disposizione la bellezza di 16 kb di memoria RAM... Morale della favola: le procedure devono essere scattanti, ma soprattutto non devono occupare inutilmente memoria, visto che si tratta di una risorsa preziosissima.

Ah fortunato io ho lavorato con un ATmega8 con 8Kb

Incredibile a dirsi, tutto questo discorso suggerisce un'interessante concetto: ad ognuno il suo compito. In my humble opinion il kernel va fatto in C.

Perchè la tua esperienza è su kernel di piccole dimensioni, se pensi a quello che include oggi un OS da desktop forse il C++ è il linguaggio più indicato.

Io sono un convinto utente VI. Nessuno riusirà mai a convincermi della potenza di un IDE, poiché VI è il mio editor, non manco di nulla. Tuttavia ho messo le mani in anjuta e in kdevelop... e anche se non l'ho fatto in modo approfondito, posso dire con un buon livello di certezza che entrambi utilizzino automake/autoconf e amici. Ok, ho barato: per kdevelop l'ho letto un minuto fa. :P

E il debug?
Non dirmi che scrivi codice già perfettamente funzionante.
Purtroppo su Linux manca un IDE potente come VisualStudio.
Ad esempio le capacità di guardare all'interno di un oggetto negli IDE Linux sono molto limitate (non so se questo dipenda da gdb), con VisualStudio vedo tutto (e a dir la verità i tip del 2005 sono di una comodità spaventosa, non riesco più a rinunciarci).
Inoltre su Linux devo ancora trovare un IDE che mi permetta di spostare a piacimento avanti e indietro il posizionamento del debugger.
Pare che gdb possa farlo ma nessuno lo ha mai reso disponibile in versione umanamente usabile.

[k0nt3]

Originariamente inviato da tomminno

E il debug?
Non dirmi che scrivi codice già perfettamente funzionante.
Purtroppo su Linux manca un IDE potente come VisualStudio.
Ad esempio le capacità di guardare all'interno di un oggetto negli IDE Linux sono molto limitate (non so se questo dipenda da gdb), con VisualStudio vedo tutto (e a dir la verità i tip del 2005 sono di una comodità spaventosa, non riesco più a rinunciarci).
Inoltre su Linux devo ancora trovare un IDE che mi permetta di spostare a piacimento avanti e indietro il posizionamento del debugger.
Pare che gdb possa farlo ma nessuno lo ha mai reso disponibile in versione umanamente usabile.

hai provato kdevelop? non è certo al livello di visual studio (però il 2005 è un macigno altro che eclipse..), ma non è affatto male. la versione 4 (attualmente alpha) promette molto bene

[khelidan1980]

Originariamente inviato da cdimauro

Ma son daccordo, eh! E' lo stesso principio dell'evoluzione che ci ha portato a quello che siamo: con milioni e milioni di tentativi, migliorando qualche specie e sbagliandone qualche milionata, prima o poi a qualche progetto "ben fatto" si arriva.

Non serve concentrare le forze per realizzare fin dall'inizio UN progetto "ben fatto": l'approccio "evolutivo" garantisce di arrivare ugualmente alla soluzione, prima o poi...

parti da un presupposto sbagliato,dietro a linux non c'è una singola azienda(leggi Microsoft o Apple ad esempio) che puoi impostare la via,la teoria dell'evoluzione è l'unica ammessa,certo in alcuni casi ciò equivale a perdere tempo,ma non mi sembra ci sia altra strada praticabile!

Originariamente inviato da cdimauro

SPE per Python (anche se mancano ancora alcuni strumenti, come la rifattorizzazione) ecc. è INARRIVABILE col classico editor.

Avevo proprio in mente di chiederti consiglio su questo! Sto iniziando a guardare python,per ora uso pydev per eclipse,tu consigli spe?Lo installato ma ancora non lo guardato

[cdimauro]

Originariamente inviato da tomminno

Ah fortunato io ho lavorato con un ATmega8 con 8Kb

Perchè la tua esperienza è su kernel di piccole dimensioni, se pensi a quello che include oggi un OS da desktop forse il C++ è il linguaggio più indicato.

Ma anche con kernel di piccoli dimensioni si può usare il C++. C++ non è soltanto programmazione a oggetti.

Ovviamente posto che esistano compilatori di buona qualità, che non producano codice inefficiente soltanto per il fatto di essere passati da C a C++ (in buona sostanza: usando gli STESSI strumenti del C, il codice C++ dovrebbe essere ALMENO efficiente quanto quello prodotto da un compilatore C).

E il debug?
Non dirmi che scrivi codice già perfettamente funzionante.
Purtroppo su Linux manca un IDE potente come VisualStudio.
Ad esempio le capacità di guardare all'interno di un oggetto negli IDE Linux sono molto limitate (non so se questo dipenda da gdb), con VisualStudio vedo tutto (e a dir la verità i tip del 2005 sono di una comodità spaventosa, non riesco più a rinunciarci).
Inoltre su Linux devo ancora trovare un IDE che mi permetta di spostare a piacimento avanti e indietro il posizionamento del debugger.
Pare che gdb possa farlo ma nessuno lo ha mai reso disponibile in versione umanamente usabile.

Concordo in toto.

Posto che il debugger è il MALE. (C) 2007-2008 by fek

Originariamente inviato da k0nt3

hai provato kdevelop? non è certo al livello di visual studio (però il 2005 è un macigno altro che eclipse..), ma non è affatto male. la versione 4 (attualmente alpha) promette molto bene

Quando sarà in versione finale ne riparleremo.

Originariamente inviato da khelidan1980

parti da un presupposto sbagliato,dietro a linux non c'è una singola azienda(leggi Microsoft o Apple ad esempio) che puoi impostare la via,la teoria dell'evoluzione è l'unica ammessa,certo in alcuni casi ciò equivale a perdere tempo,ma non mi sembra ci sia altra strada praticabile!

C'è, c'è: il Buon Senso di realizzare un gruppo di lavoro su un ben preciso progetto a cui partecipano tutte le realtà (interessate) legate a open source et similia.

E non ci vuole molta intelligenza per capirlo: semplicemente tanta buona volontà di farlo.

Avevo proprio in mente di chiederti consiglio su questo! Sto iniziando a guardare python,per ora uso pydev per eclipse,tu consigli spe?Lo installato ma ancora non lo guardato

Provalo: io lo uso da 3 anni buoni e mi ci trovo abbastanza bene. Come dicevo mancano ancora degli strumenti come la rifattorizzazione, ma complessivamente per me è il miglior IDE integrato per Python (per lo meno free).

[k0nt3]

Originariamente inviato da cdimauro

Quando sarà in versione finale ne riparleremo.

ovviamente consigliavo di provare kdevelop3 che è già finale

[cdimauro]

Già provato tempo fa: non regge il confronto con Visual Studio.

Vediamo cos'avrà di buon la versione 4.

[tomminno]

Originariamente inviato da k0nt3

hai provato kdevelop? non è certo al livello di visual studio (però il 2005 è un macigno altro che eclipse..), ma non è affatto male. la versione 4 (attualmente alpha) promette molto bene

Trovo decisamente superiore Code::Blocks, ma ancora non ci siamo.
In ogni caso le limitazioni in debug sono identiche tra i 2 IDE, il vantaggio di Code::Blocks è l'intellisense.

[jappilas]

Originariamente inviato da dacav

OK! Credo di aver scritto più di quanto credevo di scrivere...
mi sa che verrò bannato immediatamente per verbosità...

ma figurati

Spero quanto meno di aver contribuito in modo costruttivo alla discussione.

direi di sì
noto che ti ha già risposto cdmauro ma... hai comunque un primato, è la prima volta che vedo dei quote indentati

[mindwings]

Originariamente inviato da dacav

In linguaggi di alto livello (come potrebbero essere java o il mio adorato python)

Originariamente inviato da jappilas

ma figurati
direi di sì
noto che ti ha già risposto cdmauro ma... hai comunque un primato, è la prima volta che vedo dei quote indentati

deformazione professionale , adora python ->

[dacav]

Originariamente inviato da cdimauro

Per quanto mi riguarda gli ambienti di sviluppo "migliori" li trovo (da parecchi d'anni) per Windows (il mio prediletto è Delphi).

Ho "lavorato" in delphi per un paio d'anni alle superiori (ovviamente lo metto tra virgolette, visto che puoi immaginare il genere di cose che si programmano in ambito didattico...), e ti diro`che non mi trovavo poi male.

E' passato molto tempo, non ricordo piu` la sintassi del pasquale... L'unica cosa che ricordo e' la costruzione delle interfaccie grafiche. Magari nel frattempo e' anche cambiato tutto.

A livello di programmazione in ambito GNU/Linux (in fondo il thread parla di questo), so che esisteva il progetto kylix, portato avanti da Borland... ma non e' mai stato di grande successo.

Esistono tutt'ora delle implementazioni libere del pascal (free pascal, e relativo compilatore, http://www.freepascal.org). Ecco cosa ne pensa la mia debian:

The Free Pascal Compiler is a Turbo Pascal 7.0 and Delphi compatible 32/64-bit Pascal Compiler. It comes with a fully compatible TP 7.0 runtime library. Some extensions are added to the language, like function overloading. Shared libraries can be linked and created. Basic Delphi support is already implemented (classes, exceptions, ansistrings, open arayes). This package contains dependency on all FPC packages provided on your architecture. You need at least the RTL package before you can start compiling anything, but if you want to write any real-world program, you may need to install this meta package.

Dal sito noto che e' un progetto che puo' vantare anche dei cross compiler! E' una feature tipica di gcc... In genere, quando si parla di compilatori sotto GNU/Linux si ha a che fare con dei front-end del gcc. Dovrei documentarmi...

Originariamente inviato da cdimauro

Sulla scelta dell'operatore << se ne potrebbe discutere da qui all'eternità. Penso sia più che altro una questione di gusti. Ad esempio io avrei preferito questo:

cout += "Hello, World\n";

Ma poi per la lettura l'uso dell'operatore -= mi farebbe storcere il naso.

Ovviamente. Il problema deriva dal fatto che sia l'operatore di shift che l'operatore di somma short-hand sono semanticamente associati ad operazioni che hanno poco a che vedere con l'I/O...

Sarebbe IMHO piu` corretto un

cout.write("Hello world\n");

sulla falsa riga di java e python.

Originariamente inviato da cdimauro

In ogni caso l'overloading degli operatori è uno strumento molto utile, che tante volte aiuta a risolvere i problemi in maniera elegante e funzionale.

Il fatto che a volte possa essere usato in maniera impropria o macchinosa, nulla toglie allo strumento. Alla fine è sempre colpa del programmatore.

Su cio` concordo. L'assenza di overloading e' una delle cose che mi infastidiscono maggiormente nel java, per esempio... Nel python e' una delle cose che mi divertono maggiormente. La standard library del C++ ne abusa.

Originariamente inviato da cdimauro

Di questo ne abbiamo ampiamente discusso in passato, ma essendo nuovo non puoi sapere. Non sono assolutamente d'accordo: la conoscenza dei puntatori non porta nulla di nuovo / buono a un linguaggio con un elevato livello di astrazione.

In Python non ci sono puntatori e il fatto di sapere che ogni oggetto è rappresentato internamente come puntatore a una struttura di tipo PyObject non m'è mai servito in questi 3 anni e mezzo in cui lavoro stabilmente con questo linguaggio.
Non trovo un solo esempio nelle diverse applicazioni che ho scritto in cui posso dire che la conoscenza dei puntatori abbia apportato il benché minimo contributo. E ne ho scritto di codice...

Non e' questo il punto di vista a cui mi riferisco: non sto parlando di bonta` del linguaggio che permette la manipolazione del puntatore.

Il programmatore di qualsivoglia linguaggio di alto livello puo` ignorare il puntatore. Sto dicendo che un programmatore avente una buona esperienza con C/C++ dispone di una forma mentis orientata alla gestione della memoria, che secondo me si fa sentire nelle scelte implementative anche quando il linguaggio non contempla l'uso di puntatori.

Originariamente inviato da cdimauro

Anche qui non sono d'accordo: provenendo da Pascal & derivati, col C ho sempre sofferto la mancanza della possibilità di poter passare variabili per riferimento anziché per valore. L'introduzione delle reference in questo senso è stata una vera benedizione.

In effetti forse ho fatto di tutta l'erba un fascio... immagino sia questione di abitudine. Io ho un forte orientamento al C dettato da un lungo studio personale sul medesimo...

Originariamente inviato da cdimauro

Il problema che porti è certamente reale, sia chiaro, ma penso che la bilancia penda verso i vantaggi dei reference (pensa poi, a linguaggi come Java e Python, che usano i reference per le strutture complesse: gli effetti collaterali sono indispensabili per poterle usare, e mi sembra ci si riesca benissimo senza alcun "marcatore" che ne identifica la "modificabilità").
[...]

Idem come sopra. Mi sembra di notare che il problema qui è sempre il programmatore, piuttosto che il linguaggio.

Anche qui, mi sembra un caso di cattivo utilizzo, che nulla toglie alla bontà dello strumento di per sé.

Certo! E guarda caso ecco spuntare il discorso dei puntatori: un programmatore C sapra` che il reference e' semplicemente un'implementazione trasparente del puntatore...

Ed e' proprio il cattivo utilizzo del reference che e' dannoso per il C++. Java e Python usano sempre il reference, implicitamente. Nel C++ devi esplicitarlo, o usare il puntatore. Ovviamente il tutto dipende dalla disciplina del programmatore... come sempre. Se e' per questo in qualsiasi linguaggio si possono fare delle gran porcherie!

IMHO nel C++ la questione puntatore/referenza e' marcata per una ragione specifica: ci sono programmatori derivanti dal C che utilizzeranno piu` volentieri il puntatore, e programmatori derivanti da altri linguaggi che utilizzeranno piu` volentieri le reference... in un progetto collaborativo non banale si rischia di ottienere un bel codice mixato, senza una struttura uniforme... specialmente su un progetto grosso come, per restare in tema, il kernel Linux.

Si, ok... sappiamo che non e' scritto in C++... ho citato Linux perche` il codice e' piuttosto frammentato nelle convenzioni, nonostante i documenti sul coding style!

Originariamente inviato da cdimauro

Ancora una volta (come già detto in passato) il problema è nella bontà del compilatore usato, non del linguaggio in sé.

Fai ancora assunzioni sul fatto che il C++ richiederebbe più memoria rispetto al C. Al solito, dipende da come lo si utilizza e dalla bontà del compilatore.

A tal proposito, oggi con un mio collega abbiamo fatto alcuni test di compilazione e successivo disassemblaggio di programmi di esempio. Abbiamo usato sia il C che il C++, compilando con gcc/g++. Al momento l'unica cosa degna di nota e' il runtime del C++ che sembra essere piu` esoso in termini di spazio...

Per il momento abbiamo testato soltanto dei semplici pezzi di codice C compilati come C++. Sarebbe tecnicamente difficile tentare un confronto su una feature come la programmazione ad oggetti... dunque mi accontentero' dei punti in comune: le strutture.

So che in C semplicemente vengono tradotte in offset a compile time. Non so cosa fa il C++, ma di certo le deve gestire come classi. Appena avro` tempo/voglia di farlo faro` qualche test. Ti faro' sapere.

Ovviamente con il mio collega si discuteva del fatto che compilatori diversi potrebbero comportarsi in modo diverso. Magari qualche lettore di questo thread potrebbe fare qualche esperimento analogo con altri compilatori?

Ad ogni modo non ha senso scrivere del codice C e compilare con g++... se si usa il C++ e' perche` si necessita delle strutture aggiuntive che questo apporta, dico bene? Mi sto chiedendo quale potrebbe essere un buon test per poter descrivere un confronto tangibile. Forse potrebbe essere una buona idea scrivere lo stesso programma nei due linguaggi usando, nelle due implementazioni, gli approcci tipici dei due rispettivi linguaggi.

Originariamente inviato da cdimauro

Anche qui sono in totale disaccordo: la produttività di ambienti di sviluppo come Visual Studio & CBuilder per C/C++, il mio adorato Delphi per Pascal, ed Eclipse per Java (di cui ADORO le innumerevoli possibilità di rifattorizzazione del codice), SPE per Python (anche se mancano ancora alcuni strumenti, come la rifattorizzazione) ecc. è INARRIVABILE col classico editor.

[...]

Per inciso, con Linux preferisco usare joe: vi non l'ho mai digerito.

Joe e' un editor, grosso modo della potenza di gnome-editor o di mousepad... Vi e' piu` che un editor. Ha indubbiamente una certa curva di apprendimento, ma se usato correttamente e' uno strumento eccezionalmente versatile, particolarmente indicato per la programmazione. Qualunque utente VI esperto lo difenderebbe fino alla morte...

Originariamente inviato da cdimauro

Guarda, se dovessero bannare te per questo tuo post, io avrei già dovuto esser buttato fuori da anni.