Programmare sotto Linux

[dacav]

Originariamente inviato da mindwings

deformazione professionale , adora python ->

Si... ma piu` che altro questione di ordine

[marco.r]

Originariamente inviato da dacav

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.

Quando e' stato ideato il C++ una delle premesse era che non si dovevano aggiungere nuovi operatori al linguaggio. Tra quelli gia' presenti, << e >> sono stati scelti per il fatto di avere bassa priorita', riducendo il numero di parentesi necessarie, e proprio per il fatto che di solito non si fanno bit shift durante l'output su stream. Alla luce di questo non la vedo una scelta pessima (magari sono discutibili le premesse...).

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!

E' un problema che si presenta solo con i tipi predefiniti o comunque piccoli. Oltre una certa dimensione vuoi comunque passare per riferimento/puntatore per evitare il costo della copia. Se non altro in C++ lo puoi passare con puntatore/riferimento costante e sei sicuro che non lo modifichi per sbagli

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.

Sorry ma non ti seguo... se un usa un riferimento (non costante) e' proprio perche' vuole modificare il valore

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!

Eppure a volte e' quello che vuoi fare:

template <typename T>
class Matrix<T>
{ /* ... */
    T& operator()(int row, int col) { /* ... */ }
};
/* ... */
  Matrix m; 
  m(1,2) = 12;

(e a rigore l'l-value in questione non e' la funzione chiamata ma il suo valore di ritorno)

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/).

Francamente ritendo l'Object Orientation di GTK+ (intendo dire le librerie in C, non altri bindings) una cosa a mezza via tra l'abominevole e l'indecente, ma su queste cose ognuno ha le sue idee...

[dacav]

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.

In linea di massima do del mio ottenere esattamente questo: codice che funziona al primo botto . Ovviamente sono un umano, quindi non e' facile. Cio' nonostante non uso quasi mai il debugger, neanche quando programmo in altri linguaggi. Taluni individui sostengono che il debugger porti a fixare i sintomi piu` che le cause del problema, ed io sono d'accordo.

Detto questo il gdb e' un debugger estremamente potente e versatile. Dispone tra l'altro di frontend grafici (es. ddd) e di modalita` di debugging in remoto che vanno a braccetto con software di emulazione come QEMU (coppiata vincente per chi si accinge a fare del debugging a livello kernel o ad apprendere una nuova architettura hardware!)

Ti do` ragione sul fatto dell'integrazione con l'IDE... ma mica tanta sulla disponibilita` di strumenti.

[marco.r]

Originariamente inviato da dacav

Sarebbe IMHO piu` corretto un

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

sulla falsa riga di java e python.

Pero' allora diventa "pesante" la concatenazione di operazioni

cout << "Total :" << x.val1+x.val2 << "\n";

cout.write("Name:").write(x.val1+x.val2).write("\n");

A questo punto i vantaggi non sono piu' cosi' chiari.

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!

La differenza fondamentale tra puntatori e riferimenti e' che i primi fanno riferimento ad un indirizzo di memoria, i secondi ad un oggetto. Non e' una osservazione banale. Quando passo un puntatore ad una funzione (o metodo) ci sono due pezzi di codice diverso che "posseggono" quel pezzo di memoria. Chi ne e' responsabile ? Chi la deve liberare ? In un programma di una certa dimensione non e' raro introdurre errori nella gestone della memoria e sono tra i piu' subdoli da trovare. Con i riferimenti questo non accade perche' e sempre chiaro chi e' il proprietario. Altra cosa importante non e' possibile lasciare non inizializzati i riferimenti.
non a caso in un buon programma di C++ non ci sono molti puntatori che girano.

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.

Metodi non virtual sono implementati come funzioni. I metodi virtual tipicamente come dei puntatori in una tabella apposita nell'istanza della classe.

[k0nt3]

