Programmare sotto Linux

[Pixel452]

Ciao a tutti,

Ho da poco installato una distribuzione Linux( Ubuntu ), sto cercando ancora di capire come funzionano le cose in questo SO. Una di queste cose è la programmazione, io ho sempre programmato sotto Windows, generalmente con Visual Studio, volevo fare qualche esperiento con Linux. Ho installato Anjuta come ambiente di sviluppo, ho creato un progetto base GNOME, il problema è che quando cerco di compilare non mi trova i vari header che vengono inclusi, tipo: gnome.h, bonobo.h. Nelle preferenze dell'IDE ho visto che sono incluse alcune librerie, però non trovo delle opzioni tipo "Include" o cose simili, dove posso settare i percorsi necessari per compilare? Qualcuno potrebbe dirmi come fare per risolvere questo problema(magari mi mancano alcune librerie) e magari consigliarmi anche qualche IDE(questo non mi dispiace ma magari c'è di meglio)?

Grazie.

p.s. Ma perchè in Linux si usa prevalentemente il C e non il C++?

[VICIUS]

Apri synaptic e assicurati di aver installato tutti i vari pacchetti di sviluppo che ti servono per compilare la tua applicazione. Li trovi facilmente perché il nome termina con il suffisso -dev.

Per la questione C/C++ dipende molto dal de usato. Hai installato ubuntu che di default usa Gnome che è scritto in C. Installando una distribuzione come Kubuntu che ha KDE come DE predefinito avresti visto scritto quasi tutto in C++.

[cdimauro]

p.s. Ma perchè in Linux si usa prevalentemente il C e non il C++?
Generalmente è un problema di capacità (individuali): il C++ è troppo complesso per essere assimilato e usato correttamente, per cui i programmatori più scarsi ripiegano sul C.

[amedeoviscido]

Spero tu stia scherzando spero

[cdimauro]

Assolutamente no, e l'argomento è stato già AMPIAMENTE affrontato in passato (anche recente).

Ti suggerisco di fare qualche ricerca proprio in questa sezione.

[khelidan1980]

Assolutamente no, e l'argomento è stato già AMPIAMENTE affrontato in passato (anche recente).

Ti suggerisco di fare qualche ricerca proprio in questa sezione.

Non so se la tua era un provocazione nei confronti di chi scrive sw per linux,comunque se il kernel è in C,c'è una ragione ben precisa storica più che tecnica

[Pixel452]

No dai, ci credo poco, il C++ non è sta gran difficoltà rispetto al C, anzi, secondo me è persino più semplice come impostazione mentale e come "ordine" del codice.
Cmq, non sono ancora riuscito a far compilare il programma di esempio, ho visto i pacchetti con "-dev" ma sono tantissimi, in oltre i file che mi dice di non trovare sul mio PC ci sono, penso solo che sia un problema di settaggio di Anjuta, qualcuno che lo usa mi spiega come fare?
Ma voi che IDE usate per programmare? Eclipse è buono?
Io vorrei qualcosa di paragonabile al Visual Studio, diciamo il più simile possibile.

Poi, altre due cose:
Dando uno sguardo hai temi per GNOME, mi sembra di capire che la grafica funziona ancora con le bitmap, e non con interfaccia vettoriale, il che non mi piace affatto, mi sono abituato troppo bene con il WPF sotto Windows, che è veramente una cosa fenomenale. C'è niente di simile sotto Linux? Ho visto che Compix-Fusion non è male e gestisce le finestre come oggetti 3D, c'è modo di sfruttare questa potenzialità anche all'interno delle proprio finestre? Intendo a livello di controlli base.

Come ultima cosa mi domandavo se da queste parti c'è qualcuno che usa CUDA sotto linux, sto cominciando studiarla e non mi dispiacerebbe qualche consiglio su come impostarla(anche se per ora non riesco neanche a compilare una banalissima finestra:D ). Per ora mi sa che me la tengo su Windows.

[Pixel452]

Resta il fatto che per il kernel il C potrebbe(sicuramente direi) essere più veloce, la cosa eccessiva mi sembra usarlo per l'interfaccia( che palle:O ).

[khelidan1980]

Resta il fatto che per il kernel il C potrebbe(sicuramente direi) essere più veloce, la cosa eccessiva mi sembra usarlo per l'interfaccia( che palle:O ).

Se ne parla da anni di portare le gtk+ ad oggetti,vedremo con lo sviluppo della terza versione,comunque questo per ciò che riguarda Gnome,sappi che esistono molti altri de,tra cui kde,costruito sopra le qt,scritte in c++ ,imho una delle migliori libreie per interfacce attualmente in circolazione!

per quanto riguarda gli ide,eclipse potrebbe andare a patto di usare l'ultima versione del plugin per il C/C++,se vuoi il meglio su linux però devi andare su kdevelop,che integra anche un editor visuale per le qt

Edit:restando in ambito gnome,secondo me la scelta più sensata ora per scrivere programmi con annessa interfaccia è python con pygtk (http://www.pygtk.org/)

[cdimauro]

Non so se la tua era un provocazione nei confronti di chi scrive sw per linux,comunque se il kernel è in C,c'è una ragione ben precisa storica più che tecnica
La ragione è questa: http://www.hwupgrade.it/forum/showthread.php?t=1547246
No dai, ci credo poco, il C++ non è sta gran difficoltà rispetto al C, anzi, secondo me è persino più semplice come impostazione mentale e come "ordine" del codice.
Questo lo dici tu. :) Vedi sopra. :p

[khelidan1980]

La ragione è questa: http://www.hwupgrade.it/forum/showthread.php?t=1547246

Questo lo dici tu. :) Vedi sopra. :p

Comunque non credo lui con programmazione sotto linux intendesse esclusivamente kernel

[cdimauro]

Leggi attentamente tutto il suo messaggio. C'è da piangere...

[khelidan1980]

Leggi attentamente tutto il suo messaggio. C'è da piangere...

Ammetto di essermi fermato a "C++ is a horrible language" :p ,volevo giusto dire spesso le sue idee sono molto "singolari" e non troppo condivise dalla comunità! ;)

[cdimauro]

Non sono condivise anche da persone razionali e dotate di buon senso. :asd:

[-Slash]

prova ad installare build-essential. dovrebbe avere tutto il necessario per programmare(ovviamente con le librerie standard, se vuoi usare altre librerie le devi installare)


sudo apt-get install build-essetial


per quanto riguarda il discorso c, io penso sia piu adatto per un kernel. e poi vorrei vedere le persone che in questo momento stanno smerdando torvalds a scrivere un kernel, visto quanto sono bravi.

[khelidan1980]

prova ad installare build-essential. dovrebbe avere tutto il necessario per programmare(ovviamente con le librerie standard, se vuoi usare altre librerie le devi installare)


sudo apt-get install build-essetial


per quanto riguarda il discorso c, io penso sia piu adatto per un kernel. e poi vorrei vedere le persone che in questo momento stanno smerdando torvalds a scrivere un kernel, visto quanto sono bravi.

il fatto è che tutta la merda che si tira dietro non è infondata alle volte,come ha detto cdimauro nell'altro thread,ha avuto al fortuna di avere dietro a se persone con le OO,guarda come ha fatto fuori Con kolivas dopo tutto il lavoro che ha fatto per Linux,o meglio sarebbe da dire come non lo ha mai ufficialmente considerato

[arara]

Cmq, non sono ancora riuscito a far compilare il programma di esempio, ho visto i pacchetti con "-dev" ma sono tantissimi, in oltre i file che mi dice di non trovare sul mio PC ci sono, penso solo che sia un problema di settaggio di Anjuta, qualcuno che lo usa mi spiega come fare?

Per trovare in quale pacchetto si trovano i file header che ti servono per compilare un programma, puoi usare questo comando:
# apt-file search header.h
e poi installi i pacchetti che ti dice.

