Newsgroup: it.comp.lang.c++
Titolo: Usi professionali del C++

Ciao a tutti,
leggendo i messaggi che compaiono sul newsgroup mi e' sorta la
curiosita' di scoprire per quali scopi e' usato il C++ a livello
professionale in Italia e perche' proprio il C++.
Comincio io: ho usato e sto usando il C++ in due progetti. Il primo era
nell'ambito dei sistemi di supervisione per reti telefoniche; era un
progetto che  ha comportato la realizzazione di circa 100.000 linee di
codice da parte di un team di 8-10 persone. Si e' scelto di lavorare in
C++ (grosso modo la versione descritta nella seconda edizione dello
Stroustrup) anche se nel team l'esperienza specifica era molto limitata,
per sfruttare il maggior supporto all'incapsulamento rispetto al C, con
la consapevolezza che nella peggiore delle ipotesi si sarebbe ricaduti
in "un C migliore". Devo dire che la cosa e' tutto sommato riuscita:
grazie alla disponibilita' di una libreria di contenitori (Tools.h++) si
sono limitati i problemi relativi ai puntatori, le eccezioni non sono
state usate e praticamente nemmeno i template (cioe' usati si, ma non
scritti).
Il secondo progetto e' in ambito finanziario, in un gruppo di 8 - 10
persone. Quando sono arrivato la scelta del linguaggio era gia' stata
effettuata, ma la condividuo perche' l'applicazione e' piuttosto
complicata, e l'espressivita' del C++ risulta efficace nel rappresentare
gli elementi piu' o meno mutevoli che derivano dal continuo variare dei
requisiti o della comprensione del dominio.
Probabilmente una versione 1 realizzata in un linguaggio piu' semplice
avrebbe richiesto meno fatica, ma ora guadagnamo nella manutenzione e
nell'evoluzione del codice.
E tutti voi? Reitero che sono interessato esclusivamente agli scopi
professionali.
Ciao,
Nicola

Ciao,
bella questa domanda perche´ mi ha incuriosito.
Io sono praticamente un novellino del C++ e lo sto imparando man mano che
lavoro.
Lavoro in un team di sviluppo in un reparto Ericsson, ed e´ stato deciso di
implementare in C++ il nostro progetto di analisi video di fibre ottiche
mediante microtelecamere.
Prima ho lavorato esclusivamente in C in una ditta italiana che si occupava
di radar e apparecchiature navali.
Il passaggio al C++ e´ stato deciso in quanto i precedenti progetti avevano
raggiunto dimensioni mastodontiche con la conseguenza di una faticaccia
improba nella manutenibilita´. Qua il personale va e viene, la
documentazione e´ scarna per cui per capire cosa fa una data funzione devi
solo sperare che l´anima pia che ha sviluppato quel codice, abbia messo
qualche commento per non perderti nel mare dello spaghetti-code in C.
La speranza nel passare al C++ e´ quella di avere un maggior ordine nel
codice, qualche sicurezza in piu´ dovuta all´incapsulazione, codice
preconfezionato nel caso si usino i templates standard con i loro algoritmi
e gli iteratori ecc. ecc.
Il mio dubbio e´ che essendo il C++ non un mare ma un oceano, saremo
costretti ad usarlo per un ben ristretto sottoinsieme di caratteristiche,
per cui non so se il gioco varra´ la candela.
Inoltre, dovendo portare il tutto in ambiente Windows CE, abbiamo gia´ i
primi problemi perche´ il compilatore non e´ C++ standard.
Comunque seguendo questo newsgroup e con molta pazienza spero di procedere
nell´apprendimento "real time", anche grazie ai guru qui presenti.

 [CUT]