è vero che le porcherie si possono fare in qualsiasi linguaggio, ma è anche vero che il C++ sembra studiato per ammettere il maggior numero di porcherie.
per questo motivo ho sempre notato che un team che lavora in C++ si concentra su un suo sottoinsieme e rispetta certe regole di programmazione definite a priori.
nello sviluppo del kernel di linux hanno pensato di usare un "sottoinsieme" chiamato C e fino ad ora non si può dire che sia stata una pessima scelta. probabilmente in futuro lo sarà, ma bisogna anche contestualizzare nel tempo

[tomminno]

Originariamente inviato da dacav

In linea di massima do del mio ottenere esattamente questo: codice che funziona al primo botto .

Utopistico e scarsamente realizzabile in pratica.

Ovviamente sono un umano, quindi non e' facile. Cio' nonostante non uso quasi mai il debugger, neanche quando programmo in altri linguaggi. Taluni individui sostengono che il debugger porti a fixare i sintomi piu` che le cause del problema, ed io sono d'accordo.

Le cause del problema per quanto ho sperimentato sono sempre in difetti del codice che in particolari circostanze non funziona come deve.
Inoltre quando il codice è "fresco", il debug passo passo aiuta a trovare immediatamente l'errore, invece che far eseguire il codice e cercare di indovinare cosa è andato storto.

Detto questo il gdb e' un debugger estremamente potente e versatile. Dispone tra l'altro di frontend grafici (es. ddd) e di modalita` di debugging in remoto che vanno a braccetto con software di emulazione come QEMU (coppiata vincente per chi si accinge a fare del debugging a livello kernel o ad apprendere una nuova architettura hardware!)

DDD quello fermo da 2 anni?
Quello che comunque non riesce a mostrare il contenuto degli standard container del C++?
Sai che bello avere un vector di stringhe e non riuscire a vedere cosa c'è dentro.
Oppure una classe e non riuscire a visualizzare le sue variabili...

Ti do` ragione sul fatto dell'integrazione con l'IDE... ma mica tanta sulla disponibilita` di strumenti.

Non manca solo l'integrazione con l'IDE perchè DDD ha le stesse limitazioni che si incontrano in Code::Blocks o KDevelop.
Inoltre avere tutto all'interno di un IDE è certamente più produttivo.

Il debug è al momento lo stesso punto debole del C# sotto Linux. Sarà un caso?

[71104]

Originariamente inviato da marco.r

La differenza fondamentale tra puntatori e riferimenti e' che i primi fanno riferimento ad un indirizzo di memoria, i secondi ad un oggetto.

in C++ i riferimenti puntano sempre ad oggetti?
straccia il manuale dove hai letto questa amenità.

[71104]

Originariamente inviato da tomminno

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.

per non parlare della ricompilazione: in Visual C++ puoi modificare un sorgente mentre il programma è in esecuzione, salvarlo, ricompilarlo, e gli effetti sono immediati nel processo che gira. questo su Linux non è una mancanza del gdb, ma è una feature semplicemente irrealizzabile a causa di limitazioni del kernel.

[tomminno]

Originariamente inviato da 71104

per non parlare della ricompilazione: in Visual C++ puoi modificare un sorgente mentre il programma è in esecuzione, salvarlo, ricompilarlo, e gli effetti sono immediati nel processo che gira. questo su Linux non è una mancanza del gdb, ma è una feature semplicemente irrealizzabile a causa di limitazioni del kernel.

Sai alla fine non è che sia poi molto utile in quanto il più delle volte dopo la compilazione ti avvisa che le modifiche non consentono di continuare con il debug, quando funziona è utile ma non funziona quasi mai
Neanche in C# funziona, figuriamoci in C++.

[marco.r]

Originariamente inviato da 71104

in C++ i riferimenti puntano sempre ad oggetti?
straccia il manuale dove hai letto questa amenità.

