Newsgroup: it.comp.programmare.win32
Titolo: VCL?

Salve a tutti, una piccola presentazione...
Ho 30 anni, e smanetto con i computer dai tempi dello Spectrum, avendo fatto
tutta la trafila canonica... il vecchio basic interpretato del dos,
QuickBasic, DBIII+ et successivi, Clipper, dalla Summer 87 al 5.0 (Fatto
arrivare dall'america di contrabbando!), poi la nascita di VB con il suo
orrore, il Borland C++ (4 e 4.5 con le sue OWL e la sua Database Engine) e
poi l'amore, Delphi, che uso dalla prima versione...
Premetto che programmo per passione, e da 2 mesi, ora, anche per
professione...
Dopo aver letto i commenti di Alex Martelli sulla MFC e ATL, e su WTL in
it.comp.lang.c++, mi chiedevo... ma a proposito di Framework, cosa ne
pensera' Alex della VCL di Borland, e del venturo adattamento di questo
framework per Linux con il prossimo Delphi per Linux?
Gia' la vecchia OWL era per me un portento rispetto all'unica concorrente
del tempo, la MFC, ora la ditta per cui lavoro usa VC, ma e' aperta a tutti
i suggerimenti (visto che sta crescendo a ritmi spaventosi) e io volevo
proporre CBuilder e Delphi come affiancamento a VBasic e VC che attualmente
usano...
Arathorn
Paolo Invernizzi

 wrote in message
news:8kn2sj$3ni$1...@news.IT.net...


 usano...
Penso che Delphi sia migliore di VB in vari rispetti, e piu` o
meno pari nell'uso e nell'implementazione di COM.  Usare questi
linguaggi, meno "spinti" come prestazioni ma piu` semplici e
produttivi da usare, puo` essere comunque il modo migliore di
realizzare la gran parte dell'applicazione.  Il VC++, con ATL,
puo` essere l'ideale per realizzare componenti COM che forniscano
servizi computazionali spinti "a tavoletta", o accessi di basso
livello a funzionalita` di sistema; ATL e` particolarmente
adatta a questi casi per la sua maniacale enfasi sulle prestazioni
ad ogni costo (esattamente in linea con la filosofia C++).
Non mi pare che C++ Builder abbia un ruolo in questo quadro
strategico.  Non e` altrettanto semplice e produttivo di VB
e Delphi; non permette di lavorare altrettanto bene con ATL
per produrre i pochi ma cruciali "componenti ultra-spinti"
necessari.  Mi pare che l'unica "nicchia" di Builder sia in
aziende che, per qualche ragione, vogliono a tutti i costi
usare un singolo linguaggio di programmazione per svolgere
tutta l'ampia gamma dei compiti che sono necessari, dal tweak
dei bit a bassissimo livello di sistema, alla coordinazione
dell'interfaccia utente; non e` la strategia ottimale, secondo
me, e penso che quella multi-linguaggio della tua azienda sia
superiore -- ma se un'azienda e` decisa ad implementare una
strategia mono-linguaggio a qualsiasi costo, C++ Builder puo`
essere il meno peggio, un compromesso certo non ottimale per
nessun singolo rispetto ma forse si` nel complesso.
Alex

 Classes") e` disponibile solo da VJ++6, il Java di Microsoft.
Ho buttato solo un occhio alle WFC e credevo che i loro architetti si
fossero ispirati alla VCL ma non pensavo fosse lo stesso!
Mi sento un po' cretino....
Grazie per gli altri consigli, credo che proporro' il Delphi come
alternativa/affiancamento al VB...
E lascio perdere il CBuilder...
Arathorn
Paolo Invernizzi

 E lascio perdere il CBuilder...
Mi sembra una buona strategia.  Dai anche un'occhiata, gia` che
ci sei, a Python.  
www.python.com
, ad esempio, e il libro di
Hammond "Python programming on Win32".  Hammond oggi lavora per
ActiveState e collabora con Microsoft; al PDC della settimana
scorsa, hanno mostrato (ancora in beta) l'integrazione di Python
nello schema .NET cui accennavo.  Ma gia` oggi Python e` un
ottimo linguaggio [a] in generale [b] per programmare su Win32
in particolare; il libro di Hammond (O'Reilly e` l'editore)
oltre a spiegare il linguaggio stesso (non e` difficile, e`
incredibilmente semplice per la sua potenza, e viceversa:-)
mostra bene come "incastrarlo" nei piu` vari scenari Win32,
compresa mi pare l'integrazione con Delphi (su cui troverai
comunque anche ottimi esempi in rete).  Per fare prototipi,
per avere nell'applicazione uno "scripting" che la personalizzi
sul campo senza ricompilare (come VBA in Office per capirci),
e per mille altre cose, Python e` davvero senza rivali.  E,
oltretutto, gratis e Open Source; un vero sogno.  Io non
potrei piu` farne a meno, dopo solo pochi mesi che l'ho
affiancato a tutti gli altri linguaggi -- Perl non lo uso
piu` (Python occupa una nicchia analoga, e la occupa meglio),
e VB, VC++, Java, ecc, sempre meno, Python sempre di piu`...
Alex

 e VB, VC++, Java, ecc, sempre meno, Python sempre di piu`...
Attualmente stiamo lavorando a due applicazioni, tutte e due in porting da
HP Unix...
Una si appoggia ad alcuni script in Perl per parsare dei file ASCII da
spedire ad un gestore SQL...
L'altra implememta l'analisi di alcuni file ASCII di log e li presenta
all'operatore in maniera piu' "umana", e (per richiesta del cliente) deve
essere in Java e portabile per NT e HP Unix... e praticamente la stiamo
sviluppando come un preprocessore, con un file di Config, modificabile "sul
campo" dal cliente dove e' specificata la "sintassi" dei vari file di log da
parsare ed il come si presenteranno parsati e omologati all'operatore...
Quando ho visto quello che puo' fare Python mi sono mangiato le mani!!
Sarebbe stato l'ideale, soprattutto come motore per la seconda... ma ormai
e' troppo tardi ed il lavoro e' gia' in corso... ed il tempo e' tiranno!
Abbiamo sbagliato la stima dei tempi di lavoro... dovevamo fare *4, come ha
scritto Eckel!!
Arathorn
Paolo Invernizzi

necessari.  
Io mi sto sempre piu' convincendo che il C++ Builder sia un fallimento
di casa Borland. L'ha prodotto sulla base di una gerarchia creata in
Object Pascal, con tutti i limiti impliciti che ci sono.
Parliamoci chiaro : la VCL e' meravigliosa se vuoi seguire i suoi
schemi, ma presto ti rendi conto che e' un recinto soffocante.
Chi programma in C++, secondo me, non puo' essere cosi' "obbligato".
Deve avere maggiori liberta' di movimento ed e' per questo che,
nonostante la mia azienda si ostini ad afficancare Delphi e C++
Builder, io vorrei tanto iniziare a studiare l'ambiente VC++.
Ho il Visual Studio 6.0 e comincero' subito a spulciarlo.
E poi, dico io, quante aziende, tuttora, utilizzano C++ Builder ?

 Deve avere maggiori liberta' di movimento
Premetto che il CBuilder non lo conosco molto, in quanto uso Delphi. Vengo
da Borland C++ e OWL, come ho scritto prima... e premetto anche che pure a
me il CBuilder "a naso" non mi sembra destinato ad un gran successo... e il
parere di Alex e il tuo su questo mi confortano...
Ma per curiosita', per quanto riguarda quello per cui e' fatta, cioe'
gestire in maniera Visuale tutta la Componentistica win32, non credo che si
possa chiedere di piu' a questa libreria... cosa intendi per maggiori
liberta' di movimento rispetto alle VCL? Mi faresti un esempio di qualche
tipo? Non perche' non sia d'accordo, ma per capire meglio.
Arathorn
Paolo Invernizzi

ci sei, a Python.  
www.python.com
, ad esempio, e il libro di
Ho gia' scaricato il compilatore e l'ambiente Win32 nonche' il
tutorial, devo solo installarli. Dai pochi esempi che ho visto sembra
un linguaggio simpatico. Comunque il sito dovrebbe essere
www.python.org
.

tipo? Non perche' non sia d'accordo, ma per capire meglio.
Per quanto riguarda il "Rapid Development" dell'interfaccia, credo che
gli ambienti borland siano imbattibili nel modo piu' assoluto.
Offrono degli strumenti veramente potenti.
Pero', al tempo stesso, sei soggetto alle loro ferree regole.
Le classi VCL fanno tutto da sole, ti nascondono tutto il codice.
Da un lato questo e' bello, perche' non ti preoccupi troppo di come
funzionano le cose al livello piu' basso, pero' dall'altro io vorrei
riuscire a intravedere i meccanismi sottostanti.
Mi sembra che il VC++, da questo punto di vista, nasconda meno.

 
www.python.org
.
Hai ragione, grazie della correzione e scusate tutti l'errore; ho
scritto in modo affrettato!
Alex

 E poi, dico io, quante aziende, tuttora, utilizzano C++ Builder ?
Non lo so.  Sul sito Borland non se ne parla...?
Alex

 e' troppo tardi ed il lavoro e' gia' in corso... ed il tempo e' tiranno!
Tieni comunque presente che puoi incorporare Python DENTRO a Java
in modo totalmente trasparente.  Vedi 
http://www.jpython.org/
 e in
breve tempo avrai una 100% Pure Java implementazione di Python da
cui puoi fare tutto quel che puoi fare in Java.  In pratica una
volta progettata una classe o gerarchia puoi implementarla in
JPython in meta` tempo, poi se occorre rifarla in Java una volta
che tutto e` a punto, nei rari casi in cui le prestazioni te lo
richiedano.  Al netto, RISPARMI tempo; le tue .class scritte in
JPython, "da fuori", sono indistinguibili dalle altre scritte in
Java -- possono chiamare ed essere chiamate da ogni altra.
Il boost di produttivita` che questo ti permette potrebbe essere
proprio quel che ti serve in un caso di urgenza come questo.
Comunque, capisco la riluttanza ad aggiungere tecnologie a
progetto in corso; se non altro, e` pur sempre un rischio, la
tecnologia nuova va un minimo studiata, ecc ecc.  Se non altro,
nei progetti futuri saprai sin da subito le possibilita`, anche
se questi devi portarli a termine senza il Serpentone:-).
Alex

Mi sembra che il VC++, da questo punto di vista, nasconda meno.
Puo' essere uno svantaggio, no? Comunque dipende dal framework che usi con
il VC... con MFC di sicuro si vede molto di piu' dell'architettura Win32,
credo che il nascondere non sia da considerare un difetto, se il framework
e' coerente e ben fatto ben venga...
Arathorn
Paolo Invernizzi

 riuscire a intravedere i meccanismi sottostanti.


 se questi devi portarli a termine senza il Serpentone:-).
Infatti, credo che questo progetto lo termineremo in Java, ma per i
prossimi....
Sei una miniera di informazioni 8-)
Arathorn
Paolo Invernizzi

e' coerente e ben fatto ben venga...
A me piace esattamente questo. Riuscire a vedere un po' di piu'
dell'architettura Win32. Puo' anche essere uno svantaggio, e' chiaro,
ma a me piace di piu'.

discorso!-).
Grazie Alex dei tuoi consigli, come sai ne faccio sempre tesoro,
perche' penso che tu sia una grande guida (meglio di molti libroni ;).

 ma a me piace di piu'.
Ma lo puoi fare.... puoi derivare tutti i componenti che vuoi direttamente
da TObject, o TComponent, o TWinControl, ...,
Se non ti piace come hanno incapsulato l'architettura win32, nulla ti vieta
di rifarti quello che vuoi, e per di piu' inserirlo nel framework...
Non sono sicuro ma credo che l'unica cosa che non si puo' fare e' un debug
"scendendo" nell'implementazione della gerarchia VCL da CBuilder, in quanto
si salta a sorgenti Pascal, ma se uno ha dei dubbi su come funziona la
gerarchia, puo' sempre farlo in Delphi...
Certo, si apprendono meglio le win32 se si "vedono" di piu', ma lo scopo di
un Framework e' questo? Meglio allora armarsi di santa pazienza e smanettare
la MFC, anche se credo che sia meglio armarsi di santa pazienza e imparare
il Pascal e smanettare la VCL da Delphi... se il Framework e' buono, anche
la Win32 che nasconde la si "capisce" meglio.
Ciao
Arathorn
Paolo Invernizzi    ... PS... scusate per il post precedente targato
Barbara, la mia ragazza, ma ero a casa sua e non ho resistito dal postare un
follow-up .... ma mi sono dimenticato dell'identity.... ;)

 ma a me piace di piu'.
Allora ti piacera` da matti WTL, o anche solo quel sottoinsieme
di ATL che riguarda la gestione di finestre, messaggi, ecc.  Mai
visto uno strato piu` sottile (ben fatto, ma sottile) in un framework
che ricopre un livello piu` basso.  Sei chiaramente il tipo di
persona a cui si rivolge WTL, e altri schemi analoghi (non MS, ma
pure ispirati da ATL) come "Attila".
Personalmente, non sono tanto d'accordo.  "Vedere l'architettura
che c'e` sotto" ha sostanzialmente dei vantaggi di prestazioni, e
sono poche ormai le situazioni in cui in una GUI ci si preoccupa
delle prestazioni; nel caso dell'ATL siamo in uno di quei pochissimi
casi, per un parametro di misura molto specifico, *la dimensione del
componente generato*, in quanto orientata (fra l'altro, e certo per
la parte che riguarda gestione finestre ecc) alla scrittura di quei
componenti ActiveX che possono trovarsi a "viaggiare in rete" in
modo piu` o meno automatico.  Per tenerlo sul mio disco, che un certo
robo sia 50k o 100k poco m'importa; se lo scarico dalla rete,
invece, fa ancora oggi una notevole differenza!  Ma questo non si
applica a WTL (e Attila, ecc ecc).  In questi casi, mi pare, la
leggerezza del framework e` un puro tour de force.  Affascinante
vedere come hanno risparmiato un byte qui e due li, ma, in realta`,
che me ne cale?  Mi pare, onestamente, una considerazione di ordine
molto basso rispetto a tante altre misure di qualita` del framework.
Per il COM in generale, le prestazioni sono cruciali molto, molto
spesso, poiche` e` anche usabilissimo per connettere fra loro dei
componenti in-process che si fanno tante reciproche chiamata, dei
calcoli pesanti, ecc, ecc.  Per questa parte, la leggerezza del FW
e` dunque cruciale (piu` in termini di cicli di macchina che non
di byte, ma spesso le cose coincidono, a causa dell'esistenza di
cache, memoria virtuale, ecc ecc).  Idem per i thread e quel che
li accompagna (thread-pooling, meccanismi di sincronizzazione, &c):
sono aspetti che posso benissimo usare nel "cuore computazionale"
dei miei programmi, BISOGNA che vadano "come unti".
Ma, _le finestre_...?
La leggerezza/sottigliezza di un framework (rispetto a quel che
ricopre) ha anche degli svantaggi.  Ad esempio, sara` certo piu`
difficile un eventuale porting ad altre "realta` internamente
ricoperte", se il livello di astrazione della ricopertura e`
modesto.  Certo VCL non mostra buone caratteristiche da questo
punto di vista se del porting in corso si fa tanta grancassa,
visto che framework equivalenti nati sin dall'inizio come cross
platform esistono e funzionano benissimo da un pezzo (il mio
attuale preferito e` wxWindows, ma forse sono influenzato da
quanto eccellente sia la sua connessione Python, wxPython).  Ma
essendo sufficientemente "spesso", ce la fara`, come gia` tanti
anni fa ce la fece il vecchio MFC (pochi lo ricordano, ma era
disponibile anche per Macintosh, quando alla Microsoft conveniva
supportare Macintosh).  Certo (come per MFC e a differenza di
wxWindows, *progettato* x-platform) la versione portata non
sara` della stessa identica qualita` dell'originale (queste
cose non si retrofittano mai alla perfezione), ma, pazienza,
comunque bene o male, a cucci e a spinte, funzionacchiera`.
Con ATL (parte di windowing), WTL, Attila, sarebbe molto piu`
difficile fare un porting del genere.  E la versione portata
finirebbe facilmente per sacrificare la stessa leggerezza, le
prestazioni vere e proprie, della versione originale, quindi
avrebbe ben poche ragioni di esistere (salvo il solito "tour
de force" della tecnica per amor della tecnica:-).
Alex

la Win32 che nasconde la si "capisce" meglio.
Io il pascal lo conosco perfettamente ma, nonostante questo, provo
grande affetto per il C++ e vorrei che il framework fosse scritto nel
mio linguaggio preferito. Tu dici "meglio armarsi di santa pazienza e
smanettare la MFC". E' esattamente quello che ho detto anch'io.
Ribadisco, infine : contatemi le aziende che usano C++ Builder.

 smanettare la MFC". E' esattamente quello che ho detto anch'io.
Piacerebbe pure a me, ma o si mangia questa minestra o... si passa a VC ;)
Arathorn
Paolo Invernizzi

 Cosa offre il mercato in alternativa? Quale IDE C++ e' cosi' portata al
RAD?
IBM VisualAge C++, 
http://www-4.ibm.com/software/ad/vacpp/
, ma il mercato
la odia.  Buffo, perche` nella versione 4, a quanto ho visto, sembra buono.
Forse "sconta il suo passato" (OS/2, AIX, &c).  La versione 5, che per ora
esiste solo per AIX, e` anche il primo prodotto commerciale che sostiene di
supportare al 100% lo Standard, sia come compilatore sia come librerie,
a quel che so (comunque, anche il 4 e`/era MOLTO fedele).
Forse il problema piu` sostanziale e` che VisualAge supporta solo NT (e
OS/2, AIX, ecc, ma NON Win95/98) come ambiente di sviluppo; puo` certo
fare applicazioni PER 95/98/ecc, ma lui come ambiente vuol girare su NT
(e a quanto ho sentito lo sfrutta benissimo, comprese le feature piu`
raffinate di NTFS ecc ecc).
Certo che uno che spende US $800 per un ambiente di sviluppo non
dovrebbe risicare i $150 o quel che e` di extra costo di NT su Win98, ma
sapete com'e`, forse e` l'effetto psicologico.  Microsoft, come sempre piu`
furba, e Borland, una tantum furba anch'essa, i loro compilatori/ambienti li
fanno girare anche su Win95, anche se questo significa sacrificare certe
importanti possibilita` di ottimizzazione.  Forse sanno che tanti
sviluppatori,
che al lavoro, certo, hanno potenti workstation NT, a casuccia tengono '95
su un qualche vecchio catorcio, e una copia "con la benda all'occhio" del
sistema di sviluppo che usano al lavoro, e se questo non fosse possibile
la produttivita` dello sviluppatore ne soffrirebbe... e IBM (se non e` MOLTO
cambiata da un tempo) cerca sempre di vendere ai top manager del MIS,
ma nel mondo dei PC il potere decisionale non e` cosi` sbilanciato, se la
squadra tecnica della soluzione X non ne vuole sapere non e` tipico che
le venga imposta (tipico compromesso: il MIS vorrebbe IBM su NT, i
tecnici gcc su Linux, si finisce per usare MS o Borland su NT e 95/98...:-).
Mah.  IBM gia` sta regalando tanti di quei prodotti, comprese altre edizioni
di VisualAge in "micro edition", "individual pack", ecc ecc, che potrebbero
anche svegliarsi e mettersi a regalare anche versioni "per individui" di
VA C++, magari che girino anche su 95/98, e allora, chissa`...!-)
Alex

sapete com'e`, forse e` l'effetto psicologico....
Eheheh perche' non proponiamo a IBM di includere una licenza NT nel
pacchetto? ;))))
Arathorn
Paolo Invernizzi

 pacchetto? ;))))
E i driver per le periferiche p&p che NT non supporta?  Forse meglio
'2000?-)
Alex

framework C++...
Ho gia' espresso la mia opinione sulle facilita' visuali dei pacchetti
Borland.

fatturato un sacco di soldi. Io un po' meno.
Questo e' il bello di OWL e forse uno dei tanti motivi per cui e'
stato snobbato da Borland. Il fatto stesso che OWL e' inoltre
compatibile con Win16 ne fa' un ottimo strumento. Non so' che fine ha
fatto la versione di OWL per Linux, pero' penso che come framework sia
piu' portabile di quanto non lo siano VCL e MFC. Ma Borland pensa
giustamente al profitto, chi puo' dirle se sbaglia?
Bye.

la produttivita` dello sviluppatore ne soffrirebbe...
Eh eh, e' esattamente il mio caso !!! ;)
Con tanto di "benda all'occhio"...

 Bye.
Forse il fatto che da quando ha abbandonato OWL a BC502 vende sempre meno
copie del compilatore C++ e che i suoi utenti sono sempre più scontenti.
Ma tu, adesso, cosa usi?


 Il contrario e' invece possibile.
Ciao,
        sono d'accordo sul fatto che il non poter installare direttamente in
Delphi un componente scritto col Builder sia una "limitazione"; non so
(visto che uso pochissimo C++Builder) se sia possibile scrivere un package
col Builder ed installarlo su Delphi... [aspetto conferma/smentita].
Comunque potresti aggirare l'ostacolo usando una DLL (con una struttura
simil-COM). Certo così ti sogni di poterci lavorare a design-time però è
meno impegnativo (ed oneroso) che scriversi un ActiveX...
Cmq direi che l'idea di avere dei componenti riutilizzabili con più
linguaggi diversi è ben soddisfatta da COM (/CORBA),  voler avere anche la
compatibilità dei sorgenti mi sembra chiedere un po' troppo...
Ciao :-)
--
(¯`·.¸¸.·´¯`·.¸¸.-> Andrea <-.¸¸.·´¯`·.¸¸.·´¯)
AntiSpam: rimuovere il trattino basso dall'indirizzo per rispondere
AntiSpam: remove the underscore from the e-mail address to reply

 lo permette persino VB...
Ciao,
         sinceramente io trovo la VCL molto comoda: mette a disposizione
tutto il necessario (in ogni situazione, direi) senza obbligarti ad usarla.
Io stesso ho scritto applicazioni che "funzionavano metà a VCL e metà con
API nude e crude"... Direi che è raro riuscire a scrivere un'applicazione
intera (complessa) senza ricorrere _mai_ alle API direttamente mentre è
possibilissimo fare tutto solo con l' API (a prezzo di un maggiore sforzo,
anche in termini di tempo di sviluppo ovviamente).
C'è da dire che la VCL offre decine di classi utilissime che ricoprono
interamente (ed egregiamente direi) le API che ci stanno sotto. Il sistema
di scambio di messaggi fra componenti è decisamente interessante ed efficace
e comunque spesso il framework viene incontro al programmatore (ottima a mio
avviso la gestione delle eccezioni con un handler "centralizzato").
Piuttosto avrei da ridire su qualche altro punto come il fatto che molti
oggetti hanno metodi privati che vorrei fossero protected (nella scrittura
di componenti ovviamente questo pesa molto).... per contro c'è da dire che
tutte le classi TCustomXXXX sono la manna per chiunque voglia ridefinire
completamente una classe.
Sinceramente a me sembra che la VCL sia un ambiente molto ospitale (e non
invasivo) dove scrivere codice, non riesco a capire come tu (Andrea
Laforgia) possa arrivare a dire che è un "recinto soffocante"...
Per completezza vi dirò che io non sono espertissimo (ho 18 anni, programmo
prevalentemente con Borland Delphi solo da circa 2 anni. Ho cercato di
spaziare sui molti argomenti che mi interessavano: dai databases alla
scrittura di oggetti COM, dall'interfaccia [scrittura di componenti] alle
DLL e tutto ciò che ci sta intorno. Questo non per dire che ho padronanza di
tutti questi argomenti [anzi] ma per dire che non è che scrivo per "sentito
dire"...) ma non mi sono _mai_ scontrato troppo violentemente con la VCL:
laddove ho trovato problemi l'ho semplicemente "scavalcata" per maneggiare
le API direttamente...
Un saluto a tutto il gruppo :-)


Ma tu, adesso, cosa usi?
Sempre il Borland C++ 5.02.
Bye.


l'indirizzo era (una volta)
www.uno.com
Fino ad un mesetto fa era attivo. Ma non ricordo i dettagli (Unix, Linux,
etc...)
Alla prossima,
    Luigi


Laforgia) possa arrivare a dire che è un "recinto soffocante"...
Perche' io (Andrea Laforgia) programmo in C++ e :
  1. Il linguaggio su cui e' basata la VCL e' object pascal e questo
mi da' leggermente fastidio (specie quando voglio spulciare i
sorgenti).
  2. Il linguaggio C++ e' molto piu' potente di Object Pascal e la VCL
stessa potrebbe sfruttarne i vantaggi, se fosse riscritta in C++.

compatibilità dei sorgenti mi sembra chiedere un po' troppo...
uh ? quale "compatibilita' di sorgenti" ?
La "compatibilita' di sorgenti" non e' richiesta quando si installa un
componente Delphi sotto C++ Builder. Cosi' come non sarebbe richiesta
nel caso contrario.

 nel caso contrario.
Scusa, ho scelto un'espressione infelice...
Diciamo la "compatibilità dei componenti" (poter installare un componente
scritto in C++ in Delphi e viceversa senza dover passare per qualcosa di
compilato [ActiveX o DLL varie] )
Ciao :-)


 stessa potrebbe sfruttarne i vantaggi, se fosse riscritta in C++.
Beh, sinceramente (come ho specificato + volte in altri thread anche su
altri ngs) direi che è estremamente difficile poter dire X è più potente di
Y... Ci sono troppi fattori esterni.
E comunque in un ambito OO non dovrebbe fregartene assolutamente _nulla_ del
linguaggio con cui è scritto il framework. Quello che ti interessa è cosa ti
offre e, come scrivi tu stessi, se fosse riscritta in C++ ti darebbe gli
stessi vantaggi...
Capirei di più una frase del genere se i vantaggi fossero maggiori degli
attuali.


compilato [ActiveX o DLL varie] )
I componenti, proprio perche' tali, DOVREBBERO essere compatibili tra
i diversi sistemi fondati sul medesimo framework.

stessi vantaggi...
In un ambito OO in cui mi vengono forniti i sorgenti di tutto cio' che
e' OO, sarebbe meglio avere i sorgenti nello stesso linguaggio.
Tutto qui. Nessuno sta discutendo le capacita' di astrazione di mamma
Borland e i vantaggi derivanti dall'utilizzare la sua gerarchia di
classi. Con C++ Builder hanno fatto dei salti mortali (ripeto : vedi
la classe AnsiString) per implementare qualcosa che in C++ esiste gia'
! E perche' ? per compatibilita' con Delphi ?
Che lo si voglia o meno, mamma Borland conservera' Object Pascal come
la punta di diamante e ad esso subordinera' tutto, da ora in poi.
(vedi Kylix, col quale sara' possibile scrivere codice cross-platform
gia' da Delphi 6).

 i diversi sistemi fondati sul medesimo framework.
Ok allora facciamo un po' di luce:
A) il Borland C++ Builder è in grado di compilare codice C++ ed è in grado
di gestire componenti scritti in C++.
B) il Borland C++ Builder è in grado di compilare codice ObjectPascal,
sfrutta il framework VCL, scritto in ObjectPascal, e può installare e
gestire componenti scritti in ObjectPascal.
C) Delphi è in grado di compilare codice ObjectPascal, sfrutta il framework
VCL, scritto in ObjectPascal e può gestire componenti ObjectPascal.
D) Delphi non dispone di un parser per codice C++ quindi non è in grado di
compilare codice C++ _quindi_ non può gestire componenti scritti in C++
E) Non fa una piega.
Ciao


 gia' da Delphi 6).
Sull'efficienza del codice cross-platform ho i miei dubbi: penso che sarebbe
molto meglio scrivere "codice per il sistema X" e "codice per il sistema Y"
piuttosto che scrivere "codice che gira sia su X che su Y". Ovviamente però
è indubbio che se il grado di astrazione a cui si lavora è tale che
rivoluzionare le fondamenta non è traumatico, ben venga il cross-platform...
Ciao :-)
