Newsgroup: it.comp.lang.c++
Titolo: Importante! Visual C++ o Borland C++ ?

Salve a tutto il NG,
ho gia' postato un messaggio sull'argomento in oggetto ma mi sono accorto di
essermi spiegato male non ottenendo le risposte che speravo. Dovendo
scegliere un C++ per Win95 e maggiori (lasciamo perdere le applicazioni a 16
bit per Win311 che potevano essere un utile sovrappiu') chiedo a chi conosce
sia VCC sia BCC di spiegarmi le differenze ed i vantaggi dell'uno rispetto
all'altro e viceversa. A chi invece ne utilizza soltanto uno, chiedo di
"convincermi" a sceglierlo spiegandomi le motivazioni della sua scelta.
Vi ringrazio infinitamente e buon lavoro a tutti.
Alex.T
3P electronics
tr...@tiscalinet.it

Per il RAD di applicazioni con interfaccia "classica" Borland C++ Builder.
Per lo sviluppo hardcore Windows Visual C++.
--
MindFlavor's Site 
http://web.tiscalinet.it/mindflavor
Mail: mailto:
mindflav...@hotmail.com

 Per lo sviluppo hardcore Windows Visual C++.
Penso di potere sottoscrivere queste raccomandazioni.
BC++B ha la VCL, un buon framework per il RAD.
MSVC++ ha l'ATL, un ottimo framework per COM (se
non sbaglio di recente lo include anche Borland, senza
dubbio su licenza Microsoft, ma la versione originale
sara`, penso, meglio supportata e aggiornata), e il
COM e` davvero fondamentale oggi per "sviluppo
hardcore".
Suggerirei di togliere it.comp.lang.c++ dalla lista
dei gruppi, e mettervi invece il gruppo dedito proprio
alla programmazione su Win32, cioe`
it.comp.programmare.win32.
Alex

Il Borland C++ Builder e' anche considerato piu' aderente allo standard
ISO ed ha un migliore supporto dei template, per quanto in nessuna delle
due aree sia ancora completo.
Ciao,
Nicola


Scusa la mia piu' completa ignoranza ma cosa significa RAD e hardcore ?

hardcore".
Esatto, lo include anche il BCB.

"convincermi" a sceglierlo spiegandomi le motivazioni della sua scelta.
Io utilizzo C++ Builder 4 nella versione Enterprise e devo ammettere
che e' davvero potente per qualsiasi tipo di progetto tu debba
sviluppare. Se punti alla programmazione distribuita questo ambiente
ti da' un'ottimo supporto sia per COM/DCOM che per CORBA.
E poi le VCL sono fantastiche ! ;)

Rapid Application Developement. C++ Builder, grazie alle classi VCL permette
di creare un interfaccia grafica "droppando" semplicemente sul form dei
componenti già programmati senza scrivere una linea di codice. Come puoi
immaginare il vantaggio è la velocità nello sviluppo, lo svantaggio è di
essere vincolato da scelte fatte da altri.
Per programmazione hardcore si intende lo sviluppo utilizzando gli aspetti
più "complessi" e potenti delle interfaccie di programmazione.
ByEZ,


 E poi le VCL sono fantastiche ! ;)
Fantastico ho trovato una persona piu' unica che rara... come me! :-))
SISMA

essere vincolato da scelte fatte da altri.
Be', pero' questo vincolo e' relativo, esistono le classi custom ed e'
possibile riscriversi un componente che meglio si adatti alle proprie
esigenze.

 essere vincolato da scelte fatte da altri.
Anche se questo vincolo c'è sempre, indipendentemente dallo strumento
che si sta usando. Anche scrivendo direttamente i programmi in codice
macchina binario si dovrebbe comunque sottostare al vincolo imposto dal
particolare processore utilizzato.
EMG

Premettendo che io uso il solo BCB per programmare in C volevo far notare
che, troppo spesso, le VCL hanno lo svantaggio di portare lo sviluppatore ad
un approccio top-down che poco si addice all'OOP. Il mio concetto di "scelte
di altri" riguarda solo il metodo di sviluppo e non il codice in sè (che
come dice giustamente Ippopapero Acquatico mette a disposizione le classi
Custom).
Spero conveniate tutti che, da un punto di vista prettamente accademico,
l'approccio "droppa un componente, scrivi il codice, droppa un componente,
scrivi il codice, etc..." non è il massimo della OOP (molto spesso sono
caduto nel codice spaghetti).


 caduto nel codice spaghetti).
E' vero che l'approccio RAD, semplificando la vita a tutti, la
semplifica in modo particolare ai pigri, pero' nulla vieta di servirsene
bene o addirittura di usare la VCL senza l'approccio RAD.
Ciao,
Nicola

bene o addirittura di usare la VCL senza l'approccio RAD.
Esattissimo.

 caduto nel codice spaghetti).
Al 100%. E non solo da un punto di vista accademico ma proprio nella
praticaccia di tutti i giorni.
EMG

praticaccia di tutti i giorni.
Si', pero' il drag&drop dei componenti non c'entra proprio nulla con
la OOP.
Il problema e' riuscire ad usare queste classi nel modo corretto,
secondo le regole della OOP.
Il drag&drop equivale esclusivamente ad una dichiarazione di classi.

 Il drag&drop equivale esclusivamente ad una dichiarazione di classi.
Si, ma questa equivalenza non si estende a tutte le caratteristiche
dello sviluppo tradizionale.
EMG

dello sviluppo tradizionale.
Questa non l'ho capita.

 Questa non l'ho capita.
Le possibilità di intervento e modifica che hai con un tradizionale
editor di testo te le sogni quando hai a che fare con un ambiente
visuale. Per fortuna che a volte è possibile comunque editare il testo a
mano...
La mia esperienza visuale riguarda solamente il Visual Basic. Magari con
altri strumenti è tutto completamente diverso ma ci credo poco.
EMG

Enrico, 
mi sa che parli di uno strumento che non conosci; tieni conto innanzi
tutto che a differenza del VB sotto C++Builder ci sta per l'appunto il
C++. Il punto fondamentale e' che i componenti che ti mette a
disposizione BCB sono parte di un framework pienamente Object Oriented e
che con questi puoi fare quasi tutto quello che puoi fare con le normali
classi C++ (devi per forza allocarli dinamicamente e non puoi avere
eredita' multipla).
Il vantaggio che hai rispetto a MFC invece e' che questi componenti
hanno un livello di astrazione piu' alto, risparmiandoti di impelagarti
nei dettagli.
Dopo di che sta a te decidere se e come usarli: l'IDE genera delle
classi con gli scheletri dei metodi, alle quali puoi aggiungere altri
metodi o fare tutte le modifiche che vuoi. Come tutti i generatori di
codice ha qualche difettuccio, ma sono perfettamente gestibili.
Resta che l'architettura dell'applicazione devi impostarla bene tu,
cosi' come sei tu che devi adottare delle convenzioni ragionevoli
sull'uso del codice generato (ad esempio, non scrivere tutto il
programma dentro i metodi "OnButtonClick"...)
Ciao,
Nicola

Aggiungo una cosa: il vero motivo per cui mi piace C++Builder e' che le
interfacce mi annoiano: con BCB posso realizzare maschere decenti in
pochissimo tempo e concentrarmi sugli aspetti che mi interessano di
piu'.
Ciao,
Nicola

 banali.
Penso che non sia possibile giudicare un ambiente fin quando non lo si prova
a fondo. Detto questo bisogna considerare che BCB è essenzialmente un
compilatore c++ ed in quanto tale adatto (oltre ad essere un RAD) anche per
una programmazione hardcore. Il fatto che a corredo vi sia la VCL non
pregiudica affatto la scelta del tipo di approccio. Anzi possiamo
considerare l'ambiente come un *suggeritore* di codice c++, infatti
(esempio) ogni volta che piazzo un componenente in una form questi non fa
altro che dichiararlo nell'header apposito cosi' come farebbe un
programmatore nel momento in cui dichiarerebbe una classe. Il *sistema
ingestibile* non dipende affatto da come utilizzi l'ambiente ma da come
programmi e qui il BCB non puo' certo venirti in aiuto. Quindi lo sviluppo
visuale non ha *nessun* tipo di limitazioni ma semmai puo' essere
considerato un plus che aiuta il programmatore nel disegnare l'interfaccia.
Cerchiamo di non fare ti tutta l'erba un fascio. E' possibile che vi siano
ambienti che portano il programmatore verso un buco nero ma non è questo il
caso di BCB, ripeto occorre provarlo a fondo per rendersi conto che non
interferisce assolutamente con le scelte del programmatore che viene quindi
lasciato libero di sviluppare come vuole. Tirando le somme:
1) Compilatore c++ (abbastanza aderente allo standard);
2) Compilatore pascal (è possibile includere unit .pas);
3) Ambiente RAD;
4) Supporto per COM, CORBA, MFC, OWL.
Ho sviluppato parecchie applicazioni *non banali* e non mi sono trovato per
le mani mai nulla di ingestibile o di limitato e questo perche' ho sempre
cercato di sviluppare il codice nel modo migliore possibile.
Credo che la bilancia sia nettamente a favore di BCB, considerando che per
ottenere lo stesso tipo di produttivita' al VC++ va affiancato almeno VB
:-((
SISMA
P.S. Qualcuno in questo ng ha paragonato BCB a VB ma evidentemente non ha
provato entrambi a pari condizioni.



alla necessita' di creare le routine di gestione deglie eventi).
Un ambiente RAD, ancor piu` di un framework, impone un certo modo
di fare le cose. Non sempre tale visione e` pero` la migliore (o cmq 
sufficientemente valida), soprattutto in applicazioni di dimensioni non
banali, spesso ottenute gradualmente a partire da un nucleo minimo di
funzionalita` e sottoposte a continue revisioni ed affinamenti.
Cio` cmq non toglie che per certe cose un RAD possa essere una scelta
molto valida, ma cio` non e` generalizzabile.
Paolo
--------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
--------------------------------------------------

mano...
Con BC++B hai le stesse facilita' di intervento che con un
tradizionale editor di testo.

di fare le cose. 
Vorrei capire, sinceramente, fino a che punto BC++B impone questo


 mi sa che parli di uno strumento che non conosci;
Infatti l'ho detto: non lo conosco. La mia era una critica generale agli
ambienti di sviluppo visuali. Posso anche pensare che con il C++ il
discorso sia del tutto diverso (ma, come ho detto, ci credo poco). Resta
il fatto che in VB esistono i problemi legati al metodo di lavoro
visuale ai quali ho accennato.
EMG

 lasciato libero di sviluppare come vuole.
Ok, come ho già scritto, non conosco affatto il BCB. Da quello che mi
dite, allora l'ambiente visuale del VB non ha niente a che vedere con
quello del BCB. Meglio così...
EMG

 Forse e' ora che ti affacci al BC++B ;)
Terrň presente il consiglio ma ti confesso che non me la sento di
scrivere gestionali in C o C++.
EMG

"certo modo di fare le cose".
Premesso che il discorso era riferito in generale ai RAD, nel caso
di BCB ad esempio sei costretto a sottostare al concetto di form ed
al modo in cui sono gestiti. Ad esempio certi usi di variabili globali
che l'ambiente genera ed usa automaticamente, il modo in cui certe 
risorse sono gestite (vedi stringhe, BCB usa una sua implementazione,
non std::string... cio` rende il codice meno portabile di quanto non
potrebbe essere)...
In generale sorgono problemi quando la soluzione voluta x un certo 
problema non e` quella che il RAD genera. Questo perche`
normalmente un RAD e` pensato per certe applicazioni e in linea
ad una filosofia che puo` non essere sempre la migliore.
Questa mancanza di controllo spesso non e` accettabile
(tipicamente applicazioni che devono essere portate su
piattaforme diverse, appl. di dimensioni non banali...).


tradizionale editor di testo.
Ma se ti riduci a dover intervenire sul codice generato, tanto vale
ritornare ai vecchi wizzard, che pur non capaci di fare tutto facevano 
molto.


scrivere gestionali in C o C++.
Be', non ci crederai, ma con il supporto del Borland Database Engine (
o ancora meglio di ADO, si spera con la versione 5.0 di Builder!)
tirare su un'applicazione gestionale e' davvero uno scherzo
(connessioni a database di qualunque tipo, gestione delle tabelle,
query SQL, ...).
Provaci, ne vale la pena ;)

