Newsgroup: it.comp.programmare.win32
Titolo: C++BuilderX Info

Ciao a tutti.
Avrei la necessità di capire come mai questo nuovo ambiente di sviluppo sia
soltanto un semplice ambiente integrato e non sia compatibile con versioni
come C++Builder 6 o kylix.
Inoltre gradirei sapere se c'è qualche soluzione per avere i componenti
grafici a cui borland ci ha abituato.
Grazie a todo
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Grazie a todo(s)
De nada.
Paolo.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Dalle ultime che ho sentito borland ha deciso di includere wxWindows nel suo
builderX.Si parlava di un cd in circolazione che includeva tutto il
necessario, ma non so se gia disponibile sul sito.Cmq  se non vuoi aspettare
più di tanto puoi gia scaricare il framework da 
www.wxwindows.org
ciao
------------------------
http://visualwx.altervista.org/
nuova release 0.77e [freeware]
VisualWx rad per c++,python,perl,lua e wxwindows


Grazie di tutto.
ma che cxxxo sta combinando la borland, non lo capisco più!


 ma che cxxxo sta combinando la borland, non lo capisco piů!
C'č una teoria a proposito molto carina...
se ti ricordi, un pň di tempo fa la Borland
stava fallendo. Fu salvata da Microsoft, che
comprň una grossa fetta di azioni Borland.
Strano, perchč i piů diretti concorrenti
del VC++ erano proprio Delphi e CBuilder.
Comunque, guarda combinazione a distanza
di un annetto da quell'operazione la Microsoft
tira fuori dal cappello il framework .NET
e il C#... la spiegazione di tutto potrebbe
essere un trasferimento di tecnologia "sottobanco"
per cui la Micro$oft si č impadronita della VCL
e l'ha ripresentata rimaneggiandola un pň e
rimarchiandola .NET per farla passare come
sua... come parte dell'accordo sottobanco,
il prezzo della salvezza per Borland sarebbe
stato quello di abbandonare la VCL al suo
destino per non fare concorrenza a .NET
di Microsoft.
Io te l'ho riportata, poi pensa quel che vuoi...

 
Ciao  a tutti sono nuovo di questo NG e sono arrivato qui cercando
indicazioni su CXbuilder 
Sono uno sviluppatore Delphi e devo dire che la tua idea è purtroppo
condivisa da molti e assai verosimile.
Non dimentichiamo che tra le menti del framework .NET e del C# c'è uno dei
creatori di Delphi, che 3 anni fa lasciò Borland per trasferirisi a suon di
dollaroni nell'attico di zio Bill
Troppe cose di .NEt e della recente politica commerciale e di sviluppo dei
prodotti Borland (abbandono silenzioso di Kylix, conversione di Delphi in
ambiente per il framework .NET) lascia purtroppo prevedere un futuro come
succursale della microsoft se non addirittura un'inglobamento della stessa,
che potrebbe diventare il ramo programmazione di M$
-- 
----------------------------
Saluti
Andrea
----------------------------

 più di tanto puoi gia scaricare il framework da 
www.wxwindows.org
La personal edition di C++BuilderX e la preview del tool RAD
che *genera codice per* wxWindows si possono scaricare dal sito
della Borland (circa 300MB per C++BuilderX e circa 100MB
per la preview del tool RAD per wxWindows).
Comunque C++BuilderX ed il tool RAD sono scritti in Java usando swing
(ad occhio e' croce e' una creatura degli sviluppatori di JBuilder)
e quindi il tutto risulta un mangia-ram da paura.
Forse gli conveniva aspettare ed uscire con un applicazione
che usasse wxWindows "anche per se stessa".
L. Micheletto

 che usasse wxWindows "anche per se stessa".
penso che la decisione di includere wxwindows sia stata presa dopo....
Mi sa che Microsoft ci ha messo lo zampino..


 Mi sa che Microsoft ci ha messo lo zampino..
Non sono del tutto sicuro, e' l'unico prodotto Borland (a parte Jbuilder)
che non e' proiettato su .net, la scelta di Java non mi sembra cosi'
malvagia (che sia lento, secondo me, non e' una conseguenza diretta di
questa scelta. Ci sono programmi piu' lenti sotto win32, e programmi piu'
veloci scritti in Java...) e le mie speranze sono tutte per una (eventuale)
versione 2.0.
Per quello che posso aver provato io, e' un prodotto "immaturo", non so
perche' sia stato rilasciato cosi' in fretta, ma ha delle buone
potenzialita'. Suppongo che in un prossimo futuro questo stesso prodotto
supportera' anche .net, e continuo ad avere fiducia in Borland.


[5] e il Babelfish
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.5. C, C++ and ASM developers
                               and beta testers are welcome!

 [3] 
http://www.sidetalkin.com/
3? Ma non c'e' nessun riferimento n. 3 nel testo...

 versione 2.0.
No no, la scelta di Java E' stata malvagia...
ti devi chiedere: "Cosa mi dà IN PIU' C++BuilderX che gli altri
non mi danno?" Se a fronte del mezzo giga di RAM che si pappa
e della lentezza hai EFFETTIVAMENTE qualcosa di più allora va
bene, sennò è una sola...
nei fatti C++BuilderX è un semplice IDE integrato. Come ce ne
sono tanti dai tempi del TurboPascal che in questo fece scuola.
Perciò a questo punto io non vedo perchè pagare fior di $$$
(anzi, di €€€) per avere quello che ho già con Dev-C++, gratis.
Al momento io ho C++Builder5, lo uso con grande soddisfazione
e dopo avere provato un paio di giorni il BuilderX credo proprio
che resterò col 5.
IMHO usare Java per il BuilderX è stata una gran cazzata...
han fatto Kylix per win e per linux senza Java, potevano far
così pure col BuilderX.


Bravo!
cmq a me importava un ambiente "pecciato" successore di kylix (ultra bacato,
come le CLX di CBuilder6), cosa che non è avvenuta.
Per cui il prog del super enalotto resterà per sempre confinato in kylix e
CBuilder6, almenochè qualcuno non si faccia avanti per il porting con qt3 e
kdevelop!
Ciao


 porting con qt3 e kdevelop!
Io tenterei il porting verso Pascal, usando kylix...


Tu convertiresti 1.750.000 linee di codice (sotto win) da un ambiente
all'altro, tenendo conto che è completamente scritto in C/C++ (solo i
componenti sono della borland)??
Io ci penserei...


Ho installato le wxwindows dal sito della borland...
ma lo stesso non vedo un componente grafico nell'ambiente BuilderX!!
Cosa devo fare??


 Cosa devo fare??
wxWindows non č la VCL, non puoi costruire dialog e
controlli graficamente. Purtroppo il BuilderX non
supporta la costruzione grafica dei componenti come
Delphi o CBuilder... devi prendere l'editor e scriverti
il programma a manina.
Per ottenere un ambiente RAD del tipo a cui (presumo) eri
abituato prima puoi prendere VisualWX, che ti permette di
lavorare con wxWindows come facevi col Builder vecchio.
E' ancora piuttosto immaturo perň... :-(

 3? Ma non c'e' nessun riferimento n. 3 nel testo...
ho rinumerato male. Comunque, è una pagina sull'N-Gage


Ciao, Bubuti!
Il giorno 06/12/2003 alle ore 16:22 hai scritto:
 >> Dipende da cosa intendi per "veloce",
 BB>
 BB> quello che intendono tutti: veloce. Che ci metta poco tempo
Te lo faccio io un programma che impiega 2 secondi per essere eseguito in
Java. E' sufficientemente veloce ?
 BB> a maggior ragione non va fatta in Java
In Java lo fai una volta e va bene per tutte le macchine che supportano
Java, cosa non possibile con le versioni native che devono essere come
minimo ricompilate, quando non interamente riscritte (prendi per esempio
un'applicazione Windows e Mac, come minimo tutta l'interfaccia grafica deve
essere sviluppata separatamente).
La "lentezza" del Java (con processori minimo da 2,4 GHz mi sembra assurdo
parlare ancora di lentezza) viene abbondantemente compensata dalla sua
grande portabilita'.
Bye

 lentezza)
quoto


Ciao, Bubuti!
Il giorno 06/12/2003 alle ore 17:22 hai scritto:
 BB> è il "va bene" che è sbagliato. Accetto al massimo "va"
Se il programma e' fatto bene va bene ovunque.
 BB> quoto
E quindi ?
Bye

 grande portabilita'.
