Newsgroup: it.comp.lang.c++
Titolo: Curiosità:  C e C++

 
 Con C++ posso fare tutto ciň che fa C oppure ci sono campi in cui posso 
fare con uno e non con l'altro?
 
Ciao
 
nero23 
 

 nero23
 
 

 
< Sostanzialmente il C++ non ha rinunciato a nulla di quanto
< consentiva il C. Ti consiglia solo, caldamente, di scrivere
< pulito e tipizzato strettamente (e early bounded), ma ti ..
 
In rete ho letto che con C puoi progettare sistemi operativi e driver per 
periferiche.
In questo caso, C++  come si posiziona?
 
Grazie
 
nero23
 

 periferiche.
 
Intano inizia ad imparare a progettare sistemi operativi.
 
-- 
-riko
http://www.enrico-franchi.org/
 
http://rik0-techtemple.blogspot.com/
 

> Intano inizia ad imparare a progettare sistemi operativi.
 
 
ho chiesto ben altro!
 

 ho chiesto ben altro!
 
Vedi, il problema e' che e' evidente che ti stai ponendo falsi problemi.
In generale, quello che chiedi, non ha senso.
 
Vuoi sapere se imparare C o C++? Vuoi imparare quale sia piu' indicato
per fare $X? Il problema e' che, per quando C++ sia un linguaggio
complesso da imparare, il costo di imparare $X e' assolutamente molto
maggiore della somma di imparare entrambi i linguaggi.
 
Io credo che quello che ti farebbe bene, e' probabilmente capire cosa
vuoi fare (imparare un linguaggio o l'altro e' quasi un dettaglio,
probabilmente se non sai nemmeno programmare le scelte migliori sono
altre ancora).


Se  chiedo al mio dietologo cosa fa  ingrassare di meno tra la CocaCola e 
l'olio, mi aspetto che mi dica semplicemente: CocaCola!
Sapere quale delle due fa più male al nostro organismo, è un'altra domanda 
che io non ho fatto e tantomeno devo mettermi a dieta. E' solo una 
curiosità...
 
Non voglio fare polemiche, ma ritengo che   Soviet_Mario abbia dato la 
risposta più appropriata fregandosene se io debba imparare uno o l'altro 
linguaggio di programmazione.
 
Non te la prendere...
Ciao
 
nero23 
 

 In generale, quello che chiedi, non ha senso.
 
Gli volevo rispondere esattamente così, ma poi ho lasciato perdere e 
pare che ho fatto bene... comunque lode a te per la buona volontà di 
predicare agli uccelli :-)


 
Sì.
 
P.S. Come vedi, non sarebbe stato molto utile.

 P.S. Come vedi, non sarebbe stato molto utile.
 
Anche perche' si completa con "con C posso fare tutto quello che faccio
in C++". E per scendere nel dettaglio di esattamente cosa venga meglio
con uno e con l'altro... beh, buona fortuna.


 pare che ho fatto bene... 
 
Mi costa cosi' poco... 


 In generale, quello che chiedi, non ha senso.
 
Io penso invece che abbia senso chiedersi quali tipi di software si 
possano sviluppare con un dato linguaggio.
Principalmente, perche' per produrre del software con un linguaggio 
serve un sistema di sviluppo (compilatore o interprete, e librerie), e 
per ogni coppia piattaforma-linguaggio di programmazione, possono 
esistere zero o più compilatori decenti.
Secondariamente, per una coppia piattaforma-linguaggio di 
programmazione, pur essendo possibile sviluppare del software, 
potrebbero esserci svantaggi di vario tipo, come l'inefficienza 
inaccettabile, la carenza di documentazione o di librerie, la 
difficolta' di trovare persone da assumere, la penuria di articoli, 
libri, blog, forum, corsi che trattino l'argomento.
 