molto.
Dipende dai programmatori. Tutto sommato se riesci a produrre piu'
velocemente con i vecchi tool, non vedo perche' usare i nuovi ;)

potrebbe essere)...
Vero anche questo. 
A me non piace molto la forzata compatibilita' con Delphi (la classe
AnsiString nasce per supportare il tipo predefinito di Delphi) che fa
transitare le mancanze dell'Object Pascal verso il C++.
Io ho avuto grosse difficolta' nel realizzare dei componenti per i
quali sarebbe stato necessario usare l'ereditarieta' multipla, perche'
la gerarchia VCL non la supporta.
Be', pero' nessuno e' perfetto ;)

 (anche perche' lo standard gliene lascia piena liberta').
Speravo di star fuori almeno da _questa_ polemica, ma qui
proprio non riesco...: e` ASSURDO mettere sullo stesso piano
il fatto che (necessariamente!) ogni compilatore C++ dovra`
implementare tante cose "a modo suo" (in pieno rispetto
dello standard, che e` molto accurato nello specificare cosa
deve funzionare in dati modi predefiniti, cosa deve essere
definito dall'implementazione, cosa invece e` addirittura NON
definito), e la pessima prassi di violare o estendere lo standard
(di cui Borland e Microsoft si rendono spesso colpevoli).
Alex