in "un C migliore".
Ecco, questa e' una cosa che mi sono sempre chiesto : quant'e' ampia
la preparazione dei programmatori italiani su questo linguaggio ?
Io credo che il C++ sia veramente complesso, al punto che non sono
tante le persone (Alex Martelli, escluso, che secondo me continua a
incorporare il cervello di piu' maestri di C++ in uno ;) a saperne
sfruttare appieno tutte le caratteristiche.
Mi chiedo : cos'e' che spinge ad utilizzare questo linguaggio, in
ambito professionale, quando la complessita' e' tale da ridurlo a un
semplice C migliore ?
--
Andrea Laforgia (
andrea_...@bigfoot.com
)
---------------------------------------------
#exclude <windows.h>

In un team di programmatori non è necessario che tutti mangino
Template a colazione e classi polimorfe a cena... bastano un paio di
persone che preparino per gli altri le basi solide...
Luc.


persone che preparino per gli altri le basi solide...
Il succo della mia domanda non era questo ;)
E comunque il fatto che vi siano solo poche persone in grado di
gestire le caratteristiche avanzate del linguaggio dovrebbe far
riflettere. Io gradirei un gruppo di programmatori in cui tutti
mangiano template e classi polimorfe, ma finora non ne ho ancora
visti. E' una situazione solo italiana ? ... probabile !...


 persone che preparino per gli altri le basi solide...
Secondo la mia esperienza e' un approccio che funziona abbastanza, posto
di accettare il suo principale inconveniente che a mio avviso e' il
fatto che di solito i "bravi" devono dedicare troppo tempo a produrre,
per poter fare sufficiente attenzione a come lavorano i meno esperti; il
risultato tende ad essere un'applicazione da un cuore pulito e ben
organizzato, circondato da codice che va dal mediocre al terribile. Ma
e' gia' qualcosa.
Ciao,
Nicola

 Il giro d'affari è enorme, siamo in 7 come programmatori.
Vien da domandarsi come siano i vostri stipendi :-)
Ciao,
Nicola

Non male, ed in costante aumento (+10% solo da gennaio, esclusi i bei
'premi produzione')... e quando tra breve entreremo in borsa avremo
anche un bel pacchetto di azioni...
8)
Luc.


 semplice C migliore ?
Dal C al C++, in termini di complessita` e ricchezza, c'e` un
rapporto di circa 1 a 10.  Se io del C++ ne uso, che so, 8 su
10, o anche 7 su 10, ho comunque una leverage enorme rispetto
all'uso del C.
Il dubbio che ho io e` il contrario, cioe` perche` qualcuno
resti al vecchio C, come e` stato chiesto anche di recente
su thread in questo gruppo.  Penso che la diffidenza sulla
solidita` dei compilatori, e in particolare sulla bonta` degli
ottimizzatori, ormai solo parzialmente giustificata ma che
solo pochi anni fa era giustificatissima, sia probabilmente
la radice della scelta di non passare, ALMENO, a "un C migliore".
La classe di linguaggi che secondo me darebbe molti vantaggi
nella gran parte degli usi professionali rispetto al C++ non
e` certo quella del C, o quella dell'Assembler.  Al contrario,
sono linguaggi piu` *LONTANI* dalla macchina che offrono le
migliori prospettive, che la distanza in piu` sia modesta
(Java) o sostanziale (Python).  La recente, gradualmente
crescente, espressione di entusiasmo per Python, da parte dei
piu` vari guru di Java/C++/OOP (Bruce Eckel, il noto autore
di "Thinking in C++" e "Thinking in Java"; R. Martin, editor
del "C++ Report", inventore della cruciale pattern "Inversione
di Dipendenza", autore di "Obiect-Oriented programming in C++
using the Booch Method"; e, si licet parva componere magnis, io
pure:-) nasce dalla gradualmente crescente realizzazione di
questo -- una programmazione mista, con Java o C++ ai bassi
livelli e Python al di sopra, puo` offrire una produttivita`
incredibile a costi di presazioni decisamente accettabili (non
e` raro che le prestazioni *migliorino*, perche` il linguaggio
piu` dinamico consente molta piu` sperimentazione a livello
di architetture e algoritmi, sino a trovare soluzioni che nel
complesso dimostrano prestazioni migliori di quelle interamente
sviluppate in linguaggi meno dinamici).
Alex

 professionale in Italia e perche' proprio il C++.