Sorry, intendo in senso generico qualsiasi tipo di dato, e quindi non solo riferito ad una classe con metodi. Non mi veniva in mente un termine appropriato.
Quel che intendevo dire e' che e' difficile inizializzare un riferimento con dei dati non validi, e devi passare per un puntatore oppure per un cast "alla C".

[71104]

Originariamente inviato da tomminno

Sai alla fine non è che sia poi molto utile in quanto il più delle volte dopo la compilazione ti avvisa che le modifiche non consentono di continuare con il debug, quando funziona è utile ma non funziona quasi mai

eh lo so, lo so, come al solito sono l'unico fortunello da oggi persino quando gli altri difendono Windows

Neanche in C# funziona, figuriamoci in C++.

in C# non l'ho mai provato.

[DanieleC88]

Originariamente inviato da dacav

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...

No, Free Pascal Compiler (fpc) è un progetto a sé, non ha a che fare con la GNU Compiler Collection (gcc), che però a sua volta possiede un compilatore per codice Pascal, se non ricordo male.

Per il FPC c'è Lazarus, un'IDE che mima da vicino vari aspetti del Delphi. Non posso dirti però quanto sia completo, non lo provo da anni: col tempo ho perso interesse nei confronti del Pascal (e Object Pascal).

Originariamente inviato da dacav

Qualunque utente VI esperto lo difenderebbe fino alla morte...

Più che VI, è VIM che è grandioso, è estendibile fino a diventare praticamente un'IDE, e spesso ti accorcia molte operazioni altrimenti ripetitive che si compiono normalmente nello scrivere codice.

Per quanto riguarda il debugging di STL containers in GDB: http://staff.science.uva.nl/~gilad/stl/stl_gdb.html

[^TiGeRShArK^]

Originariamente inviato da DanieleC88

Più che VI, è VIM che è grandioso, è estendibile fino a diventare praticamente un'IDE, e spesso ti accorcia molte operazioni altrimenti ripetitive che si compiono normalmente nello scrivere codice.

tipo?

[tomminno]

Originariamente inviato da DanieleC88

Per quanto riguarda il debugging di STL containers in GDB: http://staff.science.uva.nl/~gilad/stl/stl_gdb.html

Come al solito gli IDE rimangono fuori.
Il debug tramite gdb è di una comodità impressionante.

[DanieleC88]

Originariamente inviato da ^TiGeRShArK^

tipo?

Ad esempio correzioni di errori di scrittura e ripetizione di comandi simili più volte (puoi ripetere l'ultimo comando con un punto se sei in modalità visuale), lo spostamento dall'inizio alla fine di un blocco, la ricerca dei prototipi delle funzioni o delle dichiarazioni di variabili con la pressione di un solo tasto, e anche il normale movimento fatto con hjkl è comodo se ti ci abitui, non devi nemmeno spostare le dita.
Et cetera... alla fine è questione di gusti, anche io preferisco un'IDE per le cose grosse (al momento uso Code::Blocks su Linux, Visual C++ Express su Windows), ma per cose rapide VIM non lo riesco ancora a sostituire.

Originariamente inviato da tomminno

Come al solito gli IDE rimangono fuori.
Il debug tramite gdb è di una comodità impressionante.

Dipende dal livello di integrazione che hanno con GDB, praticamente tutti gli IDE che ho visto permettono di mandare comandi personalizzati a GDB, quindi ispezionare le variabili è possibile anche mentre si fa un debug normale. Certo passarci sopra col mouse e controllare i valori è un'altra cosa... ma in mancanza di quello, se non altro funziona.

[cdimauro]

Originariamente inviato da dacav

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.

E' cambiato, nel senso che è andato migliorando.

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.

Già. Gli utenti che gravitano attorno al mondo open source tendono a non spendere soldi anche davanti a un eccellente prodotto, purtroppo.

Tranne ilsensine.

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...

Lo conosco da parecchio tempo e come sostituto del Turbo Pascal è ottimo, ma di rimpiazzare Delphi non se ne parla assolutamente, specialmente per la mancanza di un IDE, ma soprattutto di un framework completo, comodo e versatile come la VCL.

FreePascal è un compilatore estremamente veloce, perché utilizza un recursive descent parser scritto nello stesso linguaggio, ma questo purtroppo è anche il suo tallone d'Achille, visto che è molto più difficile aggiungere caratteristiche al compilatore rispetto a compiler-compiler quali Lex & Yacc, ma soprattutto ad ANTLR (alla PyCon2, da cui sono reduce, ho comprato la favolosa "guida definitiva" scritta dall'autore stesso; assolutamente imperdibile).