(di cui Borland e Microsoft si rendono spesso colpevoli).
Estendere lo standard e' una *pessima* prassi ?
Se si ammette che lo standard possa ammettere implementazioni
specifiche degli aspetti su cui non puo' pronunciarsi, non si sta
forse ammettendo che lo standard e' estensibile ?
Non conosco i compilatori Microsoft, ma so che Borland non *viola* in
alcun modo lo standard del linguaggio.

 ...
... come lo GNU o l'HP AC++.
Direi che ogni compilatore ne e' colpevole.
Fausto

alcun modo lo standard del linguaggio.
Non credo fosse tanto questo il punto criticato da Alex Martelli, quanto
il modo in cui certi prodotti usano e spingono ad usare tali costrutti.
Cmq sia Borland che MS non implementano ancora del tutto correttamente
lo standard (almeno per quanto ho visto fino ad ora).


E` proprio per queste cose che a me in generale non piacciono i RAD.
In sostanza se per quello che fai tu BCB (o chi altri) va bene, meglio 
per te... ma non credere che siano la cura a tutti i mali (specie per
applicazioni medio-grandi o poco ordinarie).


applicazioni medio-grandi o poco ordinarie).
Nessuno credo possa pensare questo, di alcun prodotto di sviluppo.
Ma se e' per questo neanche programmare secondo lo standard e' la cura
a tutti i mali. Il principio : non bisogna giudicare cio' che non si
conosce. Non si puo' affermare che BCB non vada bene per applicazioni
medio-grandi, se non si e' mai provato a scrivere una riga di codice.
Io riesco a sviluppare applicazioni medio-grandi con BCB sfruttando
tutte le potenzialita' delle VCL. E' chiaro che ci si muove in un
terreno recintato, ma se in questo terreno ci trovo tutta la frutta
che mi serve, a che pro' scavalcarlo ?

lo standard (almeno per quanto ho visto fino ad ora).
Solo Borland e MS ? ;)
Non penso si possano muovere delle critiche nei confronti di queste
due case software, se lo standard non e' completamente supportato da
nessun compilatore in commercio.

che mi serve, a che pro' scavalcarlo ?
Appunto quello che ho sostenuto. Io scrivo (o meglio... ci provo) codice
il piu` possibile portabile e quindi ho bisogno del massimo controllo. 
Un RAD non mi offre il controllo di cui necessito, o meglio poiche` devo
rivedere ed aggiustare il codice, e` meglio che me lo scriva a mano, 
cosi`  ho maggiore coscienza di cio` che modifico.