Un programmino in Java è accettabile, un grosso progetto in Java
invece no. Semplicemente si mangia troppe risorse, vedi il C++
builderX di cui parliamo qui. E questo senza nemmeno accennare a
programmi CPU intensive come codec audiovideo, rendering 3D ecc.
dove Java è addirittura improponibile.
Un programma in Java è, al massimo, una pezza da sostituire il
prima possibile con un binario compilato: che è sempre, senz'altro,
molto meglio di un programma in Java.

Ciao, Tin!
Il giorno 06/12/2003 alle ore 17:37 hai scritto:
 TT> Le ho viste, le interfacce grafiche in Java... fanno tutte
 TT> ugualmente schifo, indipendentemente dalla macchina su cui
 TT> girano. In questo il requisito di portabilità è senz'altro
 TT> soddisfatto :-)
Questo e' un errore molto comune tra i programmatori che si avvicinano a
Java. L'interfaccia grafica deve essere realizzata con un certo criterio.
Per esempio non si deve assumere che un determinato font sia presente nel
sistema e che una scritta o un controllo occupi lo stesso spazio ovunque.
Java mette a disposizione delle "griglie" con cui costruire interfaccie che
avranno lo stesso aspetto ovunque vengano fatte girare. Se invece si
posizionano i controlli semplicemente tramite coordinate x e y, come si fa
ad esempio con le dialog di Windows, si avranno sicuramente problemi di
visualizzazione su piattaforme diverse da quella di sviluppo.
Questo, insieme alla costruzione dei path usando il backslash fisso, sono
gli errori piu' comuni che i programmatori Java della domenica commettono.
Purtroppo ci sono anche talmente tante applicazioni scritte in questo modo
che la gente crede che non ci sia altro modo di farele, cosa del tutto
falsa.
 TT> Un programmino in Java è accettabile, un grosso progetto in Java
 TT> invece no. Semplicemente si mangia troppe risorse, vedi il C++
 TT> builderX di cui parliamo qui.
Beh, non e' che certi programmi nativi occupino molto meno, vedi Premiere,
vedi lo stesso Visual Studio .Net e tantissimi altri. Un buon programma e'
difficile da realizzare in qualunque linguaggio, specialmente se ci si
affida ai vari "visual rad" e non si conoscono le basi della programmazione.
 TT> E questo senza nemmeno accennare a programmi CPU intensive come codec
 TT> audiovideo, rendering 3D ecc. dove Java è addirittura improponibile.
Beh vorrei proprio vederlo un pazzo che scrive un codec video in Java, qui
si tratta di tutt'altra cosa. Pero' ci sono programmi di editing video ed
effettistica realizzati in Java che vanno molto bene, uno per esempio e'
M2-Edit (editing MPEG2) e un altro e' MoreFx di ClassX (effetti video 2d,
3d, titolazioni, ecc.).
Bye

 schifo, indipendentemente dalla macchina su cui girano
quella di IBM è decente. L'hai vista?


 grande portabilita'.