Think3 oggi (in Italia, e fuori) usa praticamente solo il
C++, affiancato da vari linguaggi "di scripting" (c'e`
anche qualcosina in Java, ma non molto).  C'e` dietro una
lunga evoluzione (in gran parte quando eravamo ancora
Cad.Lab), a partire dal Fortran, attraverso il C.
Quando decidemmo che era ora di migrare ad un linguaggio
ad oggetti, non c'erano alternative per noi pienamente
soddisfacenti sull'ampia gamma di piattaforme che allora
supportavamo (Eiffel ci arrivava vicino, ma non sino in
fondo; nessuno degli altri candidati esaminati aveva
la mole di supporto e conoscenza diffusa, le prestazioni,
ecc ecc, per soddisfare le nostre esigenze).  Lo stesso
C++ era piuttosto acerbo, e dapprima lo limitammo a
progetti-pilota, studi di ricerca, ecc ecc, sino a che
finalmente non lo battezzammo maturo per l'uso in fase
di produzione.  Il nostro kernel geometrico 3D, al cuore
dei nostri prodotti, fu il primo grande progetto di
produzione sviluppato interamente in C++ (gia` con ampio
uso dei template: la libreria standard non era ancora
all'orizzonte, ci facemmo i nostri template contenitori
ecc ecc).  Come dico, non c'era veramente alternativa,
volendo lavorare ad oggetti (cosa irrinunciabile) senza
sacrificio di prestazioni, e con un linguaggio ampiamente
diffuso e non proprietario (Eiffel era allora solo
all'alba del processo che poi lo de-proprietarizzo`...).
Quando, assai piu` tardi, emerse Java, lo valutammo a
fondo, naturalmente, ma non fu mai pienamente soddisfacente
ai nostri scopi; abbiamo alcune parti in Java a scopi
particolari, ma resta per noi un linguaggio del tutto
marginale.  Peccato, perche` come produttivita` un suo
vantaggio su C++ lo aveva (soprattutto nel liberare i
programmatori dalla gestione della memoria).  Chissa`
che un giorno non riemerga, se mai Sun sapra` "mollarlo
al mondo" come tante volte ha promesso e mai mantenuto.
Secondo me (e penso di avere su questo parecchi consensi,
sia entro l'azienda sia nel mondo della programmazione
in generale) l'onda emergente e` quella di programmare
per componenti.  Al momento stiamo sviluppando tutti i
nostri componenti in C++, in parte "per inerzia", ma
anche i linguaggi di scripting gia` giocano un loro
ruolo, ed e` mia fervida speranza che in un futuro non
lontano cominceremo anche ad usare simili linguaggi ad
altissima produttivita` per implementare i componenti
stessi, non solo per usarli; magari dapprima solo come
prototipi, ma poi sono sicuro che emergera` la solita
"regola 80-20", per cui l'80% dei nostri componenti non
ha alcuna criticita` sulle prestazioni (che dipendono
invece in tutto e per tutto dal restante 20%; e le cifre
sono cosi` solo perche` la modellazione 3D con annessi
e connessi resta un'operazione estremamente CPU-intensive;
per molte altre aree applicative, il rapporto potrebbe
se mai essere 90-10 o piu`...), e quindi non vi sara`
ragione di reimplementarli in C++ una volta che la loro
funzionalita` sara` OK in Pyth^H^H^H^H un qualche buon
linguaggio di Scripting, elegante, fluido, dinamico, ad
altissima produttivita` (non faccio nomi:-).
Alex

 ha scritto nel messaggio
news:8k4okf$h19$1...@serv1.iunet.it...


efficiente e facilmente modificabile.
Tu non sai gli orrori che si possono trovare in un sorgente c++ 8-)))
Luc.

 professionale in Italia e perche' proprio il C++.
Premesse:
Io faccio il consulente per progetti embedded e real-time, principalmente nei campi dell'automazione e nell'automitive. Praticamente
vengo "assoldato" per lavorare a progetti dei miei clienti dove (di solito) faccio parte del team di sviluppo (quando non sono solo,
ovviamente ;) ).
Quando dico: "scritto in C++" intendo "progettato ad oggetti e scritto in C++".
L'utilizzo del C++ come "better C" non esprime le potenzialità del linguaggio.
---- Risposta [poco] seria:
Perchè utilizzo il C++ ? E cosa dovrei utilizzare ?
- L'assembler ? il C ?
Ho già dato, grazie.
Alla mia tenera età non si ha voglia di passare le notti a debuggare o a leggersi alcuni mega di codice cercando la funzione giusta.
- Java ?
Bellissimo linguaggio, ottimo per il WEB, ma non adatto per roba che deve "andare a manetta".
- Il VB ?
Non diciamo cose orrende ...
Nella mia situazione non ho altre possibilità.
Credetemi.
--- Risposta un po' più seria.
 - Programmi per il controllo e la gestione di macchine utensili speciali (sui 30x5x3 metri di hardware).