nessun compilatore in commercio.
mai provato gcc. Non e` il massimo, ma supporta cosette come la
deduzione implicita dei parametri di un template, che non e` una
bestia rara, il BCB almeno fino alla 3 non supporta neppure i
member template (se non erro), non e` standard neppure
relativamente al namespace std... la lista potrebbe continuare.
Mi pare anche che il borland C++ compiler 5.5 (quello che danno gratis)
abbia ancora lacune in merito alla deduzione implicita dei parametri.
Neanche VC++ 6.0 mi pare si salvi da certe cose piuttosto grosse...
Considerato che BCB e VC++ si pagano, mentre gcc e` gratis, mi aspetteri
una situazione contraria...
E` chiaro poi che ognuno fa le sue scelte in base alle sue esigenze. 
Pero`...


tutte le potenzialita' delle VCL.
Per curiosità, cosa intendi per applicazioni medio-grandi? Puoi darmi un'idea
della dimensione e della complessità delle applicazioni che sviluppi, di quali
siano i maggiori problemi che devi affrontare in fase di design e in che modo
l'ambiente di sviluppo ti viene in contro?
Grazie
AB
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Andrea Baruzzo
Via Circonvallazione, 26
Muzzana del Turgnano (UD) - Italy
e-mail: 
andrea....@ud.nettuno.it
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Non esiste una OOP standard.
Lo so.
E' ovvio che mi sto riferendo al modo in cui lo standard implementi
l'oop.

cosi`  ho maggiore coscienza di cio` che modifico.
Ribadisco.
Probabilmente, a questo punto, e' una scelta sbagliata quella di usare
un RAD. Non si puo' giudicare l'utilita' di un ambiente
dall'adattabilita' o meno allo sviluppo di una certa applicazione.
Da qui, a dire che i RAD non servono a nulla ce ne vuole ;)

 una situazione contraria...