Se, ad esempio, vuoi usare la libreria xml2, devi scaricare il pacchetto libxml2-devel. Quando poi compili il programma devi indicare al linker che stai usando quella libreria col parametro -l:
gcc -lxml2 main.c
se la libreria non si trova nel path standard devi indicare il percorso in cui si trova col parametro -L:
gcc -L/path/libxml2 -lxml2 main.c
Se usi un IDE, qualunque esso sia, devi indicare nelle proprietà del progetto gli stessi valori.
Anjuta non lo conosco, ma se invece usi KDevelop puoi creare un progetto basato su automake che si arrangia da solo a creare il makefile.

[mindwings]

p.s. Ma perchè in Linux si usa prevalentemente il C e non il C++?

Generalmente è un problema di capacità (individuali): il C++ è troppo complesso per essere assimilato e usato correttamente, per cui i programmatori più scarsi ripiegano sul C.

Hai appena detto che i programmatori linux usando C sono scarsi. :tapiro:
Il linguaggio è soltanto uno strumento che ti può facilitare o meno la vita
ciò che conta sono le capacità di design che si acquistano con l'esperienza. Le discussioni precedenti non sono LA bibbia
le opinioni si possono condividere o meno e discuterne altre 20/50/1000 volte può aiutare a sviluppare un senso
critico purchè si apportino pareri senza ostentarli per LA VERITA' :D


Generalizzare fa male :) di programmatori ce ne sono di bravi e meno bravi sia su piattaforma gnu/linux che windows .

[Pixel452]

Grazie per le risposte.

apt-file funziona, non male, grazie.
Ho aggiunto le librerie libgnome-dev e libgsf-gnome-1-dev, inutilmente perchè gli header mancanti erano anche in librerie che avevo già. Quelle incluse in Anjuta sono già installate.

Magari domani provo Eclipse che mi sembra un attimino più famigliare al VS.
pygtk se non ho capito male si basa su phyton? Sinceramente non è che mi ispiri molto, a questo punto preferisco rimanere sul C/C++.
I Build-Essential da quello che ho visto servono solo in determinati casi.
Mi sa che i miei problemi sono dovuti ad anjuta più che a librerie mancanti, provo eclipse e vedo come va, visto che KDevelop non posso usarlo perchè sono su GNOME.

[khelidan1980]

kdevelop puoi usarlo,ti tirerà giù un po di dipendenze di kde,ma al giorno d'oggi non credo sia un problema,ne di memoria ne di spazio su disco! ;)

pygtk sono per python,ovviamente se non ti piace il linguaggio c'è poco da fare,io la vedo come una semplificazione notevole piuttosto che sviluppare in C,però si sa degustibus! ;)

Eclipse e plugin annesso scaricali da sito e non dai repo di ubuntu,perchè non sono aggiornati

[marco.r]

Se, ad esempio, vuoi usare la libreria xml2, devi scaricare il pacchetto libxml2-devel. Quando poi compili il programma devi indicare al linker che stai usando quella libreria col parametro -l:
gcc -lxml2 main.c
se la libreria non si trova nel path standard devi indicare il percorso in cui si trova col parametro -L:
gcc -L/path/libxml2 -lxml2 main.c

Soprattutto quando si tratta di "roba GNOME" e' il caso di evitare parametri espliciti e farsi aiutare da pkg-config, tanto piu' che sotto Ubuntu funziona con quasi tutto:

gcc `pkg-config --cflags libxml-2.0` -c main.c -o main.o
gcc `pkg-config --libs libxml-2.0` main.o -o main

(ovviamente va bene anche tutto su una unica riga).
Con certe librerie le flag da impostare possono essere numerose:

# pkg-config --cflags libxml++-2.0
-I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
# pkg-config --libs libxml++-2.0
-lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0

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.

[71104]

per quanto riguarda il discorso c, io penso sia piu adatto per un kernel. e poi vorrei vedere le persone che in questo momento stanno smerdando torvalds a scrivere un kernel, visto quanto sono bravi. perché, Torvalds invece ne ha mai scritto uno??? :rotfl:
per la cronaca, ci hanno pure provato una volta a portare Linux in C++; non mi sono mai domandato perché abbiano desistito, adesso invece me lo sto domandando (massa di incompetenti? probabile, visto che la storia ci ha dimostrato la possibilità di scrivere un kernel in C++); domani farò una ricerca.

[cdimauro]

per quanto riguarda il discorso c, io penso sia piu adatto per un kernel.
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++.
e poi vorrei vedere le persone che in questo momento stanno smerdando torvalds a scrivere un kernel, visto quanto sono bravi.
Se ti fossi preso la briga di leggere il thread di cui ho postato il link in precedenza, ti saresti accorto di due cose.

La prima è che si tratta di una domanda piuttosto banale dietro cui si rifugia chi non è in grado di argomentare altrimenti.

La seconda è che... ci troveresti la risposta.
il fatto è che tutta la merda che si tira dietro non è infondata alle volte,come ha detto cdimauro nell'altro thread,ha avuto al fortuna di avere dietro a se persone con le OO,guarda come ha fatto fuori Con kolivas dopo tutto il lavoro che ha fatto per Linux,o meglio sarebbe da dire come non lo ha mai ufficialmente considerato
*
Hai appena detto che i programmatori linux usando C sono scarsi. :tapiro:
Hai appena dimostrato che la logica non è dominio di tutti. :O
Il linguaggio è soltanto uno strumento che ti può facilitare o meno la vita
Ed è uno strumento MOLTO importante, che a volte può anche fare la differenza.

Ecco perché la sua scelta non è affatto banale.
ciò che conta sono le capacità di design che si acquistano con l'esperienza. Le discussioni precedenti non sono LA bibbia
le opinioni si possono condividere o meno e discuterne altre 20/50/1000 volte può aiutare a sviluppare un senso
critico purchè si apportino pareri senza ostentarli per LA VERITA' :D
Di come stiano le cose sull'argomento linguaggio di programmazione C vs C++ ne abbiamo già AMPIAMENTE parlato nel thread in questione (e anche in precedenza).

Quanto alle capacità di design di cui parli, non si acquistano soltanto con l'esperienza: spesso si tratta di una dote innata.
Vedi le alterne vicende dell'audio sotto Linux, ad esempio, che sono un ottimo esempio di come tali "doti" si sprechino...
Generalizzare fa male :) di programmatori ce ne sono di bravi e meno bravi sia su piattaforma gnu/linux che windows .
Anche intestardirsi sull'uso di linguaggi poco produttivi e maggiormente proni a errori come il C fa piuttosto male.

Per il resto, è vero: programmatori più o meno bravi si trovano su entrambe le piattaforme.
pygtk se non ho capito male si basa su phyton? Sinceramente non è che mi ispiri molto, a questo punto preferisco rimanere sul C/C++.
Python è un ottimo linguaggio: provalo.

Ad esempio alcuni manager di pacchetti sono scritti in Python, come pure alcuni installer (di distro).

Parlando d'altro, YouTube è realizzato quasi interamente in Python, e in Google viene spesso usato (uno dei loro più recenti progetti, Google App Engine, è scritto in Python e almeno supporta soltanto Python come linguaggio di sviluppo).
pygtk sono per python,ovviamente se non ti piace il linguaggio c'è poco da fare,io la vedo come una semplificazione notevole piuttosto che sviluppare in C,però si sa degustibus! ;)
Concordo in toto. :)
perché, Torvalds invece ne ha mai scritto uno??? :rotfl:
per la cronaca, ci hanno pure provato una volta a portare Linux in C++; non mi sono mai domandato perché abbiano desistito, adesso invece me lo sto domandando (massa di incompetenti? probabile, visto che la storia ci ha dimostrato la possibilità di scrivere un kernel in C++); domani farò una ricerca.
Ne avevamo parlato anche qui un po' di anni fa, e i motivi erano due: l'immaturità del g++ disponibile all'epoca, e l'incapacità di Torvalds di comprendere il C++ e usarlo, quindi, in maniera appropriata.