Dal collegamento TCP/IP al DB aziendale al controllo degli interrupts.
Interfaccia utente compresa (purtroppo).
All'inizio era tutto scritto in C e ASM. Poi la dimensione dei programmi e la stessa 'natura' delle macchine ha portato al C++. I
primi tentativi sono stati semi-fallimentari. Solo un utilizzo _massivo_ delle tecniche OOP ha
permesso di raggiungere i risultati sperati.
 - La centralina della Vs. auto ha un processore a bordo, lo sapevate ? ;-)
Tutto codice C e/o ASM che deve essere convertito (refactoring ?) in C++.
Work in progress ....
 - Programmi di supporto per l'automotive.
Programmi per l'analisi delle funzioni dei banchi di test dei motori.
  - Videogiochi
Un mod (modifica radicale a livello di codice) a Quake 2 e 3:  HolyWars.
Inoltre, vorrei fare notare che tutti i principali videogiochi 3D (IMHO tra i programmi + complessi che io abbia mai visto) sono
sviluppati in C++.
TaZ++

 professionale in Italia e perche' proprio il C++.
Io, come ho già detto qualche tempo fa, lo uso per piccolissimi progetti
che sviluppo da solo (tipo programmi matematici, statistici, lotto,
totocalcio... non ridete, questo mi viene richiesto :-) e per tutte
quelle cose non prettamente gestionali alle quali il mio fido Clipper
(coadiuvato egregiamente dalle librerie Fivewin) non arriva. Inoltre
cerco di tenermi il più possibile aggiornato a causa dei corsi, più che
altro individuali (ma non solo), che spesso tengo sull'argomento.
Una cosa che però, purtroppo, devo dire è che la mia preparazione
pratica riguardo la OOD è veramente scarsa in quanto, nato, cresiuto e
vissuto con la programmazione strutturata, faccio fatica a pensare i
nuovi progetti in senso strettamente object oriented e quindi mi limito
normalmente ad un approccio object based.
Ma sto cercando, anche grazie al newsgroup, di diventare un vero
programmatore OO. :-)
EMG
PS. Ho cominciato a studiarlo e usarlo nel 1993 (il primo sorgente di
prova che trovo nella vecchia directory del TurboC che utilizzavo allora
è un semplice stack ed è datato 14/10/93 :-)

 semplice C migliore ?
Da parte mia due cose: la richiesta e il fatto che mi piace. Bastano?
:-)
EMG

 Vien da domandarsi come siano i vostri stipendi :-)