Scusa, ma hai appena detto che BC++B 5.5 e` gratis, quindi come
puoi qui, poche righe dopo, dire che invece si paga...?
Alex

 l'oop.
Questa affermazione non mi e` chiara.  Lo standard C++ fornisce
un tot di strumenti relativi all'object-oriented programming, che non
corrisponde appieno al tot di strumenti forniti invece da Object Pascal
(e usati in VCL) o altri linguaggi ancora (Java, Smalltalk, Python).
Alex

 Direi che ogni compilatore ne e' colpevole.
Mi pare che Comeau Computing e Kuck & Associates abbiano
invece evitato questa "tentazione" (e se ce ne sono due, penso
che ce ne possano essere anche altri) e che dunque la tua
affermazione (o ipotesi) sia falsa.
Alex

 alcun modo lo standard del linguaggio.
Ah, hanno finalmente tolto quell'erroraccio per cui l'#include
di vari header standard INQUINAVA lo spazio dei nomi riservato
all'utente con un tot di funzioni Borland supplettive?  Microsoft
corresse l'analogo errore ai tempi di VC++1, mi pare, cogliendo
l'occasione del cambiamento del nome di prodotto per introdurre
questa inevitabile incompatibilita` con il passato.
E cosa ritorna questa funzione in Borland C++...?
int i = 23;
int vediamo()
{
    for(int i=0; i<11; ++i)
        ;
    return i;
}
Anche qui, hanno rotto la compatibilita` col passato, e tornano
23 come standard comanda, o scelgono invece di tornare 11?
Solo i primi due esempi che vengono in mente...
Alex

Perche' ? 
E in Object Pascal e dubito rientri nello standard C++.


Da qui, a dire che i RAD non servono a nulla ce ne vuole ;)
E chi ha mai detto questo... ho espressamente detto che in alcuni casi
un RAD puo` andare bene, in altri no. Ti ho fatto un esempio di un caso
in cui un RAD a me non va bene, e tu ne fai altri in cui va bene.
In generale i RAD vanno bene per applicazioni molto standardizzate
(nel senso di rientrare in categorie ben precise) e non critiche
(sia come dimensioni che da altri punti di vista). Non e` una 
affermazione solo mia, e` un dato di fatto testimoniato da esperti
ben piu` autorevoli di me. Naturalmente non si parla semplicemente
di interfacce GUI.


puoi qui, poche righe dopo, dire che invece si paga...?
BCB sta per Borland C++ Builder, mentre l'altro e` il Borland C++
Compiler che e` un sottoinsieme di una qualche versione del builder
(la 4 penso, di sicuro non la 3) e che Borland distribuisce
gratuitamente per mostrare i passi in avanti relativamente alla
standardizzazione del suo compilatore. In effetti i passi in avanti ci
sono e sono molti, ma molto ancora rimane da fare.


23 come standard comanda, o scelgono invece di tornare 11?
Non esageriamo... su questi aspetti gia` il BC++ 5.02 si comportava a
norma di standard.


 che gcc e CAI abbiano implementato quasi totalmente lo standard
non conosco il CAI ma il gcc ha le sue estensioni... 
Fausto

 Alex
Entrambi si basano sullo stesso front end. Quindi si riducono a 1.
Il fatto che sia un'affermazione "falsa" non posso confermarlo 
fino a che non provo uno dei compilatori che si basano sul
front end della EDG.
Non comprendo comunque la tua "crociata" contro le estensioni dei
compilatori. Se non ricordo male tu sei un esperto (e ne hai dato
un'ampia dimostrazione su di un'altro newsgroup) di COM e dintorni.
Non credo tu possa utilizzare tale tecnologia senza estendere 
lo standard con implementazioni proprietarie. O sbaglio?
E poi cosa c'e' di male ad usare keyword quali "__published" 
o "__fastcall"?
Quando un programmatore utilizza un RAD sa a priori che potrebbe
scrivere codice C++ non standard. 
Fausto

non conosco il CAI ma il gcc ha le sue estensioni... 
Le estensioni, chi piu` chi meno, sono presenti in
ogni compilatore, cio` non toglie che certi prodotti
ti invoglino ad usarle piu` del necessario.
Ad ogni modo la tua osservazione non toglie che
su certe cose gcc sia piu` standard di altri.