Per quanto riguarda il C++, non saprei se esistono piattaforme per cui 
non esistano compilatori, ma mi pare che il C++ sia usato poco o niente 
per sviluppare software per microcontrollori a 8-bit, che solitamente 
hanno una manciata di chilobyte di RAM.
Mi pare anche che per alcune piattaforme solitamente si evitano:
- l'allocazione esplicita della memoria (tramite malloc, free, new e 
delete), e quindi le stringhe e i contenitori della libreria standard;
- le eccezioni;
- la RTTI;
ma questo non impedisce di usare il resto del linguaggio C++.
 
-- 
 
Carlo Milanesi
http://carlomilanesi.wordpress.com/
 

  wrote:

Infatti il succo era che solitamente si sceglie il linguaggio in base
alla necessità e non viceversa :-)
Ciao!

 ma questo non impedisce di usare il resto del linguaggio C++.
 
anche io penso che C++ sia "scalabile in basso" sino al C 
schietto da cui deriva. E salvo rimettere mano a progetti 
giganteschi già esistenti in C, non capisco nessun vantaggio 
a cominciarne ex novo uno in C oggigiorno.
ciao
Soviet
 
 
 
 

 a cominciarne ex novo uno in C oggigiorno.
 
Due parole: name mangling.


 oggigiorno.
 