[-Slash]

Grazie per le risposte.

apt-file funziona, non male, grazie.
Ho aggiunto le librerie libgnome-dev e libgsf-gnome-1-dev, inutilmente perchè gli header mancanti erano anche in librerie che avevo già. Quelle incluse in Anjuta sono già installate.

Magari domani provo Eclipse che mi sembra un attimino più famigliare al VS.
pygtk se non ho capito male si basa su phyton? Sinceramente non è che mi ispiri molto, a questo punto preferisco rimanere sul C/C++.
I Build-Essential da quello che ho visto servono solo in determinati casi.
Mi sa che i miei problemi sono dovuti ad anjuta più che a librerie mancanti, provo eclipse e vedo come va, visto che KDevelop non posso usarlo perchè sono su GNOME.
build-essential contiene gcc e g++, ossia i compilatori, quindi serve sempre :D
perché, Torvalds invece ne ha mai scritto uno??? :rotfl:
per la cronaca, ci hanno pure provato una volta a portare Linux in C++; non mi sono mai domandato perché abbiano desistito, adesso invece me lo sto domandando (massa di incompetenti? probabile, visto che la storia ci ha dimostrato la possibilità di scrivere un kernel in C++); domani farò una ricerca.
Lo ha iniziato lui ed ancora oggi è sviluppatore attivo. Poi mi sembra abbastanza chiaro che un progetto di quelle dimensioni non lo puoi gestire da solo a meno che non sei superman. Avrà sicuramente incontrato programmatori piu bravi di lui che lo hanno aiutato, ma cio non toglie che un kernel di successo come linux non si crea solo con il culo.
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++.

Era ovvio che mi riferivo alla programmazione ad oggetti del c++. Volendo posso anche scrivere un programma di 5000 milioni di righe di codice in c, e poi lo compilo come cpp, come si fa in tutte le università all'inizio negli esami di fondamenti. Ma quello alla fine è sempre c :rolleyes:

[arara]

A parte le sparate di Torvalds, siete veramente sicuri che non ci sia veramente un valido motivo per cui viene ancora usato il C?
In fondo torvalds non è che abbia scritto tutto sto gran codice, interi sottosistemi di Linux sono scritti/gestiti/mantenuti da altre aziende o programamtori. Difficile credere che siano tutti coglioni, visto che in ballo ci sono aziende come IBM, Intel, HP o Sun.
Ad esempio SELinux è stato scritto dalla NSA, lo stack wireless da un'azienda specializzata che lavora nel settore, Xen da XenSource, lo stack TCP/IP da Alan Cox (credo), etc

Un motivo potrebbe essere questo: Linux gira su decine di piatatforme e architetture diverse, dai dispositivi embemmed ai supercomputer alle grid di Playstation3. Forse viene ancora usato il C perche è il "minimo comun denominatore" tra tutte le varie e disparate architetture su cui Linux gira. Usando il C++ magari non potrebbero usarlo su tutte. Soprattutto considerando che un compilatore C++ è molto piu complesso di un compilatore C, non è detto che possa essere implementato su tutte le piattaforme. Linux ad esempio viene usato anche in sistemi micro embemmed, dove magari è disponibile solo il compilatore C.

E solo un'ipotesi, comunque qua c'è l'elenco delle architetture su cui è stato portato Linux che rende l'idea:

* Alpha architecture:
o DEC Alpha
o Samsung Alpha CPU
* Analog Devices
o Blackfin (since 2.6.22)
* Argonaut RISC Core (ARC) from ARC International
* ARM architecture:
o Acorn Archimedes and Risc PC series
o DEC StrongARM
o Marvell (formerly Intel) XScale
o Sharp Zaurus
o iPAQ
o Palm, Inc.'s Tungsten Handheld[1]
o Gamepark Holdings' GP2X
o Nokia 770 Internet Tablet
o Nokia N800
o Nokia N810
o gumstix
o Nintendo DS via DSlinux
o Sony Mylo
o Psion 5, 5MX, Series 7, netBook
o Some Models of Apple iPods (see iPodLinux)
o OpenMoko Neo1973
o Freescale's (formerly Motorola) i.MX multimedia processors
* Atmel AVR32
* Axis Communications' ETRAX CRIS
* Freescale 68k architecture (68020, 68030, 68040, 68060):
o Some Amigas: A1200, A2500, A3000, A4000
o Apple Macintosh II, LC, Quadra, Centris and early Performa series
o Sun Microsystems 3-series workstations (experimental, uses Sun-3 MMU)[citation needed]
* Fujitsu FR-V
* Hewlett-Packard's PA-RISC family
* H8 architecture from Renesas Technology, formerly Hitachi.
o H8/300
o H8/500
* IBM
o System/390 (31-bit)
o zSeries and System z9 mainframes (64-bit)
* Intel IA-64 Itanium, Itanium II
* x86 architecture:
o IBM PC compatibles using IA-32 and x86-64 processors:
+ Intel 80386, 80486, and their AMD, Cyrix, Texas Instruments and IBM variants
+ The entire Pentium series and its Celeron and Xeon variants
+ The Intel Core processors
+ AMD 5x86, K5, K6, Athlon (all 32-bit versions), Duron, Sempron
+ x86-64: 64-bit processor architecture, now officially known as AMD64 (AMD) or Intel64 (Intel); supported by the Athlon 64, Opteron and Intel Core 2 processors, among others
+ Cyrix 5x86, 6x86 (M1), 6x86MX and MediaGX (National/AMD Geode) series
+ VIA Technologies Eden (Samuel II), VIA C3, and VIA C7 processors
o Microsoft's Xbox (Pentium III processor), through the Xbox Linux project
o SGI Visual Workstation (Pentium II/III processor(s) with SGI chipset)
o Sun Microsystems Sun386i workstation (80386 and 80486)
o Support for 8086, 8088, 80186, 80188 and 80286 CPUs is under development (the ELKS fork)[2]
* M32R from Mitsubishi
* MIPS architecture:
o Infineon's Amazon & Danube Network Processors
o Jazz
o Cobalt Qube, Cobalt RaQ
o DECstation
o Godson (MIPS-like), Godson II, and Godson IIE from BLX IC Design Ltd (China)
o Some PlayStation 2 models, through the PS2 Linux project
o PlayStation Portable uClinux 2.4.19 port [1]
o Broadcom wireless chipsets
* NEC v850e[citation needed]
* OpenRISC open core processor series:
o Beyond Semiconductor OR1200
o Beyond Semiconductor OR1210
* Power Architecture:
o IBM Servers
* PowerPC architecture:
o IBM's Cell
o Most pre-Intel Apple computers (all PCI-based Power Macintoshes, limited support for the older NuBus Power Macs)
o Clones of the PCI Power Mac marketed by Power Computing, UMAX and Motorola
o Amigas upgraded with a "Power-UP" card (such as the Blizzard or CyberStorm)
o AmigaOne motherboard from Eyetech Group Ltd (UK)
o Samantha from Soft3 (Italy)
o Amy'05 PowerPC motherboard from Troika
o IBM RS/6000, iSeries and pSeries systems
o Pegasos I and II boards from Genesi
o Nintendo GameCube, through Nintendo GameCube Linux
o Project BlackDog from Realm Systems, Inc.
o Sony Playstation 3
o V-Dragon CPU from Culturecom.
o Virtex II Pro Field Programmable Array (FPGA) from Xilinx with PowerPC cores.
* SPARC
o SPARC (32-bit):
+ Sun-4/SPARCstation/SPARCserver series
o SPARC (64-bit):
+ Sun Ultra series
+ Sun Blade
+ Sun Fire
+ SPARC Enterprise systems based on the UltraSPARC T1 and UltraSPARC T2 processors
+ Clones made by the Tatung Company and others[citation needed]
* SuperH
o Sega Dreamcast (SuperH SH4)
o HP Jornada 680 through Jlime distribution (SuperH SH3)