Purtroppo, come dici tu, spesso i compilatori legati a GNU sono dei front-end del GCC. Più precisamente, gli altri linguaggi (oltre al C) sono realizzati con Flex & Bison, ma utilizzano "pervasivamente" il C, tanto che vengono spesso estesi in "stile C".

Per fare un esempio, GNU Pascal è praticamente un C mascherato da Pascal.

E pensare che, quando nacque, il C venne deriso e apostrofato come "Pascal mascherato", visto che come linguaggio non ha portato nulla di innovativo in questa branca dell'informatica che non avessero già fatto i suoi predecessori...

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.

Cambiatela, non usatela, o usate altro.

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.

Il problema è che coi "secondo me" non arriviamo a niente. Hai qualche esempio di come la conoscenza della gestione della memoria appresa con C e/o C++ aiuti nello sviluppo di applicazioni con linguaggi che non hanno di questi problemi?

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.

Se non c'è coordinazione e rispetto delle regole utilizzate per lavorare a un progetto, piccolo o grosso che sia, è meglio evitare di collaborare.

Se la comunità che sviluppa Linux ha di questi problemi, vuol dire che ha serii problemi di gestione, e deve rivedere le proprie strategie. In primis cacciare gli incapaci.

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!

Per forza: se lo stesso autore del coding style poi non lo rispetta, non mi aspetto certo che lo facciano gli altri...

Come si suol dire dalle mie parti: "'u pisci feti 'ra testa" (il pesce puzza dalla testa).

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++.

Se i risultati sono quelli che hai detto prima, vuol dire che g++ è un compilatore decisamente scarso, visto che in queste condizioni dovrebbe generare almeno lo stesso codice.

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.

Assolutamente no. Strutture e classi in C++ differiscono esclusivamente dalla visibilità di default dei member: pubblica nel primo caso, e privata nel secondo caso.

Questo vuol dire che se scrivi una struct e una classe definendo al loro interno le STESSE cose, differiranno AL PIU' per la visibilità di alcune definizioni.

Ergo: una classe che definisce le stesse cose che in C definisce una struct, occupa la stessa memoria e genera (sulla carta) esattamente lo stesso codice per accedere alle variabili che in essa sono state definite.

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?

L'avevo già detto: ciò che avevi riportato sia in precedenza che adesso riguarda l'implementazione del compilatore, e non ha NULLA a che vedere col linguaggio.

Se lo stesso programma C compilato con un compilatore C++ dà risultati più scarsi, la colpa è inequivocabilmente del compilatore, ma NON del linguaggio.

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?

Esattamente.

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.

Non sono d'accordo: nella stesura del codice si devono usare le strutture che meglio risolvono un particolare (sotto)problema, non quelle "di moda" con un certo linguaggio.

Questo vuol dire che in C++ userei gli oggetti SE E SOLO SE ritenessi opportuno farlo, e ne farei a meno quando non avrebbe senso o non sarebbe conveniente.

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.

Non lo metto in dubbio, ma più che una curva VI ha una tangente di apprendimento. Il tutto IMHO, eh!

Comunque anche joe è qualcosa di più di un editor: dai un'occhiata all'utilissimo help online (Ctrl-K-H), e documentati sull'uso del file di configurazione (.joerc se non erro). Vedrai che non ha nulla da invidiare a editor più blasonati (a parte emacs, ma quello non è un editor, ma un calderone panteista ).

