Newsgroup: it.comp.aiuto
Titolo: Quale C ?

Mi occupo di acquisizione dati in ambito industriale e vorrei iniziare a 
programmare in C sotto DOS.
Sono indeciso se cominciare col Borland o con il Microsoft, se con il C 
'normale' o con il C++.
Qualcuno puo' illuminarmi sulle differenze ed eventualmente consigliarmi?
Grazie e ciao
-- 
Roberto Marchini

Qualcuno puo' illuminarmi sulle differenze ed eventualmente consigliarmi?
anch'io lavoro in ambito industriale mi occupo pero' di software per
supervisione e controllo (SCADA).
Ho avuto modo di usare i compilatori Microsoft e Watcom e devo dire
che in ambiente Dos preferisco di gran lunga quest'ultimo per i
seguenti motivi: 
1. Comprende sia il compilatore a 16bit che quello a 32bit con tanto
di Dos/Extender, in molti casi e' preferibile lavorare con programmi a
32bit in modo da risolvere in modo definitivo il limite dei 640kb del
dos.
2. Genera un codice decisamente migliore e piu' ottimizzato rispetto a
MS.
3. Permette la massima flessibilita' di chiamata delle funzioni, ad
esempio se ho una funzione in assembler che richiede di passare dei
parametri in alcuni registri posso dire al compilatore come fare la
chiamata, dove mettere i parametri e dove si trova l'eventuale
risultato.
4. Il compilatore MS per DOS/Windows a 16bit (Visual C++ 1.52) ormai
e' stato abbandonato e non verra' ulteriormente sviluppato da MS.
5. La documentazione on-line e' consultabile anche lavorando in Dos,
con il Visual C occorre usare Windows oppure acquistare a parte i
manuali.
In quanto alla scelta tra C e C++ secondo me bisogna valutare di volta
in volta in base alle esigenze del progetto.
Il C e' un linguaggio che consente la massima liberta' al
programmatore che ha il completo controllo sul codice. Al contrario il
C++ ha un maggior rigore formale e una maggiore astrazione questo
aggiunge un certo overhead nella generazione del codice pero'
facilita' la scrittura di programmi corretti e la gestione di progetti
di grandi dimensioni.
In linea di massima quando e' richiesto il massimo controllo del
codice generato dal compilatore e' meglio usare il C che ha un
overhead minimo, cioe' il compilatore aggiunge pochissimo di suo. Se
viceversa il progetto inizia ad assumere maggiori dimensioni oppure si
usano strutture dati complesse e' preferibile svilupparlo in C++
limitandosi magari a scrivere in C le parti piu' critiche. Non bisogna
dimenticare che C e C++ non si escludono a vicenda ma si integrano
benissimo.
Gianpaolo Bottin
Bruino (TO) - Italy
E-Mail: 
bott...@mbox.vol.it
-----------------------------------------

 writes:
M> Mi occupo di acquisizione dati in ambito industriale e vorrei
M> iniziare a programmare in C sotto DOS.  Sono indeciso se cominciare
M> col Borland o con il Microsoft, se con il C 'normale' o con il C++.
M> Qualcuno puo' illuminarmi sulle differenze ed eventualmente
M> consigliarmi?
Watcom  :), considera anche quello,  pare che il suo ottimizzatore sia
di ottima qualita'.
Considera inoltre che per le tue necessita` puo` essere indispensabile
andarsi a buttare giu` fino al  linguaggio macchina per ovvi motivi di
tempo di risposta. Il  C++ puo` permettere una migliore organizzazione
del lavoro in assenza di autodisciplina del programmatore, ma un'abuso
delle sue feature puo'  portare  a perdite di  efficenza intollerabili
nel tuo caso.
o   oooooo	Gian Uberto Lauri        "So, are you working on finding
      o    o	
sa...@maya.dei.unipd.it
   that bug *now* or leaving it until
     o o				  later?" - "Yes!" 