[jappilas]

perché, Torvalds invece ne ha mai scritto uno??? :rotfl:
per la cronaca, ci hanno pure provato una volta a portare Linux in C++; non mi sono mai domandato perché abbiano desistito, adesso invece me lo sto domandando (massa di incompetenti? probabile, visto che la storia ci ha dimostrato la possibilità di scrivere un kernel in C++); domani farò una ricerca.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 (http://yousefourabi.com/bsd/cpp-in-the-freebsd-kernel), 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 (http://wiki.freebsd.org/K) )

:p

[cdimauro]

Era ovvio che mi riferivo alla programmazione ad oggetti del c++. Volendo posso anche scrivere un programma di 5000 milioni di righe di codice in c, e poi lo compilo come cpp, come si fa in tutte le università all'inizio negli esami di fondamenti. Ma quello alla fine è sempre c :rolleyes:
E' ovvio che nemmeno tu conosci il C++, visto che C++ != programmazione a oggetti.
A parte le sparate di Torvalds, siete veramente sicuri che non ci sia veramente un valido motivo per cui viene ancora usato il C?
In fondo torvalds non è che abbia scritto tutto sto gran codice, interi sottosistemi di Linux sono scritti/gestiti/mantenuti da altre aziende o programamtori. Difficile credere che siano tutti coglioni, visto che in ballo ci sono aziende come IBM, Intel, HP o Sun.
Ad esempio SELinux è stato scritto dalla NSA, lo stack wireless da un'azienda specializzata che lavora nel settore, Xen da XenSource, lo stack TCP/IP da Alan Cox (credo), etc
Quelle aziende ci sono e investono semplicemente perché ne hanno un tornaconto.
Un motivo potrebbe essere questo: Linux gira su decine di piatatforme e architetture diverse, dai dispositivi embemmed ai supercomputer alle grid di Playstation3. Forse viene ancora usato il C perche è il "minimo comun denominatore" tra tutte le varie e disparate architetture su cui Linux gira. Usando il C++ magari non potrebbero usarlo su tutte. Soprattutto considerando che un compilatore C++ è molto piu complesso di un compilatore C, non è detto che possa essere implementato su tutte le piattaforme. Linux ad esempio viene usato anche in sistemi micro embemmed, dove magari è disponibile solo il compilatore C.
Linux fa uso di GCC come compilatore, e dov'è disponibile il GCC in genere è disponibile anche g++, che è sicuramente più complesso come compilatore, ma niente di eccezionale.

[k0nt3]

trovo abbastanza inutile discutere sulle scelte di Torvalds, alla fine conta il risultato

[cdimauro]

Trovo abbastanza inutile studiare: alla fine conta il risultato. :rolleyes:

Torvalds non ha bisogno di avvocati, semplicemente perché è indifendibile.

L'unica cosa che dovrebbe fare per non attirarsi delle ovvie critiche è... tapparsi la bocca su cose di cui dimostra di non avere nemmeno conoscenze di base.

Anzi, farebbe bene ad affinare le sue "doti" di design: http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html

[71104]

Lo ha iniziato lui ed ancora oggi è sviluppatore attivo. dannazione quanto rosico che non riesco a ritrovare quel messaggio dove lui descriveva il suo lavoro odierno... :muro:
mi credi sulla parola se ti dico che non è più sviluppatore attivo? :cry:

Avrà sicuramente incontrato programmatori piu bravi di lui che lo hanno aiutato, non ci vuole molto :rolleyes:

Poi mi sembra abbastanza chiaro che un progetto di quelle dimensioni non lo puoi gestire da solo a meno che non sei superman. Avrà sicuramente incontrato programmatori piu bravi di lui che lo hanno aiutato, ma cio non toglie che un kernel di successo come linux non si crea solo con il culo. di tutte le panzane (in termini di codice) che Linus aveva scritto in quel kernel non c'è rimasto più ufficialmente nulla; se usassi Linux aggiungerei "per fortuna" :rolleyes:

[Tommo]

Anzi, farebbe bene ad affinare le sue "doti" di design: http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html

Veramente uno schifo ma... torvalds non è mai citato :D

[khelidan1980]

dannazione quanto rosico che non riesco a ritrovare quel messaggio dove lui descriveva il suo lavoro odierno... :muro:
mi credi sulla parola se ti dico che non è più sviluppatore attivo? :cry:



Si questa ormai è cosa nota,comunque se cerchi in giro si trovano facilmente le percentuali di contributi dei vari dev

Tipo qui,si riferisce al kernel 2.6.20:

http://lwn.net/Articles/222773/

[cdimauro]

Veramente uno schifo ma... torvalds non è mai citato :D
Appunto. Invece di sparare cazzate su C & C++ avrebbe fatto meglio a occuparsi della situazione dell'audio di Linux.

[AnonimoVeneziano]

State mandando a ramengo un thread coi soliti discorsi che alla fine si arenano e dove tutti rimangono con le loro idee ...

[marco.r]

Anzi, farebbe bene ad affinare le sue "doti" di design: http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html
Beh... criticare ALSA e' come sparare sulla croce rossa :asd:, non capisco perche' andare a complicarsi cosi' la vita... sotto FreeBSD sono anni che il mixing software in OSS viene fatto automaticamente, basta che due programmi aprano contemporaneamente il device della scheda... forse troppo facile ? :confused:

[k0nt3]

Anzi, farebbe bene ad affinare le sue "doti" di design: http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html
non ho mai visto tanta ignoranza in un singolo blog :O
affermare che quel minestrone di OSS è meglio di ALSA è veramente difficile. è anche ovvio che ALSA è nato per essere un backend e non un frontend, quindi non ha senso che sia portabile su altre piattaforme. directx lo è? se vuoi scrivere applicazioni che usano l'audio su linux usi gstreamer o phonon per dirne un paio e magicamente vedrai che il tuo codice diventa portabile (addirittura più di OSS visto che funzionano pure su windows e OSX :rolleyes: )

[marco.r]

In che senso OSS e' un minestrone ? Visti i grattacapi che causa piu' probabile lo sia ALSA. Ogni volta che trovo HW audio nuovo c'e' qualcosa da sistemare... che sia il mixer che non va piuttosto che il volume che funziona solo sull'interfaccia OSS perche' su quella ALSA si azzera automaticamente. Certo usando distribuzioni come Ubuntu il piu' dei problemi si risolvono, ma solo perche' c'e' qualcuno che ci mette una pezza sopra.

[71104]

Si questa ormai è cosa nota,comunque se cerchi in giro si trovano facilmente le percentuali di contributi dei vari dev

Tipo qui,si riferisce al kernel 2.6.20:

http://lwn.net/Articles/222773/
ah però, non pensavo che Linus fosse così bravo a rimuovere il suo codice... :rotfl:
si vede che in fondo ha una coscienza :rolleyes:
:D

[AnonimoVeneziano]

linux rulez

[k0nt3]

In che senso OSS e' un minestrone ?

non c'è un'api unificata per la gestione in hardware del midi, del mixer e del full duplex, inoltre non è pensata per il multithreading. il che si traduce in minestrone di driver dove ognuno implementa le cose alla sua maniera.
Visti i grattacapi che causa piu' probabile lo sia ALSA. Ogni volta che trovo HW audio nuovo c'e' qualcosa da sistemare... che sia il mixer che non va piuttosto che il volume che funziona solo sull'interfaccia OSS perche' su quella ALSA si azzera automaticamente. Certo usando distribuzioni come Ubuntu il piu' dei problemi si risolvono, ma solo perche' c'e' qualcuno che ci mette una pezza sopra.
in realtà l'ultima volta che ho avuto problemi con l'audio su linux è stato quando c'era ancora il kernel 2.4 e quindi OSS (midi non funzionante, suoni che non potevano sovrapporsi, ritardati ecc...)
se la tua scheda audio ha problemi con alsa puoi usare l'emulazione OSS, ma è solo una pezza, non significa che la soluzione sia OSS in generale

[cdimauro]

x kont3

L'emulazione OSS da parte di ALSA non poche volte crea problemi.

Come anche ALSA di suo ne genera, come t'ha riportato Marco e... sarà stato un caso che anch'io, quando usavo Linux, ho avuto problemi simili (scheda audio perfettamente configurata, ma... muta, pur essendo il volume a posto; alla fine sono riuscito ad abilitare l'audio settando un parametro così scognito che nemmeno ricordo come diavolo si chiama).

Quanto al link che ho postato, rispecchia il casino che c'era e continua a esserci per quanto riguarda l'audio.

[k0nt3]

x kont3

L'emulazione OSS da parte di ALSA non poche volte crea problemi.
per fortuna non ne ho mai avuto bisogno :D

Come anche ALSA di suo ne genera, come t'ha riportato Marco e... sarà stato un caso che anch'io, quando usavo Linux, ho avuto problemi simili (scheda audio perfettamente configurata, ma... muta, pur essendo il volume a posto; alla fine sono riuscito ad abilitare l'audio settando un parametro così scognito che nemmeno ricordo come diavolo si chiama).
quindi non è un problema di alsa, ma di configurazione

Quanto al link che ho postato, rispecchia il casino che c'era e continua a esserci per quanto riguarda l'audio.
il casino c'era al tempo di OSS semmai.
ALSA ha creato un'interfaccia unificata ed è usato dalla maggiorparte del mondo senza problemi. inoltre ora che gnome inizia ad essere distribuito insieme a pulseAudio e kde insieme a phonon direi che la situazione audio su linux è ottima.

[marco.r]

per fortuna non ne ho mai avuto bisogno :D

quindi non è un problema di alsa, ma di configurazione

Diciamo che e' un problema di alsa che richiede di essere configurata quando non ce n'e' il motivo (e infatti con altri sistemi operativi non succede). Lo considero un bug di alsa.


il casino c'era al tempo di OSS semmai.

:mbe:
http://manuals.opensound.com/developer/

The Open Sound System API is based on the old and reliable Posix/unix system call model. The following system calls are available:
The open() system call
The close() system call
The read() system call
The write() system call
The ioctl() system call
The select() and poll() system calls
The mmap() system call

Non solo sono quattro chiamate in croce, ma sono chiamate standard di sistema.
Se vai a guardare le api di ALSA, sono molto piu' corpose e complesse:
http://www.alsa-project.org/alsa-doc/alsa-lib/index.html
ALSA probabilmente fa cose non previste dall'interfaccia OSS, ma a questo punto mi viene comunque da chiedermi a che scopo, visto che poi devo metterci sopra una libreria user space. Tanto vale che il lato kernel si occupi solo quello che gli compete, ovvero fornire un'interfaccia comune ad hardware diverso.


ALSA ha creato un'interfaccia unificata ed è usato dalla maggiorparte del mondo senza problemi. inoltre ora che gnome inizia ad essere distribuito insieme a pulseAudio e kde insieme a phonon direi che la situazione audio su linux è ottima.
Parlare di "maggior parte del mondo" quando funziona solo sotto linux lo trovo un po' eccessivo.

[k0nt3]

Diciamo che e' un problema di alsa che richiede di essere configurata quando non ce n'e' il motivo (e infatti con altri sistemi operativi non succede). Lo considero un bug di alsa.

al contrario secondo me è un problema della distribuzione. se la tua scheda è una di queste http://www.alsa-project.org/main/index.php/Matrix:Main la scheda audio funziona senza configurare un bel niente.

:mbe:
http://manuals.opensound.com/developer/

Non solo sono quattro chiamate in croce, ma sono chiamate standard di sistema.
Se vai a guardare le api di ALSA, sono molto piu' corpose e complesse:
http://www.alsa-project.org/alsa-doc/alsa-lib/index.html
ALSA probabilmente fa cose non previste dall'interfaccia OSS, ma a questo punto mi viene comunque da chiedermi a che scopo, visto che poi devo metterci sopra una libreria user space. Tanto vale che il lato kernel si occupi solo quello che gli compete, ovvero fornire un'interfaccia comune ad hardware diverso.

esatto in pratica l'unica regola di OSS è: nessuna regola
ALSA ha unificato il modo in cui le schede audio interagiscono con kernel e non è poco. il prezzo da pagare è un'interfaccia molto più complessa, ma esistono librerie di più alto livello e quindi perchè non usare quelle? :fagiano:

Parlare di "maggior parte del mondo" quando funziona solo sotto linux lo trovo un po' eccessivo.
ovviamente mi riferivo alla maggiorparte del mondo linux, non avevo capito :p

[mindwings]

Quanto alle capacità di design di cui parli, non si acquistano soltanto con l'esperienza: spesso si tratta di una dote innata.


Falso colossale ! Nessuno nasce imparato :fagiano:
Ci può essere una predisposizione , ma senza il lavoro e lo studio
non vai da nessuna parte... Poi se sei Von Neumann è un altro discorso.(anche lui ha lavorato/studiato niente viene gratis)

[Pixel452]

OK, allora, ho già fatto un paio di cazzate.
Ieri sera ho installato Eclipse dal repository(prima cazzata) quindi ho solo la versione 3.2.
Poi ho tentato di seguire una guida per installare CDT, ma, preso dalla fretta, mi sono distratto e ho installato CDT prima di installare MSys e MinGW, cosa da non fare assolutamente secondo la guida(seconda cazzata). Diciamo che adesso Eclipse dovrebbe supportare il C/C++, ma, in effetti non compila, almeno non come dovrebbe secondo la guida. Adesso cosa faccio installo il MinGW(l'altro nel repository non lo trovo) o cosa?
Scusate se sto facendo un casino ma mi sento un pò spaesato non avendo mai usato Linux.

[cdimauro]

al contrario secondo me è un problema della distribuzione. se la tua scheda è una di queste http://www.alsa-project.org/main/index.php/Matrix:Main la scheda audio funziona senza configurare un bel niente.
E certo: è sempre un problema di distribuzione usata... :rolleyes:
esatto in pratica l'unica regola di OSS è: nessuna regola
ALSA ha unificato il modo in cui le schede audio interagiscono con kernel e non è poco. il prezzo da pagare è un'interfaccia molto più complessa, ma esistono librerie di più alto livello e quindi perchè non usare quelle? :fagiano:
Ma che stai a dire? Nessuna regola? Proprio OSS è una libreria che incarna fino all'osso la filosofia Unix di gestione di periferiche & dati, e la sua interfaccia ne è un esempio lampante... :mbe:

Tutto il contrario di ALSA... :rolleyes:

Marco ha ragione su tutta linea.
Falso colossale ! Nessuno nasce imparato :fagiano:
Ci può essere una predisposizione , ma senza il lavoro e lo studio
non vai da nessuna parte... Poi se sei Von Neumann è un altro discorso.(anche lui ha lavorato/studiato niente viene gratis)
Ma infatti, se leggi meglio, ho usato due parole che chiarivano il mio pensiero: "(non) soltanto" e "spesso". :read: :O
OK, allora, ho già fatto un paio di cazzate.
Ieri sera ho installato Eclipse dal repository(prima cazzata) quindi ho solo la versione 3.2.
Poi ho tentato di seguire una guida per installare CDT, ma, preso dalla fretta, mi sono distratto e ho installato CDT prima di installare MSys e MinGW, cosa da non fare assolutamente secondo la guida(seconda cazzata). Diciamo che adesso Eclipse dovrebbe supportare il C/C++, ma, in effetti non compila, almeno non come dovrebbe secondo la guida. Adesso cosa faccio installo il MinGW(l'altro nel repository non lo trovo) o cosa?
Scusate se sto facendo un casino ma mi sento un pò spaesato non avendo mai usato Linux.
Prova KDevelop.

[Pixel452]

Ma non dovrei anche in quel caso installare compilatori e roba varia?
In oltre, se è basato su KDE come si integra in GNOME?

[cdimauro]

Generalmente nelle distro sono già installati alcuni compilatori, per cui non dovresti avere problemi.

Quanto a Gnome, segui il consiglio di Torvalds: buttalo e passa a KDE. :asd:

[k0nt3]

E certo: è sempre un problema di distribuzione usata... :rolleyes:

chiaramente se una volta immessi i parametri corretti alsa funziona magicamente è un problema di configurazione. e se è un problema di configurazione chi doveva pensarci se non la distribuzione?

Ma che stai a dire? Nessuna regola? Proprio OSS è una libreria che incarna fino all'osso la filosofia Unix di gestione di periferiche & dati, e la sua interfaccia ne è un esempio lampante... :mbe:

Tutto il contrario di ALSA... :rolleyes:

Marco ha ragione su tutta linea.
quindi sono tutti pazzi? per quale motivo non si è continuato a usare OSS allora? forse perchè non conosci la reale situazione?

[marco.r]

OK, allora, ho già fatto un paio di cazzate.
Ieri sera ho installato Eclipse dal repository(prima cazzata) quindi ho solo la versione 3.2.
Poi ho tentato di seguire una guida per installare CDT, ma, preso dalla fretta, mi sono distratto e ho installato CDT prima di installare MSys e MinGW, cosa da non fare assolutamente secondo la guida(seconda cazzata). Diciamo che adesso Eclipse dovrebbe supportare il C/C++, ma, in effetti non compila, almeno non come dovrebbe secondo la guida. Adesso cosa faccio installo il MinGW(l'altro nel repository non lo trovo) o cosa?
Scusate se sto facendo un casino ma mi sento un pò spaesato non avendo mai usato Linux.

consiglio mio: eclipse scaricatelo dal sito. Non solo lo trovi con CDT gia' pronto ma avrai meno problemi ad installare ed aggiornare i vari plugin.
Dal repository installa compilatori e debugger (gcc, g++,gdb) oltre che il runtime java per far andare eclipse.
Ignora MinGW e MSys. Servono quando lavori sotto windows per darti proprio quello che di solito in Linux trovi senza problemi (fondamentalmente il compilatore e una shell con bash)

[k0nt3]

Ma non dovrei anche in quel caso installare compilatori e roba varia?
In oltre, se è basato su KDE come si integra in GNOME?
secondo me dovresti continuare con anjuta che si integra meglio in gnome

[khelidan1980]

Ma non dovrei anche in quel caso installare compilatori e roba varia?
In oltre, se è basato su KDE come si integra in GNOME?

se hai gia installato build-essential hai tutto cio che ti serve,almeno per compilare,mingw non è roba che ti interessa

[Doriän]

OK, allora, ho già fatto un paio di cazzate.
Ieri sera ho installato Eclipse dal repository(prima cazzata) quindi ho solo la versione 3.2.
Poi ho tentato di seguire una guida per installare CDT, ma, preso dalla fretta, mi sono distratto e ho installato CDT prima di installare MSys e MinGW, cosa da non fare assolutamente secondo la guida(seconda cazzata). Diciamo che adesso Eclipse dovrebbe supportare il C/C++, ma, in effetti non compila, almeno non come dovrebbe secondo la guida. Adesso cosa faccio installo il MinGW(l'altro nel repository non lo trovo) o cosa?
Scusate se sto facendo un casino ma mi sento un pò spaesato non avendo mai usato Linux.


Elimina la versione 3.2, puzza. Scarica eclipse-cpp-europa-winter-linux-gtk dal sito di Eclipse, scompattalo un po' dove ti pare (io vado di /usr/local), fatti un link a /usr/local/eclipse/eclipse ed è gg. O meglio, sarebbe. Devi anche installarti il jdk/jre, perché lavorare con quello che passa Ubuntu out of the box è un dito in culo (in fatto di reattività dell'IDE; per lo meno così leggevo :dunno:). Dunque, qui (http://ubuntuforums.org/showthread.php?t=201378) dan delle dritte, io su ubuntu ricordo di averle seguite e fungeva tutto piuttosto bene. Al limite chiedi, ti si saprà aiutare!

[nico159]

Leggi attentamente tutto il suo messaggio. C'è da piangere...
Certo...peccato che ti sei dimenticato di contestualizzare il messaggio di Linus, ma tanto che vuoi che cambi :°D

perché, Torvalds invece ne ha mai scritto uno???
Sì, si chiama Linux, non lo conosci? :)

Beh... criticare ALSA e' come sparare sulla croce rossa , non capisco perche' andare a complicarsi cosi' la vita... sotto FreeBSD sono anni che il mixing software in OSS viene fatto automaticamente, basta che due programmi aprano contemporaneamente il device della scheda... forse troppo facile ?
O magari perchè usare PulseAudio è la scelta migliore?
Sbaglio...ma anche un tale Vista ha un certo "userspace sound system"?...adesso che mi ricordo anche Mac OS X...:)

[cdimauro]

chiaramente se una volta immessi i parametri corretti alsa funziona magicamente è un problema di configurazione. e se è un problema di configurazione chi doveva pensarci se non la distribuzione?
Una volta immessi i parametri? Ma di quali parametri parli? Era da parecchio tempo che non mi funzionava l'audio, pur avendo cercato fra mari e monti con HOW-TO, forum, blog. Una volta apro alsamixer, e per sbaglio premo un tasto che mi cambia un parametro il cui nome non mi dice assolutamente NULLA; esco da alsamixer e dopo un po', a causa di un'azione, sento un suono: l'audio funzionava!

Se questo lo chiami "configurare"... :rolleyes:
quindi sono tutti pazzi? per quale motivo non si è continuato a usare OSS allora? forse perchè non conosci la reale situazione?
Sì, la conosco e ci sono passato anche sulla mia pelle.

Concordo con le osservazioni fatte nel link che ho postato prima: per risolvere un problema molto semplice (poi risolto anche con OSS) hanno preferito scrivere una nuova libreria, complessa, incompatibile con tutto ciò che era stato fatto prima, e che funziona soltanto su Linux (mentre OSS gira anche su altri s.o. Unix-like).
Certo...peccato che ti sei dimenticato di contestualizzare il messaggio di Linus, ma tanto che vuoi che cambi :°D
Peccato che ti sei dimenticato di leggere il thread in questione, visto che l'argomento è stato sviscerato AMPIAMENTE, ivi compresa la contestualizzazione del suddetto messaggio.

Troppa fatica leggere prima di flammare? :rolleyes:
Sì, si chiama Linux, non lo conosci? :)
Non è stato solo, ed è partito da Minix...
O magari perchè usare PulseAudio è la scelta migliore?
Sbaglio...ma anche un tale Vista ha un certo "userspace sound system"?...adesso che mi ricordo anche Mac OS X...:)
PulseAudio? Mi fai l'elenco di tutte librerie per la gestione dell'audio che sono state sviluppate per Linux? :asd:

[khelidan1980]

Elimina la versione 3.2, puzza. Scarica eclipse-cpp-europa-winter-linux-gtk dal sito di Eclipse, scompattalo un po' dove ti pare (io vado di /usr/local), fatti un link a /usr/local/eclipse/eclipse ed è gg. O meglio, sarebbe. Devi anche installarti il jdk/jre, perché lavorare con quello che passa Ubuntu out of the box è un dito in culo (in fatto di reattività dell'IDE; per lo meno così leggevo :dunno:). Dunque, qui (http://ubuntuforums.org/showthread.php?t=201378) dan delle dritte, io su ubuntu ricordo di averle seguite e fungeva tutto piuttosto bene. Al limite chiedi, ti si saprà aiutare!

Più che altro Ubuntu viene rilasciata con openjdk di default,e non ho ancora ben capito quali componenti manchino o vengono sostituiti rispetto alla release Sun binaria

[tomminno]

Ma non dovrei anche in quel caso installare compilatori e roba varia?
In oltre, se è basato su KDE come si integra in GNOME?

Usa Code::Blocks

[k0nt3]

Una volta immessi i parametri? Ma di quali parametri parli? Era da parecchio tempo che non mi funzionava l'audio, pur avendo cercato fra mari e monti con HOW-TO, forum, blog. Una volta apro alsamixer, e per sbaglio premo un tasto che mi cambia un parametro il cui nome non mi dice assolutamente NULLA; esco da alsamixer e dopo un po', a causa di un'azione, sento un suono: l'audio funzionava!

Se questo lo chiami "configurare"... :rolleyes:
tu lo chiami bere? :Prrr:

Sì, la conosco e ci sono passato anche sulla mia pelle.

Concordo con le osservazioni fatte nel link che ho postato prima: per risolvere un problema molto semplice (poi risolto anche con OSS) hanno preferito scrivere una nuova libreria, complessa, incompatibile con tutto ciò che era stato fatto prima, e che funziona soltanto su Linux (mentre OSS gira anche su altri s.o. Unix-like).
1- non è incompatibile con un bel niente dato che tutto ciò che era stato fatto prima funziona con l'emulazione OSS
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

PulseAudio? Mi fai l'elenco di tutte librerie per la gestione dell'audio che sono state sviluppate per Linux? :asd:
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.

[k0nt3]

Usa Code::Blocks
avevo consigliato di tenere anjuta, ma adesso che ci penso voto anche io per Code::Blocks :D

[nico159]

Troppa fatica leggere prima di flammare? :rolleyes:
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? :asd:
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]

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 :rolleyes:

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]

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]

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

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


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]

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:D