Qualunque utente VI esperto lo difenderebbe fino alla morte...

Chessò: i miei colleghi linuxiani?

Per il resto concordo col buon Marco.

Originariamente inviato da marco.r

Francamente ritendo l'Object Orientation di GTK+ (intendo dire le librerie in C, non altri bindings) una cosa a mezza via tra l'abominevole e l'indecente, ma su queste cose ognuno ha le sue idee...

Come non quotare: mai idea più orribile fu concepita da mente umana (dopo Perl ).

Originariamente inviato da dacav

In linea di massima do del mio ottenere esattamente questo: codice che funziona al primo botto . Ovviamente sono un umano, quindi non e' facile. Cio' nonostante non uso quasi mai il debugger, neanche quando programmo in altri linguaggi. Taluni individui sostengono che il debugger porti a fixare i sintomi piu` che le cause del problema, ed io sono d'accordo.

Detto questo il gdb e' un debugger estremamente potente e versatile. Dispone tra l'altro di frontend grafici (es. ddd) e di modalita` di debugging in remoto che vanno a braccetto con software di emulazione come QEMU (coppiata vincente per chi si accinge a fare del debugging a livello kernel o ad apprendere una nuova architettura hardware!)

Ti do` ragione sul fatto dell'integrazione con l'IDE... ma mica tanta sulla disponibilita` di strumenti.

Hai detto niente. Perfino il mio amatissimo HiSoft Devpac per Amiga (assemblatore per Motorola 68000+), era un IDE integrato col debugger: puoi immaginare quanto tempo sia passato da allora...

Comunque sentire ieri alla PyCon2 "ma tanto ai programmatori open source non servono gli IDE, perché usano gli editor" mi ha fatto raggelare il sangue e ricordare i tempi bui della programmazione...

Originariamente inviato da k0nt3

è vero che le porcherie si possono fare in qualsiasi linguaggio, ma è anche vero che il C++ sembra studiato per ammettere il maggior numero di porcherie.

Opinabile. E anche se fosse così, di validissime alternative al C ne esistono da tempo: basta usarle, invece di continuare con un linguaggio trapassato.

per questo motivo ho sempre notato che un team che lavora in C++ si concentra su un suo sottoinsieme e rispetta certe regole di programmazione definite a priori.

In buona sostanza, a causa dell'incapacità di apprendere e usare sapientemente un linguaggio complesso come il C++, si preferisce livellare la skillness di tutti al minimo comune denominatore...

nello sviluppo del kernel di linux hanno pensato di usare un "sottoinsieme" chiamato C e fino ad ora non si può dire che sia stata una pessima scelta. probabilmente in futuro lo sarà, ma bisogna anche contestualizzare nel tempo

Pessima scelta. Se non c'avessi fatto caso, siamo già a 2008 inoltrato. Quando prevedono di passare a un linguaggio al passo cosi tempi? Nel 2800?

Originariamente inviato da DanieleC88

No, Free Pascal Compiler (fpc) è un progetto a sé, non ha a che fare con la GNU Compiler Collection (gcc), che però a sua volta possiede un compilatore per codice Pascal, se non ricordo male.

Sì, ed è un aborto. MOOOOLTO meglio Free Pascal.

Per il FPC c'è Lazarus, un'IDE che mima da vicino vari aspetti del Delphi. Non posso dirti però quanto sia completo, non lo provo da anni: col tempo ho perso interesse nei confronti del Pascal (e Object Pascal).

Purtroppo Lazarus è ancora incompleto, e comunque quando finiranno avranno rimpiazzato soltanto le classi base della VCL.

Più che VI, è VIM che è grandioso, è estendibile fino a diventare praticamente un'IDE, e spesso ti accorcia molte operazioni altrimenti ripetitive che si compiono normalmente nello scrivere codice.

Come ad esempio dover premere la lettera I prima di poter iniziare a scrivere?