Sono indeciso se cominciare col Borland o con il Microsoft, se con il C 
Evita il Microsoft come eviteresti la peste! Credo che qualsiasi altro
compilatore sia migliore; personalmente uso Borland e lo trovo superbo.
Per quanto riguarda C o C++, li' e tutto da vedere; lavoro nel campo dei
controlli di processo e fino ad ora non ho ancora visto usare il C++ in
applicazioni con strette esigenze di realtime.
saluti
+------------------------------------------------------------+
| 
dant...@tn.village.it
                                     |
| 
marco...@elsag.it
                                       |
| Marco Danti, Via Morselli 24, 16158 Genova Italy           |
+------------------------------------------------------------+

 applicazioni con strette esigenze di realtime.
Il C++ e decisamente abbastanza piu` complicato, anche se ha i suoi vantaggi,
comunque farsi un po' le ossa sul C secondo me e` inevitabile.
ciao
Franz
-- 
Francesco Di Tolla, Center for Atomic-scale Materials Physics
Physics Departement, Build. 307, Technical Univesity of Denmark, 
DK-2800 Lyngby, Denmark, Tel.: 
(+45) 4525 3208
/3210 Fax: 
(+45) 4593 2399
mailto:
dit...@fysik.dtu.dk
 
http://www.fysik.dtu.dk/persons/ditolla.html

compilatore sia migliore; personalmente uso Borland e lo trovo superbo.
non credo che esistano classifiche assolute o giudizi assoluti nemmeno
nel campo dei compilatori, come tutti i programmi anche il Visual C++
ha i suoi pregi e i suoi difetti. Il suo vantaggio fondamentale ? Nel
mondo della programmazione professionale in ambiente windows e' lo
standard di fatto. Ho avuto modo di acquistare di recente delle
librerie di classi come MFC Extension che sono molto interessanti e
ovviamente sono disponibili solo per Visual C. E' vero che anche altri
compilatori distribuiscono le MFC ma si tratta sempre di una versione
antecedente a quella del Visual C.


applicazioni con strette esigenze di realtime.
Beh, io l'ho visto utilizzare in controllo di processo, e piu'
precisamente si trattava del Visual C++, che gestiva un programma di
"supervisione" con I/O su schede analogiche, in "collaborazione" con
appositi software di controllo di laboratorio.
Bye, Luca.
ta...@pianeta.it
 - San Polo d'Enza (RE) - Italy
***********************************************
******      The truth is out there       ******
***********************************************

ringrazio gli amici che hanno risposto alla mia richiesta.
Non avevo considerato il Watcom, ma spesso vedo che certe schede 
forniscono delle librerie le quali sono o per MS o per Borland.
ciao
-- 
Roberto Marchini

> usare il C++ in applicazioni con strette esigenze di realtime.
FDT> Il C++ e decisamente abbastanza piu` complicato, anche se ha i
FDT> suoi vantaggi, comunque farsi un po' le ossa sul C secondo me e`
FDT> inevitabile.
Ci sono posti dove "C++" e' considerato una parolaccia, e in quei
posti c'e' tanto da imparare.
Il C++ in ogni caso aggiunge degli overhead che possono essere
intollerabili nelle applicazioni real time.
Curiosita': Ma perche' in  italia si usano i PC  per il real time ? Vi
fa proprio cosi' schifo programmare una CPU con  16 registri interni ?
O meglio una con 32 (anche se questa non la  ho ancora vista impiegata
in questo campo) ?


in questo campo) ?
beh, parlando di PC industriali, cioe' di computer con
monitor,tastiera,HD,ecc. inseriti in un rack di tipo industriale non
e' che ci sia molta scelta. Ho sentito dire recentemente che alcuni
produttori avrebbero intenzione di usare delle schede con CPU Alpha
che Digital fornirebbe a prezzi concorrenziali a quelle dei PC
Pentium.


 writes:
M> ringrazio gli amici che hanno risposto alla mia richiesta.  Non
M> avevo considerato il Watcom, ma spesso vedo che certe schede
M> forniscono delle librerie le quali sono o per MS o per Borland.
Watcom dovrebbe essere in grado di usare le  librerie di MS, salvo che
non facciano riferimenti espliciti al runtime di microsoft.


> vista impiegata in questo campo) ?
GB> beh, parlando di PC industriali, cioe' di computer con
GB> monitor,tastiera,HD,ecc. inseriti in un rack di tipo industriale
GB> non e' che ci sia molta scelta.
Non commento. Di 680x0 non si e' mai sentito parlare eh ? BAH!!!!
GB> CPU Alpha che Digital fornirebbe a prezzi concorrenziali a quelle
GB> dei PC Pentium.
Questa e' una notizia carina....


> che non facciano riferimenti espliciti al runtime di microsoft.
GB> e' vero il Watcom permette di linkare file obj generati dai
GB> compilatori MS, in pratica pero' non ho mai provato. Per andare
GB> sul sicuro ho sempre preferito usare i compilatori MS quando
GB> dovevo usare una libreria di terze parti.
L'unico problema che ho avuto e' stato per una libreria che faceva
uso di un simbolo del runtime credo per la printf, e che non veniva
soddisfatto. Il formato e' gestito senza alcun problema.