[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. :)


Parliamo di C e C++
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! :)


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.


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:

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!


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.


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/Callback_%28computer_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/).



Sull'implementazione del kernel in C++
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 (http://yousefourabi.com/bsd/cpp-in-the-freebsd-kernel), 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 (http://wiki.freebsd.org/K) )

:p

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.


Parlando di IDE

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]

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!
La pluralità è un bene mai un male :)
se un sistema è decisamente più potente verrà adottato
dalla maggioranza delle distro... Su questo non ci piove:D
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... :p
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. :)


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! :)


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.

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

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!

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/Callback_%28computer_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. :D

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

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

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]

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 :fagiano: altro che eclipse..), ma non è affatto male. la versione 4 (attualmente alpha) promette molto bene

[khelidan1980]

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



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!


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]

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. :D (C) 2007-2008 by fek
hai provato kdevelop? non è certo al livello di visual studio (però il 2005 è un macigno :fagiano: altro che eclipse..), ma non è affatto male. la versione 4 (attualmente alpha) promette molto bene
Quando sarà in versione finale ne riparleremo.
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]

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]

hai provato kdevelop? non è certo al livello di visual studio (però il 2005 è un macigno :fagiano: 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]

OK! Credo di aver scritto più di quanto credevo di scrivere...
mi sa che verrò bannato immediatamente per verbosità... :(ma figurati :D
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 :eek: :sofico:

[mindwings]

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

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

deformazione professionale , adora python :rotfl: -> :D

[dacav]

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


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.


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.


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


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.


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


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! :D


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.


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


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

:banned: :banned: :banned: :banned: :banned: :banned:

[dacav]

deformazione professionale , adora python :rotfl: -> :D

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

[marco.r]

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 :mbe:



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/Callback_%28computer_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... :D

[dacav]

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 :cool:. 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 (http://www.gnu.org/software/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]

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]

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

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 (http://www.gnu.org/software/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]

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? :mbe:
straccia il manuale dove hai letto questa amenità.

[71104]

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]

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 :rolleyes:
Neanche in C# funziona, figuriamoci in C++.

[marco.r]

in C++ i riferimenti puntano sempre ad oggetti? :mbe:
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]

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 :rolleyes: eh lo so, lo so, come al solito sono l'unico fortunello :rolleyes: da oggi persino quando gli altri difendono Windows :asd:


Neanche in C# funziona, figuriamoci in C++. in C# non l'ho mai provato.

[DanieleC88]

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).
Qualunque utente VI esperto lo difenderebbe fino alla morte... :sofico:
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^]

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? :fagiano:

[tomminno]

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

[DanieleC88]

tipo? :fagiano:
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.
Come al solito gli IDE rimangono fuori.
Il debug tramite gdb è di una comodità impressionante. :muro:
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. :D

[cdimauro]

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. :D
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. :p
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... :rolleyes:
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. :p
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! :D
Per forza: se lo stesso autore del coding style poi non lo rispetta, non mi aspetto certo che lo facciano gli altri... :asd:

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. :asd: 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 :asd: ). ;)
Qualunque utente VI esperto lo difenderebbe fino alla morte... :sofico:
Chessò: i miei colleghi linuxiani? :p

Per il resto concordo col buon Marco. :)
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... :D
Come non quotare: mai idea più orribile fu concepita da mente umana (dopo Perl :asd:).
In linea di massima do del mio ottenere esattamente questo: codice che funziona al primo botto :cool:. 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 (http://www.gnu.org/software/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... :O

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... :doh:
è 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... :rolleyes:
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?
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? :p
Per quanto riguarda il debugging di STL containers in GDB: http://staff.science.uva.nl/~gilad/stl/stl_gdb.html
Welcome to:

http://www.ociol.com/figcartoni/giatrus.jpg

[tomminno]

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]

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]

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^]

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 ;)