Per quanto riguarda il debugging di STL containers in GDB: http://staff.science.uva.nl/~gilad/stl/stl_gdb.html

Welcome to:

[tomminno]

Originariamente inviato da cdimauro

Il problema è che coi "secondo me" non arriviamo a niente. Hai qualche esempio di come la conoscenza della gestione della memoria appresa con C e/o C++ aiuti nello sviluppo di applicazioni con linguaggi che non hanno di questi problemi?

Si, uno che non parte dal C non capisce l'importanza dei metodi "Dispose" per il rilascio delle risorse anche in linguaggi dotati di GC.
Per cui non è vero che con il GC non devi pensare alla deallocazione delle risorse (che non significa solo deallocare memoria, ma pure chiudere connessioni al db/rete, chiudere un file...), anzi hai pure delle rogne per tutte le possibili eccezioni che possono generarsi.

Il vantaggio dei linguaggi managed è l'enorme libreria, non la gestione della memoria, perchè devi lottare comunque con il rilascio delle risorse.

Assolutamente no. Strutture e classi in C++ differiscono esclusivamente dalla visibilità di default dei member: pubblica nel primo caso, e privata nel secondo caso.

Questo vuol dire che se scrivi una struct e una classe definendo al loro interno le STESSE cose, differiranno AL PIU' per la visibilità di alcune definizioni.

Ergo: una classe che definisce le stesse cose che in C definisce una struct, occupa la stessa memoria e genera (sulla carta) esattamente lo stesso codice per accedere alle variabili che in essa sono state definite.

No strutture C e C++ sono diverse e generano sulla carta codice differente.
le strutture C++ hanno costruttore e distruttore esattamente come le classi (e anche l'uso di this), le strutture C no.
La differenza di codice dovrebbe (ripeto dovrebbe) essere nulla tra una struct C++ e una classe C++ con stessi metodi e stessa visibilità.

[marco.r]

Originariamente inviato da tomminno

Si, uno che non parte dal C non capisce l'importanza dei metodi "Dispose" per il rilascio delle risorse anche in linguaggi dotati di GC.
Per cui non è vero che con il GC non devi pensare alla deallocazione delle risorse (che non significa solo deallocare memoria, ma pure chiudere connessioni al db/rete, chiudere un file...), anzi hai pure delle rogne per tutte le possibili eccezioni che possono generarsi.

Il vantaggio dei linguaggi managed è l'enorme libreria, non la gestione della memoria, perchè devi lottare comunque con il rilascio delle risorse.

Dipende dal linguaggio. La soluzione "alla Java", ovvero di gestirle manualmente oppure aspettare il GC non e' la migliore ma neanche l'unica. Ad esempio in Ruby si puo' usare in modo molto elegante

File.open("myfile") do |file|
file.each_byte {....}
end

che fa si' che il file venga chiuso immediatamente finito il blocco. E' un pattern abbastanza standard nei linguaggi con GC.

[71104]

Originariamente inviato da tomminno

La differenza di codice dovrebbe (ripeto dovrebbe) essere nulla tra una struct C++ e una classe C++ con stessi metodi e stessa visibilità.

infatti questa è una cosa che non ho mai capito: che differenza c'è in C++ tra una struct e una classe?

in alcune situazioni ho visto usare addirittura l'ereditarietà con le struct; mi pare che in MFC la classe CPoint derivi dalla struct POINT.

[^TiGeRShArK^]

Originariamente inviato da marco.r

Dipende dal linguaggio. La soluzione "alla Java", ovvero di gestirle manualmente oppure aspettare il GC non e' la migliore ma neanche l'unica. Ad esempio in Ruby si puo' usare in modo molto elegante

File.open("myfile") do |file|
file.each_byte {....}
end

che fa si' che il file venga chiuso immediatamente finito il blocco. E' un pattern abbastanza standard nei linguaggi con GC.

infatti anche in C# c'è "using" che fa la stessa cosa