scrivere codice C++ non standard. 
Molte volte capita di dover introdurre codice non standard (per un
motivo o un'altro), specie se si devono utilizzare certe risorse
proprie di una piattaforma, tuttavia se hai il pieno controllo puoi
riuscire ad isolare quei frammenti... un RAD non offre un controllo
completo (a meno di non rivedere a mano ogni istruzione) ed e`
(IMO) controproducente nei casi in cui e` importante la
portabilita` (o implementare una certa soluzione).
Personalmente non ritengo inutili i RAD, ci sono casi in cui possono
tornare comodi, tuttavia il loro funzionamento e` contemporaneamente
punto forte e debole... per i miei scopi piu` debole che forte.


 su certe cose gcc sia piu` standard di altri.
Puoi farmi un qualsiasi esempio in cui gcc sia "piu`
standard" del KAI (Kuck & Associates, "CAI" non so
cosa sia)?
Alex

 scrivere codice C++ non standard.
Su questo punto concordo pienamente con Paolo
Marotta: si tratta, per la maggioranza dei casi, di
un difetto dell'approccio RAD -- tra l'altro, un difetto
non giustificato da pure considerazioni tecniche.
RAD come il VisualAge C++ della IBM mostrano come
sia perfettamente fattibile, se lo si desidera, sviluppare
in RAD _senza_ nessun bisogno di violare lo standard.
Alex

 avanti.
Sei sicuro?
Ti vorrei ricordare che il BCB 3  aveva gia' l'implementazione 
standard delle std::string, quando ancora il GCC non sapeva 
cosa fossero. O meglio quando ancora implementava la prima 
versione delle string.
Non sono un fan dei RAD, ma li uso ove occorre.
Come hai scritto in un altro post, vanno bene per progetti 
standardizzati. 
Resta comunque il fatto che ove implementano lo standard, lo fanno
bene. Se poi lo estendono, e' il programmatore che decidera' se 
utilizzare o meno l'estensione.
Fausto

 in RAD _senza_ nessun bisogno di violare lo standard.
L'ho usato anni fa ma non mi sembrava cosi pulito.
Fausto

 L'ho usato anni fa ma non mi sembrava cosi pulito.
Di "pulizia", non so, ma l'IBM asserisce (da piu` release,
se ben ricordo) che tutto il codice generato e` standard.
Alex

 gratuito.
Intendevo in termini di sviluppo.
Fausto

cosa sia)?
Del KAI no, visto che non e` piu` standard del KAI (e non l'ho mai
detto), di BCB si... la libreria standard del BCB ha le sue grane,  e
non sono supportate le template member function e la deduzione implicita
dei parametri (in gcc almeno questi ultimi due aspetti pare funzionino).
La deduzione implicita dei parametri non e` supportata neanche da VC++
(fino alla 6), di altri problemi di VC++ ne so poco... sto cominciando
ad utilizzare per lavoro questo ambiente solo da poco tempo.


utilizzare o meno l'estensione.
Questo e` il punto... non sempre il programmatore puo` decidere (a meno 
di rivedere a mano tutto il codice...). Questo e` il punto su cui ho 
sempre fatto leva.


 ad utilizzare per lavoro questo ambiente solo da poco tempo.
In effetti e` importante capire, usando la programmazione generica,
cosa l'unificatore _dovrebbe_ dedurre (a norma di standard) e cosa
e` invece effettivamente _in grado_ di dedurre (nella praticaccia di
una data implementazione).  Considerando l'importanza del generic
programming, penso che sia questa la issue numero uno, oggi, in
termini di compatibilita` e potenza dei compilatori attuali.
Fra le tante doglianze che si possono avanzare (e che sia tu sia io
abbiamo recentemente avanzato su questo gruppo) contro la prassi
delle "estensioni" allo standard, e` che queste estensioni vengono
INVECE dell'importante lavoro necessario per migliorare la aderenza
allo standard.  Borland, Microsoft, gcc, tutti hanno speso tempo ed
energie per queste sciocchezze INVECE che per cose fondamentali
(come i namespace nel caso di gcc, o i template nel caso di Borland
e Microsoft), mentre KAI e Comeau mostrano quanto meglio si sarebbe
potuto fare usando le stesse energie nella giusta direzione.
Penso (spero) che si tratti di "un transitorio", ma e` un transitorio
che sta diventando molto, TROPPO lungo...
Alex