[cdimauro]

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.
Anche mia figlia capisce che quando entra nella stanza ed accende la luce, prima di uscire la deve chiudere.

Mia figlia non ha la benché minima conoscenza dei metodi "dispose" perché non sa programmare, ma ha già ben presente il concetto di accesso e rilascio di una risorsa. ;)
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à.
Fin da quando ha presentato il C++, Stroustrup ha SEMPRE specificato che le vecchie caratteristiche del C non dovevano assolutamente essere penalizzate. Quindi soltanto quelle nuove, giustamente, possono portare EVENTUALMENTE a un decadimento delle prestazioni.

Questo, se non ricordo male, l'ha anche riportato nel libro che ha scritto sul linguaggio.

L'uso di strutture SENZA utilizzare alcuna caratteristica peculiare del C++ NON deve generare alcun codice addizionale / penalizzante. Se si verifica, è il compilatore che è scritto male.

Ad esempio, prendiamo questo codice:
struct sPunto
{
int x, y;
};

class cPunto
{
public:
int x, y;
};

struct sPunto s;
s.x = 320;
s.y = 256;

cPunto c;
c.x = 320;
c.y = 256;
Non c'è nessun costruttore da chiamare: si tratta di strutture statiche, senza metodi virtuali né codice di inizializzazione, per cui il compilatore deve accorgersene e non generare nessun codice a parte l'assegnazione.
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.
Esatto. In Python:
with open('myfile') as f:
for ch in f.read()
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.
Esattamente. Questo perché, appunto, non c'è nessuna differenza fra struct e classi, tranne per la visibilità di default, che nelle prime è pubblica, e nella seconda privata.