Stai tranquillo che la quantità "enorme" di soldi non se la prendono
certo i programmatori che ci mettono il cervello e il sangue ma i soliti
chiacchieroni che non fanno un accidenti di costruttivo dalla mattina
alla sera. :-(
EMG

normalmente ad un approccio object based.
E' la malattia di cui soffro anch'io ! ;(
Spero di guarire nel tempo ! :)


 Un mod (modifica radicale a livello di codice) a Quake 2
Grandissimo gioco!
EMG

 per componenti.  
Condivido. Ormai la tendenza e' diventata una certezza.
Non solo via COM, ma anche librerie come le Qt spingono
a ragionare per componenti
La mia esperienza con il C++ copre un po' tutti i campi. 
Mantengo un'applicativo per la manipolazione dei file (IEEE, COFF, ELF, 
DWARF piu' altri proprietari) prodotti dai compilatori Embedded 
nel campo automotive. Chi mi aveva preceduto aveva fatto un'obbrobrio 
in C che impiegava anche delle mezzore per fare quello che oggi 
fa in 9 secondi.
Ho fatto applicazioni per la gestione e manutenzione remota di Banche 
Dati con il Borland Builder, che poi vengono utilizzate 
via Web attraverso script ASP e/o PHP (una visibile e' 
www.cinematografo.it/dati
)
Lo utilizzo per generare componenti ActiveX e/o estensioni a IE.
L'ho utilizzato per creare DLL per Java.
Lo utilizzo per la creazione di estensioni crossplatform a Matlab.
Lo utilizzo per un'applicazione cross-platform nella quale 
utilizzo anche le librerie Qt (meravigliose).
L'ho utilizzato per l'I/O su seriale/RAS/TAPI.
Ho usato anche Java per creare un'applicativo su CDROM, ma non mi
ha mai convinto.
E poi da' molta soddisfazione poter "creare", meglio dire "comporre",
un'applicazione utilizzando la potenza espressiva del C++. O no???
Fausto

 del linguaggio.
Non le esprime tutte, certo, ma se e` per questo neppure un
utilizzo ad oggetti le esprime, perche` ignorare i template
non sfrutta appieno il suo potenziale.
Non e` detto che un dato componente debba sfruttare appieno
TUTTE le potenzialita` del linguaggio: sara` progettato al
meglio se e solo se sfruttera` tutte quelle che gli portano
beneficio, e nessun'altra ("do the simplest thing that could
possibly work" e` un principio di grande valore, anche se
"simplest" qui non significa certo "per chi il linguaggio
non lo conosce sino in fondo"!-).
Alex

semplice C migliore ?
Onestamente non ho mai utilizzato il C++ nell'ottica di un C migliore,
ma come linguaggio OO.
Penso che il problema siano (IMO) le persone che non riescono a 
vedere in un linguaggio piu` della sua sintassi e della sua semantica.
Cosi` succede che in un linguaggio che offre una sola alternativa, sei
costretto ad operare in un certo modo, in uno che ne offre 3-4
fai pasticci perche` non riesci ad andare oltre il problema di
far funzionare al momento il codice ottenendo un prodotto mediamente
peggiore.
Paolo
--------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
--------------------------------------------------

Enrico,
quanto segue e' piu' una curiosita' che non un suggerimento: mi vien da
pensare che per chi svolge un'attivita' come la tua ed e' interessato
anche ad approcciare i problemi in un certo modo (ad es. costruiendosi
degli strumenti, delle librerie riutilizzabili, ecc.), un ambiente come
il C++Builder della Borland, potrebbe ridurre l'overhead iniziale
rispetto a strumenti in un certo senso piu' semplici (il tuo amato
Clipper, per esempio :-), pur fornendo notevoli vantaggi per esempio
rispetto alla realizzazione di componenti software. Che ne pensi?
Ciao,
Nicola

 non sfrutta appieno il suo potenziale.
    [snip]
Concordo.
La precisazione si riferiva al tipo di utilizzo del C++ che vedo in diverse aziende:  i progetti vengono sviluppati con metodologie
procedurali (quando va bene) o con nessuna metodologia (pezzi di carta sparsi e giù a scrivere codice).
In quest'ottica si utilizza il C++ come un "C migliorato", svilendone le potenzialità.
Allo stesso modo, utilizzarlo come OOPL "puro" non esprime appieno il linguaggio.
Inoltre,
 - nel software real-time è fondamentale l'efficienza, una progettazione OOP "pura" comporta, quasi sempre, soluzioni non
applicabili realmente. L'utilizzo dei template è vitale.
 - Alcune specifiche parti, per loro _natura_, devono essere risolte con modalità non strettamente ad oggetti (per esempio:
interrupts critici).
TaZ++


No, nessuno mi convincerà mai a scrivere gestionali in C++. :-)
EMG


Come mai scarti a priori la possibilita' di poter fare del gestionale 
in C++ facendoti aiutare dal Builder???
Fausto

 in C++ facendoti aiutare dal Builder???
Per il motivo che si è discusso tante volte qui: l'estrema complessità
del C++, complessità che non puoi fare a meno di portarti appresso anche
se non la desideri e cerchi di evitarla, non è giustificata dalla
modesta richiesta di efficienza elaborativa di un gestionale. E la
produttività sarebbe nettamente inferiore.
EMG

produttività sarebbe nettamente inferiore.
Secondo me non e' cosi'.
Il C++ Builder ti fornisce il framework VCL che puo' facilmente
guidarti nella scrittura di gestionali.