Aggiungerei che C++Builder 3.0 ha due anni (e due release) di eta'. Le
funzioni membro template erano gia' supportate in BCB 4.0 .
Mi pare che a questa discussione sfugga un punto fondamentale,
soprattutto ai paladini dello standard: Nessuno standard di linguaggio
coprira' mai le peculiarita' delle diverse piattaforme. E' gia' stato
menzionato ad esempio il problema delle diverse calling convention
supportate dalla piattaforma Intel (e cara grazia che ci hanno tolto dai
piedi i modelli di memoria...). Neanche l'SDK aderisce allo standard.
L'unica speranza e' trovare un framework di terze parti che mascheri
queste difformita', ma in questo caso ci si trova legati ad un prodotto
specifico e da un punto di vista pratico francamente non so se sia
meglio una libreria proprietaria la cui interfaccia aderisce allo
standard o l'uso di estensioni al linguaggio, peraltro previste dallo
standard stesso. Se non altro le keyword che iniziano con "__" sono piu'
facili da individuare...
Con questo non voglio sottovalutare l'importanza dell'esistenza di uno
standard per il linguaggio, per non parlare della libreria che lo
accompagna. Pero' i difensori a spada tratta dello standard si ricordino
della fine fatta dal Pascal, che se sopravvive in qualche forma con una
certa diffusione lo si deve esclusivamente all'esistenza di Delphi...
Ciao,
Nicola

 potuto fare usando le stesse energie nella giusta direzione.
Oh, Alex, Microsoft degli standard se ne frega abbastanza e questo mi
pare ampiamente dimostrato dal suo atteggiamento sia in generale che nel
caso specifico del C++; per quanto riguarda Borland invece quelle che
chiami sciocchezze sono l'unica speranza di sopravvivenza commerciale
del C++Builder e sono sicuro che te ne rendi conto anche tu. Se non
altro loro un minimo di sforzo nell'avvicinarsi allo standard lo fanno,
maggiore ad esempio di quello di Sun, a giudicare dalle note di
accompagnamento della loro beta (di Sun, non di Borland).
Per quanto riguarda KAI e Comeau, ho un dubbio: permettono di realizzare
interfaccie grafiche in ambiente Windows? Se si, con che libreria?
Ciao,
Nicola

 Se si, con che libreria?
Utilizzando le Qt e' possibile.  Ovviamente la Troll fa lo stesso 
discorso della Microsoft cioe' se ne frega dello standard (vedi 
le keyword "signal", "slot" ed "emit").
Tra l'altro la Troll ha dimostrato ampiamente che estendendo il C++
e creando librerie Cross-Platform si puo' ottenere un OTTIMO prodotto.
Fausto

 interfaccie grafiche in ambiente Windows? Se si, con che libreria?
Non vedo perche` un qualsiasi compilatore C++, usato su e
per Windows, non dovrebbe permettere di implementare la
convenzione di chiamata standard di Windows ("WINAPI"
aka "STDCALL" etc).  Non occorre altro che questo per
potere accedere alle API e quindi realizzare qualsiasi cosa
sia fattibile su Windows.
Vi sono vari framework C++ open-source che rivestono le
API a vari livelli di astrazione e portabilita`, e non dubito che
parecchi di essi siano del tutto usabili con i compilatori teste`
nominati, come lo sono con gcc eccetera.
Alex

 certa diffusione lo si deve esclusivamente all'esistenza di Delphi...
Gia`, uno standard che nessuno ha mai implementato senza
enormi estensioni perche`, rispettandolo appieno, potevi forse
scrivevi "ciao mondo" (al massimo, se ti andava bene).  Gran
bell'esempio.  Secondo te lo standard C++ e` cosi` restrittivo?
Mi spieghi, salvo lo specifico caso del S.E.H che ho gia` portato,
cosa NON si puo` fare (e fare BENE) SENZA estensioni...?!
Alex

>Scusa la mia piu' completa ignoranza ma cosa significa RAD e hardcore ?
RAD = Raoid Access Development, ed indica la creazione di programmi in
rapidità senza troppe complicazioni. Con hardcore _penso_ poiché non
sono sicuro, che si intenda lo sviluppo lungo direttamente al cuore
del programma.
Anche se io penso che VCL può andare bene non solo per il RAD...
DGP85

 pragmatiche che #pragma e` stato inventato per coprire?!
Potremmo utilizzare il pragma per il packing delle strutture,
pragmiamo per specificare la convenzione di chiamata,
pragmiamo per ottimizzare,
pragmiamo per definire tonnellate di variabili d'ambiente,
pragmiamo per ... perche' no  anche per fare un caffe',
pragmiamo ovunque. 
Tanto la direttiva pragma e' standard, poi poco importa 
il significato, oppure che il codice diventi illeggibile.
Fausto

che sta diventando molto, TROPPO lungo...
Purtroppo la tendenza e` quella di acquisire clienti e fare in modo
che non possano andarsene. Questo secondo obiettivo e spesso ottenuto
piu` legandoti ad una certa piattaforma che conquistandoti con le
caratteristiche del prodotto.
Anche per questo mi sforzo di scrivere codice standard ed il meno
dipendente da piattaforme. Ho subito una volta e quella volta gli sforzi
mi sono costati 3 volte piu` del necessario perche` sono stato legato
anche ad alcuni odiosi bug del prodotto.