Quindi in teoria potresti benissimo usare sempre e soltanto le struct per dichiarare classi e programmare a oggetti. Stroustrup introdusse la keyword class per marcare la differenza col "passato"; inizialmente il suo obiettivo era di aggiungere il minimo indispensabile al linguaggio C per supportare nuove funzionalità, e quindi sfruttò la keyword struct per introdurre l'uso delle classi, e ciò rimase nel linguaggio.
IMHO avrebbe fatto meglio a lasciare le struct come sono in C, e permettere di usare le innovazioni delle classi con la keyword class.

[tomminno]

Anche mia figlia capisce che quando entra nella stanza ed accende la luce, prima di uscire la deve chiudere.

Mia figlia non ha la benché minima conoscenza dei metodi "dispose" perché non sa programmare, ma ha già ben presente il concetto di accesso e rilascio di una risorsa. ;)


Già ma se fosse abituata a lasciarla accesa perchè tanto la spengono i genitori...


Fin da quando ha presentato il C++, Stroustrup ha SEMPRE specificato che le vecchie caratteristiche del C non dovevano assolutamente essere penalizzate. Quindi soltanto quelle nuove, giustamente, possono portare EVENTUALMENTE a un decadimento delle prestazioni.

Questo, se non ricordo male, l'ha anche riportato nel libro che ha scritto sul linguaggio.


Prova questa struct in C

struct Prova
{
int p;
Prova() { cout << "costruttore Prova" << endl; }
~Prova() { cout << "distruttore Prova" << endl; }
Prova * Get() { return this; }
};


Volendo puoi omettere costruttore e distruttore tanto ci pensa il C++ a metterli per te.
Ah e prova a mettere int p = 0; nella struct e leggi il bellissimo messaggio di errore che viene fuori:

error C2864: 'Prova::p' : only static const integral data members can be initialized within a class


saranno anche uguali a quelle del C ma a me non sembra proprio.


Esatto. In Python:
with open('myfile') as f:
for ch in f.read()


Peccato che ad esempio in C# se non chiudi esplicitamente un file o utlizzi il costrutto using (che è la stessa cosa solo più sicura a causa delle eccezioni che escono come funghi dal .NET), il file rimane aperto fino a che il GC non decide di terminare l'oggetto.
E se ti arriva una eccezione il file rimane aperto.


string towrite = null;
StreamWriter sw = new StreamWriter("myfile.txt",true);
sw.Write(towrite);

[marco.r]

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.

Nessuna, o meglio una sola, le struct di default hanno membri public mentre le classi hanno membri privati, tanto che qualcuno usa costantemente solo struct. Un effetto del voler introdurre una keyword piu' comprensibile e di dover rimanere compatibili col C.

[k0nt3]

Nessuna, o meglio una sola, le struct di default hanno membri public mentre le classi hanno membri privati, tanto che qualcuno usa costantemente solo struct. Un effetto del voler introdurre una keyword piu' comprensibile e di dover rimanere compatibili col C.
leggasi: massimizzare il numero di porcherie possibili :asd:

[71104]

leggasi: massimizzare il numero di porcherie possibili :asd: per me il fatto che classi e struct siano quasi la stessa cosa non è una porcheria, è una confusione; se vuoi vedere una vera porcheria allora parliamo della keyword friend :Puke:

[DanieleC88]

se vuoi vedere una vera porcheria allora parliamo della keyword friend :Puke:
Perché, povera lei? :D

[marco.r]

Prova questa struct in C

struct Prova
{
int p;
Prova() { cout << "costruttore Prova" << endl; }
~Prova() { cout << "distruttore Prova" << endl; }
Prova * Get() { return this; }
};


Non ho capito l'esempio :mbe:, il bisogno di mantenere la struct era nato dalla volonta' di far si' che il codice C fosse il piu' possibile leggibile come codice C++, non il contrario.


Volendo puoi omettere costruttore e distruttore tanto ci pensa il C++ a metterli per te.

Ed in effetti se uso una struct "alla C" (ovvero contenente solo tipi primitivi o strutture) fa la stessa cosa che fa in C, ovvero niente.


saranno anche uguali a quelle del C ma a me non sembra proprio.

Non sono uguali, sono un superset di quelle del C



Peccato che ad esempio in C# se non chiudi esplicitamente un file o utlizzi il costrutto using (che è la stessa cosa solo più sicura a causa delle eccezioni che escono come funghi dal .NET), il file rimane aperto fino a che il GC non decide di terminare l'oggetto.
E se ti arriva una eccezione il file rimane aperto.

Ma questo e' un problema di design delle librerie, non del GC. La gestione delle risorse la fai con costruttori e distruttori di oggetti se questi hanno una vita predicibile, altrimenti procedi per altre vie.
Certo che se si parte dall'idea che deve sembrare il piu' possibile al C++ oppure che non si puo' implementare perche' altrimenti il linguaggio diventa troppo complesso i risultati sono quelli che sono...

[71104]

Perché, povera lei? :D perché se era proprio necessario metterla tanto valeva eliminare tutto il concetto di visibilità e tanti saluti

[DanieleC88]

perché se era proprio necessario metterla tanto valeva eliminare tutto il concetto di visibilità e tanti saluti
E vabbe', almeno puoi definire delle "eccezioni", non credo sia così... perniciosa. :D

[k0nt3]

in realtà il concetto di friend function serve a sopperire alla mancanza del concetto di package.. hanno usato il mezzo sbagliato per risolvere il problema giusto IMHO
il tutto sempre per massimizzare il numero di porcherie ammissibili :asd:

[marco.r]

leggasi: massimizzare il numero di porcherie possibili :asd:
Boh, son solo due keywords praticamente identiche per cui non parlerei di porcheria. Diciamo allo stesso livello di poter omettere "int" quando si parla di short o long. O meno peggio del non sapere se "char" e' uguale a "unsigned char" o "signed char".

[marco.r]

E vabbe', almeno puoi definire delle "eccezioni", non credo sia così... perniciosa. :D
Anche perche' non e' che si usi poi molto. Sicuramente non e' una soluzione "pulita", ma cosa lo e' in C++ ? :D

[cdimauro]

Già ma se fosse abituata a lasciarla accesa perchè tanto la spengono i genitori...
I genitori devono fare soltanto una cosa: educere, che nell'etimologia della parola vuol dire "condurre".

Il resto, visto che ha una testa e le funziona pure bene, deve imparare a farlo da sola.
Prova questa struct in C

struct Prova
{
int p;
Prova() { cout << "costruttore Prova" << endl; }
~Prova() { cout << "distruttore Prova" << endl; }
Prova * Get() { return this; }
};


Volendo puoi omettere costruttore e distruttore tanto ci pensa il C++ a metterli per te.
Ah e prova a mettere int p = 0; nella struct e leggi il bellissimo messaggio di errore che viene fuori:

saranno anche uguali a quelle del C ma a me non sembra proprio.
L'esempio è sbagliato: quello che hai postato non è codice C.

Il codice C e l'esempio giusto è quello che ho postato prima, con la struct prima e la class poi.

Ovviamente in C può andare soltanto la parte relativa alla struct.

A me premeva far notare che l'uso, in C++, di una struct nella STESSA maniera in cui si farebbe in C non comporta NESSUN overhead, e che lo stesso vale per la dichiarazione di una classe che, anche questa, non aggiunge nulla a ciò che farebbe un'equivalente struct in C.

Sul resto concordo con quel che ha scritto Marco.
in realtà il concetto di friend function serve a sopperire alla mancanza del concetto di package.. hanno usato il mezzo sbagliato per risolvere il problema giusto IMHO
Vero. Avrei preferito l'introduzione (finalmente) del concetto di modulo/unit/package.
il tutto sempre per massimizzare il numero di porcherie ammissibili :asd:
Almeno hanno provato a migliorare un linguaggio, il C, che è stato messo in frigorifero e ibernato... :rolleyes: