Newsgroup: it.comp.lang.c++
Titolo: A proposito di RAD e non...

<HTML>
Salve a tutti ,
<P>chi vi scrive &eacute; un aspirante programmatore nel linguaggio
<BR>C++.
<BR>Ho letto alcuni messaggi di questi giorni circa ambienti RAD
<BR>e non (tra cui ricordo che esite anche l'Optima++
<BR>con compilatore Watcom 11.0 come ambiente RAD...).
<BR>Traggo le seguento conclusioni:
<BR>1)Che nessuno mi venga a dire cose del genere...
<BR>>Se conosci bene Visual C++ ci metti lo stesso tempo a sviluppare
<BR>>un'applicazione che fa le stesse cose che fa una scritta in Visual
Basic
<BR>> o Delphi, perintenderci.
<BR>Ebbene NON E' VERO!!!!
<BR>Io sto studiando anche (solo a livello di curiosit&agrave;) Visual
C++ ed &eacute;
<BR>veramente una purga!
<BR>Le richieste intellettuali e di tempo(soprattutto)sono da panico, e
<BR>poi per conoscere BENE le MFC ( di cui penso ce ne
<BR>siano veramente pochi al mondo che te le smanettino BENE tutte...)
&eacute;
<BR>meglio preventivare almeno 1 o forse 2 anni di smanettamento intenso.
<BR>NON E' AFFATTO UN AMBIENTE PER COMINCIARE COL C++ SOTTO<BR>
WINDOWS!!E' un ambiente a mio avviso per pochi addetti ai lavori....
<BR>2)Anche i RAD non scherzano come complessit&agrave; per&ograve; quelli
<BR>che ho potuto testare alla meno peggio (vedi Builder C++,di mia prossima
<BR>adozione...) ti fanno respirare un p&ograve; di pi&ugrave;.Nel caso
del Builder C++ o
<BR>l'Optima++(scusate ma ora si chiama Power++ ed &eacute; della Powersoft)
<BR>fate conto di avere un Visual Basic con linguaggio C++,anche se di
<BR>quest'ultimo ambiente hanno ben poco a che fare.<BR>
Per&ograve; indubbiamente per sviluppare sono MOLTO pi&ugrave; veloci del
VC++,
<BR>che&nbsp; quest'ultimo&nbsp; &eacute; a mio avviso pi&ugrave; Windows95/NT
oriented.
<BR>3)Alla fine poi vedo che ognuno dice la sua come me d'altro canto,
<BR>ma un punto FERMO rimane:
<BR>il C++ &eacute; un linguaggio con i cosiddetti,&eacute; un linguaggio
serio,&eacute; un
<BR>linguaggio complesso ma soprattutto &eacute; un linguaggio cha VA STUDIATO,
<BR>prima di addottare anche il + fantasmagorico dei compilatori oggi
<BR>disponibili sul mercato!!Perch&eacute;?
<BR>Perch&eacute; se non sai un picchio di C/C++ hai voglia di saper far
funzionare
<BR>BENE i programmi (prima) e i compilatori(poi)!!
<BR>Ok, detta la mia, vi saluto e vi auguro buone feste fra ereditariet&agrave;,
<BR>information hiding,funzioni virtuali e polimorfismi vari!
<BR>&nbsp;
<P>Ciao da Klaus :-)</HTML>

<BR>disponibili sul mercato!!
se ho capito bene (accidenti all'HTML ! :) ) su questo sono
perfettamente d'accordo !
Ciao, e la prossima volta disabilita l'html :)
Gianpaolo Bottin
- The truth is out there -

linguaggio complesso ma soprattutto é un linguaggio cha VA STUDIATO,
C'è anche un altro punto fermo: se vuoi scrivere applicazioni che non
facciano addormentare l'utente e hai bisogno di velocità non puoi fare altro
che "scendere" in basso e SCRIVERE le tue applicazioni... senza demandare
questo compito all'ambiente di sviluppo o a linguaggi "pseudo interpretati".
Anch'io ho detto la mia.
Saluti.
Sebastiano Del Gobbo
info - software solutions
gr...@mbox.vol.it

<BR>&nbsp;
Che il polimorfismo accompagni le tue feste in un'atmosfera di sereno
sviluppo veloce ;)
Cordialmente,
Gianni Rondinini, programmer and designer at Pierre s.n.c.
e-mail: mailto:
pie...@mail.asianet.it
homepage: 
http://www.geocities.com/Eureka/Plaza/7153
Red Hat Linux user since 9/25/97
Windows NT Server user since 9/19/97
A paperless office has about as much chance as a paperless bathroom.

In quest'ultimo caso se sei esperto con il tuo NON-RAD ci metti >circa lo
stesso tempo.
Concordo.
Saluti,
Massimo

 Gianni Rondinini, programmer and designer at Pierre s.n.c.
Molto cordialmente 
Klaus ;-)

ANCHE QUI DI SAPERLO USARE!!!     
in parte sono d'accordo, certamente e' molto meglio di VB e simili ma
restano ancora alcuni problemi:
- non e' standard. Questo comporta dei problemi quando ad esempio
cerchi dei tools o delle librerie; MFC e OWL sono standard di fatto e
ormai soprattutto per le MFC si trovano molti add-on ben fatti e
dotati di sorgenti. E' vero che puoi usare gli OCX, ma credimi, non la
stessa cosa che usare una librerie di classi C++. Altri problemi
nascono se devi scrivere del codice per terzi oppure utilizzare del
codice scritto da altri, in questi casi lo standard e' quasi sempre
MFC.
- Il framework ti nasconde windows e questo non sempre e' una bella
cosa; probabilmente e' vero che puoi fare tutto quello che fai con il
VC, ma quando un framework ti nasconde pesantemente cio' che sta sotto
diventa difficile capire se certi comportamenti sono dovuto a una
"feature" del framework o a windows e soprattutto e difficile
intervenire. Gia' le MFC per alcuni aspetti fanno troppe cose, senza
contare che se le classi non sono state progettate a regola d'arte e'
un problema anche modificare il comportamento di quelle cose che
dovrebbero invece agevolarti il lavoro. Ad esempio con le MFC
customizzare l'anteprima di stampa e' un disastro per via del modo con
cui e' stata realizzata.
Gianpaolo Bottin
- To boldly go where no one has gone before... -

Sottoscrivo, per esperienza vissuta (non solo letta).
Quello che dive C. Calvert del C++ Builder č tutto vero,
se fosse stato falso io non starei usando il C++ Builder
e non starei qui a perder tempo per garantire che č vero,
d'altro canto a me non me torna niente in tasca se la
Borland vende due compilatori in piů, anzi se non li vende
ho due potenziali concorrenti in meno...
Ciao.

ho due potenziali concorrenti in meno...
Il discorso è lo stesso sia per te che per Klaus. Tu sei convinto di
avere l'ambiente di sviluppo migliore perché altrimenti non lo
useresti: mi dicono spesso che sono presuntuoso, ma mi sembra che tu
non sia tanto da meno ;). Io ho usato per un po' VB poi Delphi 1 e 2 e
un po' BC e poi sono passato a VC avendo cura di provare anche Watcom
10.5. Nessun programma di terzi potrà andare mai bene come uno di
Microsoft in termini di prestazioni, perché Microsoft ha scritto il
sistema operativo e ha in mano tutte le cose non documentate che gli
altri non hanno. Quando uno scrive "Ottieni gli stessi risultati
-almeno- in termini di prestazioni e dimensioni" lo fa in mezza mala
fede, perché sa che nessuno andrà mai a controllare e sa anche che non
è vero. Tu hai comprato un ambiente di sviluppo di Borland e poi hai
comprato un libro che ti spiega come usarlo dove, chiaramente, c'è
scritto che quello è l'ambiente di sviluppo migliore. Ci credo anche
io che l'autore scrive una cosa così. C'è scritto la stessa cosa anche
sui libri che parlano di Visual Basic 5.0, sai? E poi c'è scritta la
stessa cosa anche sul mio Visual C++ Unleashed. Ti pare che uno ti
vuole invitare a usare un ambiente di sviluppo e poi ci scrive che
altri sono migliori? Non si è mai visto.
Cordialmente,
Gianni Rondinini, programmer and designer at Pierre s.n.c.


ANCHE QUI DI SAPERLO USARE!!!     
Oh, kakkio, mi hai quasi rotto i timpani ;)
Tu puoi sapere usare BCB quanto ti pare, ma non produrrai MAI
applicazioni prestanti come le mie -a parità di listato se usiamo solo
API e non classi precostruite- perché il tuo compilatore non può usare
il 100% di quanto il sistema operativo mette a disposizione. Sono
stato chiaro? Lo sai quante cavolo di API non sono documentate da
Microsoft? TANTE! E BCB non le usa mentre VC sì. La intuisci la
differenza? Io credo proprio di sì.
Cordialmente,
Gianni Rondinini, programmer and designer at Pierre s.n.c.


 differenza? Io credo proprio di sì.
Uhm. Scusa l'intervento, ma sono curioso: dato che conosci bene
VC++, a quanto pare, *dove* sono queste leggendarie chiamate proprietarie?
In MFC? In tal caso, fare un reverse engineering non dovrebbe essere
difficilissimo, per un'altra casa che fa praticamente solo compilatori. (a
proposito, ricordo Undocumented Windows, su 3.x, divertente, ma non e'
che poi ci fosse dentro chissa' cosa).
Nelle system call generate dal compilatore? Hai quindi disassemblato
il codice su vari programmi diversi e verificato che VC++ genera e usa chiamate
e sc molto diverse da altri? E a partire da *quale* codice? Un'API, dopotutto, non
e' nient'altro che un formalismo per esprimere una sequenza di allocazioni sullo
stack e un jump a un indirizzo. Tutto il bendidio sta nelle parti di MFC scritte
in assembler?
Ormai non ho piu' tempo :( di fare suddette comparazioni (e uso indifferentemente
VC++ e BCB, a seconda di quanto mi serve :^) ), quindi sarei interessato
a qualche informazione piu' precisa.
Saluti,
    CS
--
Cristiano Sadun - Software Engineering and Consulting
***********Remove NOSPAM from address to reply***********
*********************************************************
"God is Real - unless declared Integer"

a qualche informazione piu' precisa.
Facciamo un sunto veloce così risolviamo il tutto. E' chiaro che non
stanno nelle MFC le chiamate alle API non documentate, altrimenti
sarebbe sufficiente guardare il codice sorgente delle MFC -che è
fornito con il compilatore- per vederle. Le chiamate non documentate
vengono generate dal compilatore in fase di compilazione. Analogamente
a quanto avevano fatto con Dos tanti anni fa, alla Microsoft hanno
introdotto anche in Windows tante "API" non documentate. Vuoi qualche
esempio? Fai un salto su 
www.ntinternals.com
 e poi vedi quante ne
hanno usate loro per quei 10 programmini demo che puoi scaricare
gratuitamente dal sito. Poi ce ne sono tante altre che si trovano in
altri posti, ma dato che l'argomento non mi interessa particolarmente,
non ho mai approfondito più di tanto.


differenza? Io credo proprio di sì.
Ripeto: nessun compilatore utilizza il 100% di quanto il sistema operativo
mette a disposizione, nemmeno quello di MS.
Riflettendo sulla tua affermazione: se fosse come dici tu ai concorrenti di
MS basterebbe utilizzare VC++ per ottenere gli stessi risultati che MS
ottiene nei suoi applicativi.
Semplice no ?
Caro, Gianni, rifletti con piu' attenzione prima di fare certe affermazioni.
Saluti,
Massimo


Giusto e facciamola finita una buona volta di creare thread di 20
messaggi dei quali uno parla bene di MS l'altro di BOrland.
Saluti
Stefano

Semplice no ?
perfettamente d'accordo
Buon Natale a tutti
[ranger, email: 
ran...@queen.it
]

esempio? Fai un salto su 
www.ntinternals.com
 e poi vedi quante ne
introdurre api non documentate non e` la stessa cosa di un compilatore
che ti inserisce le chiamate automaticamente.
le chiamate non documentate ci sono, ma poi possono sparire senza
preavviso ... 