io sì, se vantaggio si può chiamare: piattaforma harware
il cui compilatore C++ è sottilmente buggato e nel
migliore dei casi produrrebbe un codice su cui non
potrebbe girare e tocca andare "più vicini al ferro", come
mi pare si dica. Naturalmente non ho sparato a caso :( e
sto disperatamente chiedendo un hardware che non sia un
pallottoliere a 7 MHz.
 
naturalmente lo dico solo per lamentarmi un po', so bene
che qui è in questione tutt'altro problema.
 
ciao!
 
Apx.
 
 


Il name mangling si risolve con extern "C"
 
 

 Il name mangling si risolve con extern "C"
 
E come fai a fare extern C su una cosa templatica, per dire?
Il linkage C non lo puoi usare con i templates. Puoi usarlo per le
funzioni. Il problema e' che se sviluppi una libreria C++ non banale,
usando effettivamente i vantaggi di C++ su C extern "C" si applica solo
su pochi casi. Il risultato e' che interfacciare tale libreria con terze
parti puo' essere problematico.



 
quindi questa è una pecca del C che non vede il C++, non una 
pecca del C++ che non  riesce ad importare da C.
Come dicevo : essenzialmente il C non ha nessun vantaggio 
sul C++, salvo le costrizioni di codice precedentemente 
scritto (cosa che dissi da subito).
 
ciao
Soviet
 
 

 scritto (cosa che dissi da subito).
 
Ma certo che ne ha. E' un linguaggio molto piu' semplice, per esempio.
In particolare, per come la maggior parte delle persone usa il C++
(cioe' male) farebbero proprio bene ad usare C dove ci vuole la parte
low level di C++ e un linguaggio di piu' alto livello altrove.


 il C abbia o meno vantaggi sul C++ ancora oggi.
 
Molto semplice: se scrivi una libreria in C la puoi chiamare in modo
banale da: C, C++, D, Python, Pascal, ... e in modo quasi banale da
praticamente tutti gli altri.
 
Se scrivi una libreria in C++ hai molte piu' rogne per fare il bridge
verso qualcosa che non sia C++.
 
Questo da solo e' un ottimo motivo per usare C per questo tipo di
progetti: scrivere codice "universalmente" usabile.
 
Uno dei tanti esempi.


 low level di C++ e un linguaggio di piu' alto livello altrove.
 
Vabbè, se tra i difetti del linguaggio ci mettiamo i difetti 
apportati dall'utente che lo usa male, posso concordare. Ma 
questa argomentazione in sé mi convince meno del problema 
del mangling nella produzione di librerie di uso generale.
 
ciao
Soviet
 
 
 
 

 del mangling nella produzione di librerie di uso generale.
 
No: la complessita' del linguaggio e' un suo difetto. Direi il piu'
evidente. 



 
extern "C" non significa che il codice sia C,ma che la convenzione di 
chiamata è C
E' possibile costruire una classe C++ in un wrapper a extern "C" e 
buttare il tutto in una libreria perfettamente usabile anche da altri 
compilatori.
E visto che anche qui, il concetto di classe non esiste in C
non si perde nulla rispetto al C

 numerico ? Cosa ?
 
Una dispositivo biomedicale; in sostanza si è trattato di
implementare un modello biofisico. Ma adesso non ci voglio
pensare perché il modello ora in commercio è arrivato nel
momento peggiore, di recessione; si vende poco e sono
depressissimo. Come tutti gli esseri umani sarei contento
di vedere il mio lavoro apprezzato da critica e mercato...
:( Si stava pensando alla serie successiva ma la vedo
difficile. Magari ti dico di più in prv per non rompere le
scatole qua.
 
Comunque implementare l'integrazione di eq.
differenziali usando l'aritmetica intera è stata una bella
sfida :D e son contento di esserci riuscito; letteratura
ce n'era pochissima.
 
ciao!
 
Apx.
 

 da poter dire più di questo. 
 
"Potenza"? Non e' una macchina. ;)


 libri, blog, forum, corsi che trattino l'argomento.
 
Assolutamente d'accordo. Ma, a mio avviso, fra C e C++ questo tipo di
considerazioni non si applicano davvero.  


 non si perde nulla rispetto al C
 
Quindi cosa abbiamo concluso? Che essenzialmente usando C++ come fosse C
e rinunciando alle "innovazioni" possiamo farci linkare facilmente da
fuori?
 
Gia'... scrivendo C in C++ possiamo fare proprio questo.
 
Il problema e' che scrivere una libreria in C++ moderno (che e' quello
che vorrei fare se scelgo di usare C++ invece di C, come dicevo, se devo
usare C++ grosso modo come userei C, faccio a meno) diventa un problema
se la si vuole usare da qualcosa che non sia C++.
 
In particolare e' un problema su cui mi sono scontrato: fare un API
essenzialmente C sopra una bella libreria C++ che faccia massiccio uso
di templates, tecniche "moderne" (di 10 anni fa) tipo le policy e
compagnia e' essenzialmente un bagno di sangue. Fine della storia: e'
qualcosa che funziona su cose molto piccole, molto poco C++ oppure come
estrema ratio. 
 
Semmai funzionano meglio oggetti come swig (con tutto il macello che si
porta dietro) per semplificare il boilerplate. Ma non mi sembra di dire
nulla di sconvolgente, sono cose note a tutti. 
 
E la mia posizione e' che per scrivere qualcosa che voglio chiamare dal
resto del mondo, se devo scegliere fra scrivere del cattivo C++ o
dell'ottimo C, preferisco semplicemente scrivere in C. Scrivere
dell'ottimo C++ semplicemente non e' un'opzione per come funzionano oggi
le cose.


 Semmai funzionano meglio oggetti come swig
 
per curiosità, di cosa si tratta ? Non conosco questo 
acronimo o nome o quel che è. Se si può accennare in due parole.
 
ciao
Soviet



E quindi rinunci al C++ solo perchè è "complicato" costruire una 
libreria dinamica portabile ?
Mi sembra troppo riduttivo a meno che la tua professione sia quella di 
costruire solo librerie
 
 

 acronimo o nome o quel che è. Se si può accennare in due parole.
 
E' piu' facile "mi sento fortunato" su Google. :)
http://www.swig.org/
 
 
Praticamente (in teoria) ti fa il mestieraccio di wrappare C++ perche'
sia facilmente compreso dal resto del mondo in automatico. In pratica e'
molto meno automatico di quello che ti "vendono" e bisogna insomma
starci attenti (specialmente testare accuratamente sui pochi linguaggi
che uno decide di supportare attivamente).


 libreria dinamica portabile ?
 
Veramente rinuncio a C++ perche' mi fa perdere un mucchio di tempo e
fine della storia. Poi voglio dire, e' uno dei tanti coltellini che so
usare, se ne avessi bisogno e' ancora li. Al momento non ne ho bisogno.
 
Sono invece piuttosto affascianato da 2011, che pare abbiano pezzato
molte delle cose che mi infastidivano soverchiamente. Si vedra'.
 
Comunque il thread diceva essenzialmente per quali cose va meglio C e
quali C++. L'ipotesi dominante sul ng (di C++, guardacaso) e' che C++ fa
tutto quello che fa C (meglio) e che non c'e' ragione per per usare C.
 
Io trovo che invece ci siano anche ragioni per usare C (alcune delle
quali sono state esposte da altri) e questa e' stata esposta da me. 


 
http://www.swig.org/
 
 
 
ok grassie
 
Soviet


 molte delle cose che mi infastidivano soverchiamente. Si vedra'.
Si, sono interessanti, ma non apro una discussione su C++2011


 tutta la parte non esportata puo essere codice C++ anche complesso
 
Mi sa che non ci siamo. Probabilmente non sono stato in grado di
spiegarti il problema; non ci ho investito molto, pensavo fosse
abbastanza ovvio.
 
Al mondo esiste altro oltre C++. Questo altro parla piu' o meno
universalmente bene con C.
 
Quando scrivo in un linguaggio, a me piace progettare il lavoro usando
le features di quel linguaggio. Di solito il lavoro viene meglio. Quando
progetto una libreria in C++, tipicamente voglio usare templates e
namespace *anche* nell'interfaccia. 
 
C++ offre delle cose comode *specialmente* quando si progetta una
libreria. I templates sono praticamente il nocciolo di scrivere codice
riusabile in un linguaggio con static typing: o hai un type system
decente come Haskell, oppure, senza i templates, devi fare magheggi. 
 
Se uso C++ e' perche' non voglio magheggiare con i void* (non che sia un
problema, eh, ma visto che ho comunque il typing fra le scatole, almeno
che faccia qualcosa di utile -- vedi templates --). 
 
Riprogettare un'interfaccia perche' *non* faccia uso di templates *e*
sia comoda non e' banale. Certo, se scrivi C++ molto elementare
probabilmente non ci sono grosse questioni.
 
Il problema e' che se devo scrivere C++ elementare, allora tanto vale
usare C. Io voglio usare C++ come si deve. E questo *non* si puo' fare
dentro gli extern. 


 namespace *anche* nell'interfaccia.
Perfettamente d' accordo
ma nel mondo reale qualche volta non è possibile perchè esistono delle 
limitazioni a cui sottostare
 


 
Sì, no, forse.
Faccio due osservazioni così, in generale, visto che purtroppo
nell'ultimo anno ho scritto una quantità di briges e wrappers da
mettersi a piangere..
- Che io abbia visto, una libreria con interfaccia C è utilizzabile
praticamente da chiunque, quindi è sicuramente la soluzione più
riusabile.
- Se ho una codebase C e devo sviluppare una libreria ovviamente non
lo faccio in C++ a meno che:
- - non debba utilizzare una libreria di terze parti in C++
- - la libreria esporta solo due/tre funzioni stupide e fa un sacco di
lavoro dentro (mettiamo ad esempio una libreria di calcoli, prende un
array in input e da un array in output: dentro posso usare vettori,
code, classi, etc.etc. per mia comodità)
Ci sono sicuramente altri casi che non mi sovvengono, ma solitamente
un po' di buon senso e si trova la soluzione migliore per il caso
specifico. Ovviamente sono possibili anche varie aberrazioni, come mi
è capitato di vedere (per connettere una libreria .NET ad un codice C
avere due DLL di bridge, una in C++/CLI e una in C/C++) il che non è
necessariamente sintomo di cattiva progettazione, ma dell'eccessiva
eterogeneità dei linguaggi.
M2C
Ciao!

 limitazioni a cui sottostare
 
Figurati. Ma allora, come dicevo, uso C. 