le keyword "signal", "slot" ed "emit").
Un momento... Qt e` una libreria compilabile da un qualsiasi
compilatore standard? Se si il tuo ragionamento e` errato perche`
Qt non farebbe ricorso ad estensioni non standard del linguaggio.


certa diffusione lo si deve esclusivamente all'esistenza di Delphi...
Anche il C mi pare avesse sostanzialmente uno standard, non mi
pare abbia fatto la fine del pascal.
Credo che la fine del pascal sia legata anche ad altri motivi...


 
Errore. Per gestire le keyword fa uso di un precompilatore che
le traduce in C++ standard. Quindi sono estensioni al linguaggio
a tutti gli effetti.
Fausto

il significato, oppure che il codice diventi illeggibile.
Secondo me tu parti dal concetto (sempre IMO) errato che
sia necessari introdurre molte features proprietarie per
riuscire a fare qualcosa di valido. Io sono convinto che questo
sia in gran parte merito di certe politiche di note software house, 
perche` nella mia (pur limitata) esperienza molto (per non dire quasi 
mai) raramente ho dovuto utilizzare estensioni non standard
di un linguaggio (notare il termine "linguaggio"). Generalmente
me la cavo egreggiamente e senza contorsionismi con le
cose standard.
Nel caso specifico, sono convinto che lo standard del C++, lungi
dall'essere perfetto, sia piu` che sufficiente nel 95% del codice
di una generica applicazione e non c'e` motivo in quei casi
di allontanarsi dallo standard. Non costa nulla, e il vantaggio e`
che se improvvisamente sorge la necessita` di migrare l'applicazione,
un buon design minimizza i costi.


 proprietarie per riuscire a fare qualcosa di valido. 
Non mi sembra di aver detto questo. 
Dico solo che se un compilatore (o libreria) ha una feature in piu'
(non molte come tu sostieni) oltre allo standard, con la quale 
si ottiene un vantaggio in termini di sviluppo/manutenzione del 
codice, non vedo il motivo per non utilizzarla.
Sicuramente se rimane nello standard e meglio.
Fausto

a tutti gli effetti.
Allora non sono keyword aggiunte da un compilatore C++ al
linguaggio... sono piu` una specie di macro fornite dalla stessa
libreria...
In ogni caso dopo questa precompilazione, le Qt 
sono compilabili da un qualsiasi compilatore standard...
E` molto diverso dall'avere arricchito la sintassi del C++ con nuovi
costrutti che non necessariamente hai su altre piattaforme.
Nel caso di Qt fa tutto parte della libreria e se essa e` portabile
(riducibile a C++ standard) non hai problemi.


 
Direi di no, in quanto senza il precompilatore
della "Troll" (chiamato "Meta Object Compiler") sarebbe impossibile 
dare in pasto il codice ad uno qualsiasi dei compilatori sul mercato.
Quindi e' un'estensione al linguaggio a tutti gli effetti.
Che l'estensione risieda in una libreria o in un compilatore, 
comunque occorre un'eseguibile che la interpreti. Ne convieni????
Fausto

comunque occorre un'eseguibile che la interpreti. Ne convieni????
Dato che quell'eseguibile trasforma il tuo codice Qt in C++
standard e dato che sicuramente lo ricevi insieme alla
libreria, direi che cio` nulla toglie alla portabilita` della libreria.
Quando hai fatto tutto, preprocessi il tuo lavoro ed hai raggiunto
l'obiettivo della portabilita`.
La situazione e` molto diversa dai casi in cui non ti viene
offerto alcuno strumento di traduzione come normalmente
accade. In questi casi l'unico modo di rendere il codice
portabile e` intervenire manualmente (con molta fatica
e grande dispendio di tempo) e sempre che sia praticabile.
D'altronde lo standard non dice nulla circa il come va ottenuto
un codice che lo rispetti... Sia esso scritto totalmente a
mano o con l'ausilio di strumenti automatici (RAD, preprocessori...),
ti dice semplicemente che se ad un certo punto rispetti certe regole (e
le rispetta anche il tuo compilatore) non hai problemi. 
Inoltre e` lo standard che ti permette di capire quando un errore e`
veramente tale e non un bug dello strumento che usi. Altrimenti
ogni cosa potrebbe essere considerata come feature!


 ogni cosa potrebbe essere considerata come feature!
Messa cosi, non posso che darti ragione. 
Fausto