Dipende quanto ti serve la portabilita` e quanto ti serve la velocita`.
La maggior parte delle applicazioni hanno piu` bisogno di velocita` che
di portabilita`, e quindi per la maggior parte delle applicazioni, Java
e` una pessima scelta.
-- 
Lorenzo

 e` una pessima scelta.
Aggiungerei anche che la portabilita' la puoi ottenere anche in C++, 
usando librerie multipiattaforma; ti basta una ricompilazione, o giu' di 
li' :) ...e hai le performance del C++!
Bye
Dan


Qualcuno sa se esistono tool automatici di conversione progetti da kylix a
CBuilder6 (intendo eliminazione delle CLX) o per CBuilderX?


 Mentre invece le prestazioni di .net sono strabilianti, vero?
Non e' un problema di linguaggio (entro certi termini) ma piuttosto
di infrastruttura.
Java e' "nato" per essere un *sistema* (linguaggio, runtime, librerie
ed infrastruttura) *portabile* e *sicuro*, la velocita' era
considerata secondaria e sacrificabile rispetto al resto
anche perche il progetto da cui e' derivato Java era risalente
a fine anni '80 ed inizio anni '90 ed era
orientato a dei set-top box ("decoder intelligenti" e roba simile)
realizzati con le tecnologie allora disponibili.
Poi e' uscito MS .Net, realizzato alla solita maniera da Microsoft
( prima tenere a freno la concorrenza e poi giu a a fare patch
   fino ad ottenere una versione 4.0 utilizzabile ).
Se si leggono le specifiche e la documentazione si scopre
che attualmente .Net non e' ne portabile e sicuro se si usano
le feature che *dovrebbero* renderlo superiore all' infrastruttura
Java.
Inoltre se lo si usa "come Java" tanto vale usare Java visto
che in tal caso si ottiene qualcosa che con qualche ulteriore
sforzo diventa realmente portabile.
La soluzione ai problemi dei due sistemi e' relativamente semplice
(se uno ha le risorse di MS o Sun)
ovvero cambiare l'infrastruttura di esecuzione e prevedere
qualche facilitazione per il codice che deve spremere al massimo
il sistema anche a costo di un rilassamento della sicurezza.
Microsoft lo sta gia facendo (basta dare un occhiata ai dati
resi pubblici sulla nuova infrastruttura "Phoenix"
che costituira' il cuore di .Net circa nel a meta 2005
(questo nelle ultime roadmap di Microsoft).
Stanno unificando il supporto per CIL e "C++IL" ed aggiungendo
*due* sistemi di esecuzione (compilazione statica in codice nativo
all'installazione dell' applicazione oppure compilazione JIT
con un sistema simile al layer di code morphing delle
cpu Transmeta o del progetto LLVM).
Sun invece per ora non sembra muoversi, ma sia IBM che la
comunita open source stanno lavorando ad alcuni sviluppi
interessanti:
- GCJ ovvero "GCC per Java" che permette la compilazione statica;
- SWT che velocizza le GUI che utilizzano tale toolkit;
- nuovi compilatori JIT che trasformano il bytecode Java;
   in un altro formato interno che rende piu efficiente analisi
   profiling ed ottimizzazione.
Peccato che l'alternativa migliore (partire con un runtime
minimo e poi espanderlo *con giudizio* a strati e moduli)
non sia stata seguita da nessuno dei contendenti.
Sun ha "riciclato un vecchio progetto" e poi ha aggiunto
API su API senza considerare cosa avrebbe ottenuto alla fine.
Microsoft ha "copiato alcune idee" da Sun e ci ha aggiunto di brutto
il requisito della compatibilita con le API gia supportate
da win-qualchecosa.
Nessuno dei due sistemi e veramente "leggero", nessuno e' stato
pensato tenendo conto che a qualcuno potrebbe tornar utile
compilare staticamente il codice "portabile" su un sistema
senza tutto il runtime (parlo di una crosscompilazione
in cui vengono compilate staticamente per il target
le sole librerie utilizzate dall'applicazione).
L. Micheletto

Ciao, Danguard!
Il giorno 08/12/2003 alle ore 11:04 hai scritto:
 D> Aggiungerei anche che la portabilita' la puoi ottenere anche in C++,
 D> usando librerie multipiattaforma; ti basta una ricompilazione, o giu' di
 D> li' :) ...e hai le performance del C++!
Quello che a molti forse sfugge e' che in Java non devi ricompilare niente
per far andare il programma su un'altra piattaforma. Puoi sviluppare sotto
Windows o Linux e avere la certezza che il tuo programma funzionera' nello
stesso modo su tutte le piattaforme che supportano Java.
Anche trovando delle librerie comuni per tutte le piattaforme che si intende
supportare (e la gestione delle finestre e' solo uno dei problemi da
risolvere) hai sempre bisogno di sapere come compilare i programmi, come
linkare le librerie, testare il software, eventualmente debuggarlo e
correggere gli errori specifici di quella piattaforma, creare gli installer,
ecc. Insomma hai bisogno del know-how specifico per ogni piattaforma. In
Java tutto questo non serve, se il programma e' fatto con criterio.
Certo se non interessa il multipiattaforma o se si sviluppa un'applicazione
multimediale spinta il Java non e' molto adatto (anche se per il
multimediale esiste da tempo il Java Media Framework), ma per chi e'
fortemente interessato alla portabilita' estrema il Java e' una piu' che
valida soluzione.
Bye

 valida soluzione.
Sono d'accordo. Come al solito, e' bene non essere mai "fanatici" di un 
certo linguaggio, ma analizzare sempre i pro e i contro caso per caso.
Ciao,
Dan

 Java tutto questo non serve, se il programma e' fatto con criterio.
Mmmm... e qui già compare un SE... ;-)
Sbaglierò, ma con Java va a finire come col C...