Newsgroup: it.comp.lang.c++
Titolo: Microsoft o Borland

devo comprare un c++ quale mi consigliate? io sono propenso un po' di
più x quello borland.

 wrote in message
39201785...@interfree.it...


Anche io.
Ciao
  Roberto.


 programmazione ti consiglio vivamente il Visual.
Salvo che se vuoi imparare il "vero" C++, Borland e' piu' aderente allo
standard di Microsoft.
Ciao,
Nicola

più x quello borland.
Borland Builder 3 è gratuito (lo trovi in edicola, o altrimenti
chiedimelo e te lo invio). L'attuale versione è la 5, che
effettivamente ha diverse cosette in più che sono molto carine: valuta
tu se vale la pena di spendere dei soldi per averle; io ho optato per
la versione gratuita, e mi sto trovando veramente bene.
Conosco anche il VisualC++, che utilizzo controvoglia perchè mi è
richiesto sul lavoro. Tieni conto che non sono un grande esperto di
C++, e quello che dico è molto opinabile (anche se lo esprimo con
molto pathos :-), ma se vuoi un caldo consiglio scappa da VisualC++.
VisualC++, essendo prodotta dalla stessa casa che produce il sistema,
le librerie di sistema e praticamente tutte le tecnologie utilizzate
in Windows (COM, COM+, ActiveX e via discorrendo) è *ovviamente*
sempre pronto ed aggiornato per sfruttarle al meglio. Inoltre, gli
eseguibili che riesci a produrre sono estremamente veloci e compatti
(non quanto riesce a fare gcc, evviva Linux, tiè! ;-)
Il prezzo di tutto questo?
Un ambiente semplicemente vergognoso: il nome Visual è fuorviante. In
VisualC++ non c'è niente di "visuale", per lo meno non nel senso
inteso dagli altri produttori. Adesso, non voglio (e non riuscirei) ad
entrare in dettagli tecnici: cerco solo di farti una breve descrizione
di quello che incontreresti, con Borland e con Microsoft, durante il
periodo di apprendimento (poi, può darsi che per un programmatore
esperto e navigato il discorso sia diverso).
Il concetto di "visuale" per Microsoft è molto distorto. Se voglio
aggiungere una variabile private alla classe MyClass, con Borland apro
MyClass.h e aggiungo nella sezione private: la mia
int i;
Su Visual C++ c'è una fantastica utility! Clicco con il mouse su
MyClass.h e seleziono Add member variable, si apre una utilissima
finestrella con dei campi da riempire: il tipo della variabile, il
nome della variabile e una scelta tra public, private e protected.
Uno strumento simile *non è visuale*! E' solo stupido: è ovvio che se
devo definire 20 variabili, dopo un pochino mi rendo conto che vado
molto più velocemente scrivendole a mano!
Insegnando l'uso di VisualC++, mi sono reso conto che strumenti
"visuali" come questo rischiano di nascondere il più possibile il
codice al punto che lo studente ha delle grosse difficoltà,
inizialmente, a comprendere *quali aggiunte al codice* avvengano
eseguendo questi wizard.
Non c'è niente di male nell'uso di strumenti di automazione che
scrivono il codice al posto tuo: ma devono essere intelligenti,
offrirti un'interfaccia object oriented e risultare *effettivamente*
delle scorciatoie.  Microsoft definisce il suo prodotto Visual perchè,
per fare alcune operazioni elementari, facilmente eseguibili scrivendo
del semplice codice, viene proposta un'interfaccia a finestre, che,
bada bene!, richiede l'immissione della stessa identica quantità di
informazioni: vale a dire, non contiene alcuna operazione che
automatizzi la scrittura del codice, non accelera le operazioni.
Le MFC poi, sono una delle librerie più confuse, contorte e meno
eleganti che la storia dell'informatica abbia mai conosciuto.
Ovviamente, essendo tutto Windows basato sulle MFC ed essendo
VisualC++ tutto orientato all'uso delle stesse, VisualC++ si rivela
estremamente efficiente nello sfruttarle. Ma attenzione: questo non
significa che la scrittura del codice sia più agevole con VisualC++.
Le MFC hanno un'interfaccia dove il concetto di object oriented è
stato completamente travisato. L'aspetto più interessante dell'OO, da
un punto di vista prettamente pratico è la sensazione di ordine,
coerenza, chiarezza e leggibilità del codice che ne risulta.
Quando con Borland (che usa le VCL) aggiungo un dialogo per la
richiesta di un file, ho immediatamente visibili a schermo le
Proprietà dell'oggetto e gli Eventi associati. Premendo F1 posso avere
la lista dei Metodi utilizzabili dall'oggetto, cioè delle funzioni che
posso richiamare per operare sull'oggetto.
Così, se voglio che non vengano mostrati i file nascosti, imposterò la
proprietà corrispondente con un codice simile a
filedialog->Attributes->HideReadOnly=true;
(i nomi non corrispondono, non li ricordo a mente e adesso non ho un
Builder da aprire)
Nelle MFC usate da VisualC++, la classe CFileDialog prevede che nel
momento di richiamarne il costruttore si utilizzi una sitassi
concettualmente simile a quella di VCL:
static char BASED_CODE Filtro[]="File bitmap (*.bmp)|*.bmp||";
CFileDialog m_filedialog(TRUE, ".bmp", m_bitmap, OFN_HIDEREADONLY,
Filtro);
Al di la' della vergognosa poca leggibilità del codice, VisualC++ non
offre nessuno strumento visuale per venire incontro alla scrittura di
questo codice.
Con il Builder, invece, clicco sull'oggetto del filedialog e, nella
finestrella che elenca tutte le proprietà, con un clic posso andare a
settare la voce Attributes->HideReadOnly. Semplice, no?
A Microsoft forse, invece di aggiungere l'inutile ClassWizard,
avrebbero dovuto aggiungere la possibilità di accedere, per ogni
oggetto, a tutte le sue proprietà, no?
Non solo! Supponi che tu abbia sulla finestra un testo, che l'utente
può editare. Da programma vuoi accedere al contenuto di questo testo. 
Con Builder, rispondendo perfettamente alla filosofia della
programmazione ad oggetti, si tratterà di accedere ad un membro della
classe dell'oggetto. Quindi, qualcosa di simile a
Edit->Text;
VisualC++, invece, adotta un sistema che ti fa veramente capire come
alla Microsoft non abbiano capito cosa sia la programmazione orientata
agli oggetti.  Devi creare, in aggiunta all'oggetto, una variabile,
mettiamo si chiami Text, che assocerai all'oggetto. Poi con la
chiamata
UpdateData(TRUE)
fai in modo che il testo contenuto nell'oggetto venga copiato nella
variabile associata ad esso.
Adesso, accedendo alla variabile
Text
potrai accedere al testo.
Questo sistema è semplicemente stupido: il testo dell'oggetto dovrebbe
essere una caratteristica interna dell'oggetto, memorizzata in una
variabile pubblica in modo che io da fuori possa leggerla con
Oggetto->Variabile
VisualC++ mi costringe a memorizzare questo testo in una variabile che
non è *incapsulata* dentro l'oggetto, ma è esterna (quindi, si mescola
con tutte le altre variabili associate a tutti gli altri oggetti, e
alle variabili del mio programma). Su Builder, se ho tre oggetti
contenenti ognuno un testo, so che per ognuno di essi il testo è
memorizzato *sempre* nel campo Text.
Oggetto1->Text
Oggetto2->Text
Oggetto3->Text
Con VisualC++, invece, devo ricordarmi che il testo di Oggetto1 è
asociato a m_text1, il testo di Oggetto2 è asociato a m_text2, il
testo di Oggetto2 è asociato a m_text2 (e, naturalmente, non sempre è
possibile fare delle associazioni così intuitive). Non solo,
UpdateData(TRUE) copia TUTTI i testi nelle rispettive variabili, anche
se io volevo leggere UN solo testo. 
Alla faccia della programmazione orientata agli oggetti! Se essere
costretto ad usare questa logica così contorta ed inelegante significa
"entrare nei particolari della programmazione", in modo da poter
"controllare ogni singolo aspetto del proprio programma", ok,
preferisco di gran lunga una libreria più "automatizzata" come la VCL,
ma che mi offra una vera interfaccia OO, elegante, coerente,
intuitiva, leggibile.
Se davvero vuoi controllare ogni singola riga del tuo programma,
allora non vale la pena di usare le MFC, che sono un'accozzaglia di
spazzatura Microsoft: vale molto pià la pena, a questo punto,
programmare su Linux, compilando con gcc ed usando vere librerie OO
come la QT o librerie eleganti e semplici come la GTK.
Ma gli esempi si sprecherebbero. Io,piuttosto, se fossi in te, darei
un'occhiata alla documentazione che avresti a disposizione. Da una
parte una guida in linea chiara ed efficiente, che puoi consultare
tutta dall'installato su hard disk, con gli strumenti di ricerca
standard della Guida di Windows. Per ogni oggetto ti viene mostrata
una descrizione sommaria, la gerarchia rispetto agli altri oggetti, la
lista dei metodi, delle proprietà e degli eventi, suddivisi in
funzione della classe da cui discendono. Cliccando su ogni voce, hai
una descrizione della funzione, la sintassi, a volte un esempio, e i
rimandi ad altre voci.
Ti invito a guardarti le famose MSDN, la guida in linea di VisualC++.
Intanto, nonostante tu la installi tutta sull'hard disk (sono 2 CD,
ovviamente memorizzati in formato proprietario e non consultabili se
non le installi), viene chiesto continuamente l'inserimento di uno dei
2 CD. Una palla esagerata.
Poi, le ricerche restituiscono sempre centinaia di voci, cliccando con
F1 su un oggetto raramente ti ritrovi la pagina che desideravi. Le
pagine di documentazione sulle MFC, poi, sono ridicole: le
informazioni importanti sono mescolate all'interno di discorsi lunghi
e prolissi. Manca un'organizzazione che permetta una visione sommaria
e d'insieme dell'argomento e che permetta di navigare all'interno
delle informazioni scendendo nei particolari solo quando lo si
desidera. Quando usi le MSDN e cerchi un argomento specifico,
rassegnati a dover perdere del tempo per cercare tra la masnada di
roba la riga che ti interessa. Io non so perchè, ma quando ho bisogno
di una semplice e imemediata informazione, con Builder impiego i pochi
secondi necessari ad individuare la sezione della guida e i pochi
secondi per leggere lo stretto necessaro di cui ho bisogno; con MSDN
mi ritrovo sempre a passare dei quarti d'ora a leggere paginate che
non mi interessano nella speranza di trovare almeno un accenno a
quello che mi serve.
Naturalmente, non ci sbagliamo, se programmi in ambiente Windows a
livelli professionali, le MSDN sono praticamente indispensabili,
purtroppo.
VisualC++, insomma, di visuale ha il fatto di usare dei Wizard basati
su finestre che "aiutano" nella scrittura di codice elementare
(aggiungere una variabile membro, aggiungere un file al progetto), ma
non offre assolutamente niente per rendere umana ed intuitiva la
gestione degli elementi veramente visuali.
Io ti consiglio, se vuoi *divertirti* imparando il C++, di usare il
Builder, se sei uno smanettone di usare Linux e solo se ti viene
richiesto esplicitamente di rassegnarti all'uso di VisualC++.
-- 
Topoldo  
www.pianetalinux.com
(Grazie a Dio, sono ateo)

 richiesto esplicitamente di rassegnarti all'uso di VisualC++.
Forse e' meglio se prova entrambi. E poi scelga quello con la quale si
trova meglio. 
Fausto

La filosofia di utilizzare il codice, contrariamente ad usare l'effetto, č
errata:
noi non siamo piů nell'era di questo tipo di filosofia...
Ma siamo arrivati nell'era del digitale (č ben differente dal "fare cose
mediante il computer")
FarSee

Tools di sviluppo.
Mi basterebbe un CD di MSDN in meno e i sorgenti di WIndows e MFC
liberi. Allora si inizierebbe a parlare di serietà di documentazione.


 liberi. Allora si inizierebbe a parlare di serietà di documentazione.
I sorgenti di MFC li hai, inclusi in VC++.  In che modo sarebbe 'piu`
seria la documentazione' se cambiasse la licenza d'uso degli stessi,
identici sorgenti...?
Alex

I sorgenti di MFC li hai, inclusi in VC++. 
Ehm.. Liberi (=free) nel senso di GNU/GPL. E non mi pare che le MFC lo
siano.


 siano.
Sei liberissimo di estendere/modificare/cancellare le MFC 
che hai installato a tuo rischio e pericolo (come del resto tutto il 
software public domain). Se non ti piace come viene implementata la 
gestione del REPLECTION messagging puoi cambiarla a tuo rischio e
pericolo (come nel software public domain). 
Se non ti piace come viene gestito il RETURN su una CEdit puoi 
cambiarla (a tuo rischio e pericolo come nel software public domain).
etc etc etc...
Non sono un fan delle MFC (anzi le odio con tutto il cuore), ma quello 
che hai scritto e' falso.
Mi sa che tu sia animato da un po' troppa faziosita' verso Linux.
Ti ricordo che stai scrivendo su di un news group ove piu' della meta'
della gente ha lavorato o lavora costantemente sotto UNIX in generale
e Linux in particolare.
In particolare uso tutti i giorni HPUX, Win32 e Linux. Ora mi spieghi 
dov'e' il vantaggio ad utilizzare uno Unix/Linux rispetto a Win32?
Fausto

 Allora si inizierebbe a parlare di serietà di documentazione.
Lascimo stare tale affermazione. Non vale la pena commentarla. 
Fausto

 siano.
Non lo sono, come non lo sono quelli di Perl, di Python, di BSD, di
VCL, ... -- ciascuno ha licenze d'uso diverse da quella GNU.  Alcune
le definirei "liberissime", altre no, ma che c'entra la licenza d'uso
dei sorgenti con la "serieta` della documentazione" di ciascuno?!
La tua affermazione era: la serieta` della documentazione e` in
qualche modo funzione della "liberta`" dei sorgenti delle MFC,
cioe` dei dettagli legali della licenza d'uso del copyright.
Non mi pare che tu stia in alcun modo difendendo questa affermazione,
che, in effetti, mi pare sostanzialmente indifendibile.  Il *riuso*,
il *porting*, le *modifiche*, ai sorgenti di un prodotto, dipendono
dalla licenza d'uso di questi sorgenti; la *documentazione* no -- se
i sorgenti puoi leggerli e studiarli (possibilissimo esattamente
nello stesso modo per tutti i prodotti suddetti e tanti altri),
perche` mai dovrebbe soffrire la "serieta` della documentazione"
a seconda di quali modifiche o riusi tu possa apportare ai sorgenti?!
Tanto piu` quando si parla, come si faceva in quel contesto, di
documentazione 'in-linea', piu` o meno 'inclusa' nel prodotto.  Ma
anche come libri 'di terze parti' (tipo 'MFC Internals', ecc), non
e` che la licenza d'uso con cui i sorgenti sono comunque resi
disponibili possa minimamente inficiare la "serieta`" di questi
libri, no?!
Alex

dov'e' il vantaggio ad utilizzare uno Unix/Linux rispetto a Win32?
Beh, un po' lunghetto come discorso, no? Forse è meglio continuarlo su
it.comp.os.dibattiti. A proposito dei commenti sui FOF stiamo
discutendo anche di questo aspetto. Lasciamo solo dire che,
caratteristiche tecniche a parte, quello che fa la *vera* differenza
tra Win e Hurd, Linux, Minix etc è proprio la licenza GNU/GPL.
Probabilmente alcuni (me compreso) stanno dando un peso forse
eccessivo a questo aspetto filosofico dell'informatica, ma sono
convinto che *questa* è la vera differenza. Se ti va, ne parliamo con
piacere su un ng più appropiato.


libri, no?!
Certo.Stavamo discutendo se la documentazione di Borland Builder fosse
più o meno agevole ed utile di quella MSDN. Non mi pare di aver
improntato il discorso sulla licenza dei due prodotti (tra l'altro, è
più "libertina" quella Microsoft.. Mi sarei tirato la zappa sui
piedi). La mia frase (a questo punto, infelice) era una risposta a
quello che mi diceva Fausto: che la mole delle informazioni (e la
conseguente sensazione di spaesamento e confusione che si riceve
quando si fanno ricerche su MSDN) è inevitabile perchè se si vogliono
avere tante informazioni su Windows e sui tool di sviluppo,
necessariamente si deve avere tanto materiale di documentazione. Io ho
semplicemente detto che avrei preferito meno documentazione
unilaterale e più apertura dell'ambiente. Non mi fate passare come
quello che dice che MSDN si leggono male perchè non sono GPL!


Lascimo stare tale affermazione. Non vale la pena commentarla. 
Beh, non vorrei che il clima diventasse troppo teso per colpa di
divergenze di opinione. Mi piace lurkare su questo ng e (raramente)
intervenire, e mi spiacerebbe di discutere per delle questioni
scatenate da due righe di post :-) Se ci vogliamo scannare
(amichevolmente) su questo, andiamo su un ng dove non sembri che
voglia venire a rompervi le scatole con questioni barbose sulla
filosofia GNU, ok?


 quello che dice che MSDN si leggono male perchč non sono GPL!
Quello che tu preferisci sono naturalmente fatti tuoi.  Asserire
che non si puo` parlare di serieta` di documentazione in mancanza
di "sorgenti liberi" e` invece un'affermazione gravissima, sulla cui
assurdita` mi sembra di capire che anche tu concordi, pur avendola
tu originata (e non mi sembra di avertela ancora vista ripudiare
appieno).  Se io preferisco il gelato alla cioccolata a quello alla
fragola, non per questo affermo che non si puo` parlare di serieta`
di documentazione relativamente alle case dolciarie che producono
invece gelato alla fragola.
Alex

 filosofia GNU, ok?
Non ho nulla contro la filosofia di Stallman eccetto il fatto
che e` ampiamente superata (da un pezzo) dall'attuale movimento
"Open Source": licenze come quelle di Python e Perl secondo me
sono (oltre che in buona parte il presente) anche sicuramente
il futuro.
Ma tutto cio` nulla toglie alla serieta` della documentazione
dell'uno o dell'altro prodotto, ed e` questa specifica asserzione
che mi ha urtato (e non solo me, vedo) portandomi quindi a
ribattere puntualmente.
Alex

 tra Win e Hurd, Linux, Minix etc è proprio la licenza GNU/GPL.
Quindi BSD, che non usa GPL, e` dalla stessa parte della barricata
di Windows, secondo te?  Mi sembra che tu dia eccessivo peso ai
dettagli delle condizioni d'uso rispetto che non alla effettiva
disponibilita` dei sorgenti.
I sorgenti di MFC sono disponibili, sia pure con licenza d'uso
ben diversa da GPL (cosi` come e` ben diversa da GPL, in modi
del tutto diversi, la licenza BSD): considero dunque assurdo
pensare che questa licenza modifichi in qualche modo la "serieta`
della documentazione", e profondamente errato accomunare come tu
hai fatto codice i cui sorgenti non sono disponibili "praticamente
a nessuno" (Windows) con codice i cui sorgenti sono pubblicati,
amplissimamente disponibili (non solo con prodotti Microsoft: non
li ridistribuisce anche Borland in alcune edizioni del suo C++?),
e ottimamente documentati da eccellenti libri di terze parti come
"MFC Internals" (non dispiacerebbe affatto avere libri analoghi
su software come l'interprete Perl, ad esempio).
Alex

 Un tempo c'erano le ZINC, le OWL, le MFC, le XWT, le ZAPP ed altre.
OWL esiste ancora!!! Non ha più il supporto della Borland, ma sta per
diventare un progetto freeware...
Lunga vita ad OWL
--
Luigi Bianchi
http://www.luigibianchi.com

eccole, ma non lamentarti poi che le informazioni sono tante.
Affatto. Ma mi lamento che sono male organizzate. Fai tu, quando ho
avuto bisogno di cercare info sulle MSDN ho constatato un ecessivo
tempo speso nella lettura di informazioni che *non* desideravo, mentre
sono sempre riuscito a "navigare" meglio con altre documentazioni. 


 sono sempre riuscito a "navigare" meglio con altre documentazioni.
Io no.  Grazie a Index e Search e ai subset di selezione, trovo
la navigazione in MSDN molto piu` agevole di quella in tutti gli
altri schemi di documentazione che ho usato, e sono proprio tanti,
*COMPRESI*, al 100%, i man (di Unix, Linux, ecc) e gli gnu-info.
E non e` questione di abitudine.  Dopo dieci anni e oltre di
"frughe" su man, gnuinfo, e compagnia, e sei mesi di esperienza
di MSDN, trovavo gia` molto piu` proficuo usare quest'ultima.
Bisogna dire che io sono una persona molto atipica perche` la
prima cosa che faccio con un nuovo strumento e` *STUDIARLO, se
appena appena esso include un minimo di documentazione.  L'approccio
quadratico medio sembra invece essere quello di tuffarcisi, piedi
in avanti e naso tappato, poi lamentarsi di quel che non si e`
imparato a fare (magari su it.comp.lang.c++).  Mezz'ora passata
a studiare l'help di MSDN Library mi ha quindi reso un "super
esperto" di questo tema, apparentemente (e ci credo, visto che
l'utente medio di tempo di studio ha speso circa zero secondi,
salvo poi naturalmente sprecarne molto, molto di piu` in inutili
tentativi a vuoto e lamentele varie assortite).
Alex