standard di fatto. Ho avuto modo di acquistare di recente delle
Infatti, purtroppo, bisogna tenere conto anche del supporto "terze
parti".  Visual C++, parlo solo della versione 4.1 che conosco bene,
ha i suoi difetti (soprattutto bug, molti dei quali emergono con
prepotenza solo nella gestione di progetti _grandi_, ma anche carenza
di feature per {A} facilitare la collaborazione di molteplici
progettisti e {B} seguire l'evoluzione dello standard ANSI C++),
ma anche pregi (ambiente di lavoro accattivante, e, per piccoli
progetti [diciamo entro le 20-30 mila righe di codice], anche assai
usabile; discreto array di features C++, superiore ad esempio al
Watcom C++ 10.6; buon supporto da terze parti).  Se potessi fare
la mia scelta "nel vuoto" non dubito che propenderei per il C/C++
della Cygnus (versione di quello Free Software Foundation): gratis,
disponibile su tutte le piattaforme con possibilita` di cross
compilation, stesse feature/bug/limitazioni su tutte le piattaforme,
eccetera eccetera -- ma cosi` facendo mi taglierei fuori dall'accesso
pieno al "parco" di librerie e strumenti ``terze parti'', che possono
invece offrire un'ottima "leva" di produttivita` nello sviluppo.
Quanto all'affermazione che "qualsiasi altro compilatore sia migliore"
del Visual C++ 4.1, mi piacerebbe costringere chi l'ha scritta a fare
il porting di codice C++ -- mica tanto, poche decine di migliaia di
righe -- sviluppato su Unix sotto GCC, e portato facilissimamente a 
VC++ -- sui vari compilatori proprietari (IBM, DEC, HP...) delle varie
box Unix... e godermi l'espressione quando realizzera` che il codice
e` progettato con dipendenze cruciali da features che sono nel draft
ANSI Standard C++ sin dall'inizio del '93, come il dynamic_cast<>...
e che GCC e VC++4.1 supportano benissimo... e questi altri compilatori
*NON* supportano -- quello IBM, ad esempio, documenta accuratamente
che implementa il draft ANSI Standard C++ del *1992* -- piu`, magari,
Nmila estensioni proprietarie, magari carine, come il SOM, ma *NON*
usabili, ovviamente, da chi voglia/debba tenere in vita il proprio
programma su parecchie piattaforme diverse...:-(
Alex
--
DISCLAIMER: these are MY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: 
mart...@cadlab.it
 -- Phone: +39 (51) 597 313  [Fax: 597 120]
Cad.Lab S.p.A., v. Ronzani 7/29, 40033 Casalecchio (BO), Italia

 writes:
AM> anche assai usabile; discreto array di features C++, superiore ad
                                  ^^^^^^^^^^^^^^^^^^^^^
AM> esempio al Watcom C++ 10.6; buon supporto da terze parti).
Se  non erro il  Watcom  e' compatibile a  livello   di ogetto con  il
Microsoft...
AM>  Se
AM> potessi fare la mia scelta "nel vuoto" non dubito che propenderei
AM> per il C/C++ della Cygnus (versione di quello Free Software
AM> Foundation):
Chiamalo col suo nome, GCC :). La cygnus distrubuisce molti
precompilati del software GNU.
Tra   l'altro  il     GCC   ha  un'ottimo    ottimizzatore    (scusate
l'alliterazione) che si fa sentire  sopratutto con cpu un tantin  piu'
serie delle architetture Intel Classiche (fino al pentium).
Tra l'altro,  mi domando quando le  aziende italiane si sveglieranno e
si accorgeranno che i processori  migliori non sempre son sulla  bocca
di tutti. Ci sono architetture con 31 registri interni disponibili (il
32 e' fisso a 0 :) ), bon il buon GCC  ne usa gia'  una buona fetta se
solo  gli chiedi di  ottimizzare, se poi  cominci  ad usare la keyword
"register" obbedisce diligente...
AM> Quanto all'affermazione che "qualsiasi altro compilatore sia
AM> migliore" del Visual C++ 4.1, mi piacerebbe costringere chi l'ha
AM> scritta a fare il porting di codice C++ -- mica tanto, poche
AM> decine di migliaia di righe -- sviluppato su Unix sotto GCC, e
AM> portato facilissimamente a VC++ -- sui vari compilatori
AM> proprietari (IBM, DEC, HP...) delle varie box Unix...
CAAAAAAAAAAAAALMA!
Qui giochi MOLTO SPORCO!
Hai citato 3  casi di Unix MOOOOLTO  proprietari e molto a se' stanti.
Ti sfido a far girare bene un programma da  qualche centinaio di righe
chiamato "talk" sotto una HP9000/800 - a meno che  non si siano decisi
a metterci un kernel di rete decente. E non siamo ancora nel campo
delle "Unix farebbe cosi', ma io invece faccio cosa'".
AM> implementa il draft ANSI Standard C++ del *1992* -- piu`, magari,
AM> Nmila estensioni proprietarie, magari carine, come il SOM, ma
AM> *NON* usabili, ovviamente, da chi voglia/debba tenere in vita il
AM> proprio programma su parecchie piattaforme diverse...:-(
Ahem, forse e' il caso che ti riguardi cosa  dice IBM delle sue classi
Open  Doc, per quel che riguarda  la portabilita' (BTW, nella lista di
portabilita'  e' incluso Solaris, ergo tutti  i System V - peccato che
abbia simpatie BSD!)


Watcom C++ 10.6; buon supporto da terze parti). 
sono d'accordo il VC 4.1 ha dei difetti, ma non mi sembra che i miei e
i tuoi coincidano ! 
Non trovo ad esempio grossi problemi nella collaborazione tra
sviluppatori, d'accordo siamo solo in 3, ma SourceSafe ci risolve
tutti i problemi, il VC che c'entra ? 
Stiamo sviluppando un progetto che conta allo stato attuale circa 300
sorgenti e 5 file di risorse, ma non ho mai riscontrato problemi
particolari oltre ai classici piantamenti del developer studio. 
Il difetto maggiore mi sembra invece che stia proprio nell'ambiente di
sviluppo, accattivante ma troppo incasinato. Infatti continuo a usarlo
sono per le risorse e la gestione del progetto. Preferisco di gran
lunga lavorare con un editor esterno e ad consultare MSDN con
l'Infoviewer.
Riguardo alla compatibilita' con lo standard ANSI C++ la cosa non mi
tocca minimamente, ritengo invece fondamentale il supporto da terze
parti.
