Newsgroup: it.comp.lang.c++
Titolo: Novello C++ ha iniziato a programmare: perchè DJGPP...

Il compilatore C++ per DOS DJGPP crea file eseguibili troppo grandi.
Ad es. la celeberrima applicazione "Hello word!" occupa ben 104KB.
Non voglio fare un paragone inutile tra un file eseguibile DOS creato
in C++ e uno in TurboBasic, per es., però la differenza non è da
sottovalutare: con l'ultimo compilatore citato scrivere "Hello Word"
con un semplice print "Hello Word" arrivi con hello.exe a 37K, mentre,
come già detto, con DJGPP arrivi a 104K!!
Esiste un modo per creare eseguibili più "corti"?
Ciao!
Vi ringrazio in anticipo.

Esiste un modo per creare eseguibili più "corti"?
Perche' vorresti eseguibili + corti ?
A che ti serve, oggi, ottimizzare la grandezza di un eseguibile ?
--
Walkie...@Libero.It (ICQ# 8143647)

A che ti serve, oggi, ottimizzare la grandezza di un eseguibile ?
Che risposta del cavolo :/ ...
 - Ad esempio perche' voglio distribuire un aggiornamento
   via internet e non tutti hanno un collegamento ADSL e
   sanno come usare WinZip
 - Ad esempio perche' il programma viene lanciato da rete
 - Ad esempio perche' il programma e' un driver e resta
   sempre residente
 - Ad esempio perche' cosi' forse ci sta in un dischetto
 - Ad esempio perche' cosi' lo posso mandare come allegato
   di mail senza farmi insultare da chi lo riceve
 - Ad esempio perche' se per colpa delle dimensioni del
   tuo eseguibile il gestore di memoria virtuale entra in
   modalita' "trashing" la differenza, ti assicuro, si
   nota eccome.
Nota che fra l'altro, per tornare on topic, in C++ e' abbastanza
facile se ci si distrae creare eseguibili mostruosi (mai sentito
del problema del "code bloating" con i template ?).
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

Ciao, scusa se mi intrometto ma quali sono i problemi dell'utilizzo dei
template?
Dimensioni, memoria?
--
---
Alessandro >>CoMiX<< Cominu
e-mail: 
aco...@tiscalinet.it
Icq: 116354077
Registered user at 
http://counter.li.org
 # 203765
[SNIP]


Che risposta del cavolo :/ ...
Onestamente, al giorno d'oggi non mi sembra cosi' importante che un
eseguibile abbia delle dimensioni ridotte come un tempo.
--
Walkie...@Libero.It (ICQ# 8143647)

 wrote in message
news:3b16128a...@news.libero.it...

Puo` essere assolutamente cruciale SE l'eseguibile in
questione deve "viaggiare in rete", come ad esempio un
componente ActiveX (che, se opportunamente firmato &c,
puo` venire automaticamente scaricato ed eseguito).  In
questo caso, con una banda passante (se va proprio grassa,
tipo IDSN:-) di 64k BIT al secondo, un megabyte di
eseguibile prende almeno quasi 10 minuti per essere
scaricato, e il visitatore del sito perde la pazienza
prima che questo processo termini:-).  Anche 100k sono
tanti se devi supportare utenti con piu` tipici modem
ecc, che se va bene fanno 4k circa al secondo: 25/30
secondi di ritardo (per lo scaricamento del programma)
prima che possa partire sono un piccolo ma pur sempre
avvertibile problema.
Altri casi in cui la dimensione dell'eseguibile puo`
essere cruciale sono quelli dei sistemi embedded, ma,
per quelli, TUTTO e` strano:-).
Nella maggior parte dei casi (distribuzione via CDROM,
bersaglio il PC tipico, ecc), e` verissimo che in questa
fase della tecnologia siamo al "megabyte piu`, megabyte
meno, chi se ne...".
Alex (MVP di Brainbench per il C++)

 Dimensioni, memoria?
A meno che il tuo compilatore e il tuo linker non abbiano
un decente livello di ottimizzazione (e collaborazione tra
loro:-), puo` succedere, usando i template, di generare
codice grosso in quanto "ripetitivo" -- se le espansioni
separate di un template non vengono riconosciute e "fuse"
in una sola istanza in fase di linking.
La soluzione migliore e` di usare un compilatore (e linker)
migliori (se li trovi per la tua piattaforma:-).


 wrote in message
news:9eb7b9$gol$1...@serv1.iunet.it...


 ha scritto nel messaggio
news:3b16128a...@news.libero.it...


č solo questione di spazio: parte anche piů velocemente, etc...
Ho notato la differenza con C++ Builder (5 Enterprise).
Con Delphi in realta' la differenza si nota poco perche' alla fine usi
praticamente solo le VCL per la creazione e gestione delle finestre.
Comunque gli eseguibili sono sempre abbastanza grandi.
Personalmente non ho mai avuto problemi con dimensioni anche di
qualche megabyte.  Pero' ammetto che potrebbero esserci casi in cui
questo diventa un problema (ma esistono sempre le DLL no ? :) o per
restare in tema Borland, i run-time packages ...).
--
Walkie...@Libero.It (ICQ# 8143647)

 A che ti serve, oggi, ottimizzare la grandezza di un eseguibile ?
100K in ambiente dos non mi sembrano pochini....

100K in ambiente dos non mi sembrano pochini....
Neanche a me, ma non vedo che motivo ci sia per accorciarli (a meno di
casi particolari tra quelli discussi negli altri messaggi)...
--
Walkie...@Libero.It (ICQ# 8143647)

 >è solo questione di spazio: parte anche più velocemente, etc...


P.S. Ma se devi fare un eseguibile più piccolo te lo frego io!!!
ROTFL ! ;) non pensavo fossimo arrivati a questi livelli ! :)
--
Walkie...@Libero.It (ICQ# 8143647)


Non è poi così terribile come sembra. Una volta capito come si crea una
finestra e come si intercettano i messaggi, il più è fatto. Secondo me vale
più la pena imparare le API di Windows che non le VCL, che moriranno molto
prima e che sono meno compatibili con tutto (leggi CE, Whistler, etc..)
Ad ogni modo, se devi fare solo delle semplici DialogBox, dai una occhiata
alla mia Dfm2API utility, che converte molti controlli VCL in un file di
risorse ed un file CPP con del codice già scritto. E se lo provi, fammi
sapere che ne pensi. Ci conto!
Ciao, Luigi
--


sapere che ne pensi. Ci conto!
Lo provero' ! ;)
--
Walkie...@Libero.It (ICQ# 8143647)

 ha scritto nel messaggio
news:3b0db92c...@news.libero.it...


che ha un senso.
Io ero tifoso borland. Con il tempo pero' ho compreso
la differenza fra un linguaggio (il C++) e un prodotto
(Delphi o Builder). I prodotti muoiono. Istantaneamente.
Senza appello. Con essi muore la conoscenza approfondita
che ci si e' fatta sugli stessi (se specifica).
Con i prodotti e' difficile "costruire"... perche' tutto
continua a crollare ad ogni passo.
Borland in particolare mi ha lasciato senza parole quando,
usciti i problemi della "division by zero" con programmi
Borland Pascal fatti girare su computer veloci non si e'
nemmeno degnata di rilasciare una patch "ufficiale" (cosa
che credo le sarebbe costata quasi zero).
Piu' importanti erano i bitmap di sfondo per il prossimo
l'installatore dell'IDE di Delphi 6.
Il C e' un linguaggio. Il C++ e' un linguaggio. Non sono
cosi' sicuro di poter classificare Java come linguaggio.
Delphi, Builder, Visual J++ sono sicuramente prodotti
e quelli che non sono morti stanno per morire. A breve.
Sicuramente si tratta di cose interessanti per risolvere
i problemi... io pero' non investirei troppo a studiarli
oltre al minimo necessario per la soluzione delle mie
necessita' contingenti.
Su C# e .NET ho le idee confuse. Quando vedro' qualcosa
in mezzo a tutto il fumo che MS sta facendo decidero' se
bruciare neuroni sulla cosa anche se non forzato.
.NET in particolare *potrebbe* diventare un "ambiente" e
quindi avere una vita' piu' longeva di un "prodotto".



Che opzioni di compilazione usi? Per caso fai includere le informazioni
per il debug?
Io uso il gcc sotto Linux, e per rendere piu' corti gli eseguibili
aggiungo l'opzione -s del linker, che serve per eliminare i simboli
dall'eseguibile.
Dovrebbe funzionare anche nel tuo caso.
Nel mio sistema, per esempio:
gcc hello.c
lunghezza eseguibile -> 11705 bytes
gcc -s hello.c
lunghezza eseguibile -> 3028 bytes.
Inoltre attivando le ottimizzazioni (-O) potresti ottenere eseguibili
leggermente piu' corti.
Ciao
Daniele

bere!
Sarei felice di incontrarti... se passo da Roma ti faccio un fischio !


e quelli che non sono morti stanno per morire. A breve.
Ripeto.  Non e' sicuramente vero x Delphi.
Per Builder e' probabile, per Visual J++ e' molto probabile.
Gli utenti di Delphi sono moltissimi e si e' creata una cultura
attorno a questo ambiente di sviluppo che e' difficilmente
contrastabile.  I sistemi informativi in cui viene utilizzato Delphi
cresce parecchio di numero rispetto al passato.
Personalmente, trovo Delphi, oggi, il miglior ambiente di sviluppo RAD
esistente e quindi non vedo perche' dovrebbe essere cosi' imminente la
sua morte.  Finquando ci sara' un buon numero di persone che
scegliera' quel prodotto, non ci sara' pericolo.
Borland, poi, farebbe bene ad abbassare *di molto* i prezzi ;)
--
Walkie...@Libero.It (ICQ# 8143647)

quindi avere una vita' piu' longeva di un "prodotto".
Non so perché ma prevedo che .NET si rivelerà alla fin fine un grosso
buco nell'acqua. Un sistema multipiattaforma prodotto proprio da
coloro che fino ad adesso hanno maggiormente contrastato i veri
sistemi multipiattaforma(perché vogliono che il software giri solo su
Windows) mi suscita quasi un senso di ilarità.
Il Ghenio
-----
ZIO : Fun and games are over with. Anyone who dares
get in my way shall perish.
-----

Borland, poi, farebbe bene ad abbassare *di molto* i prezzi ;)
Il Turbo Pascal non era caro... ma non so quante copie ne
abbiano vendute (anche se il Turbo Pascal ha *ridefinito*
cosa doveva essere un ambiente di sviluppo su PC).


E perché?
Perche' e' in mano a Sun e i cambiamenti introdotti con Java2
mostrano che la compatibilita' con il passato non e'
sicuramente fra le priorita' di Sun.
Chi costruisce con Java deve essere pronto a veder crollare
tutto ogni anno o due per le scelte di una singola ditta.
La cosa non e' vera (per fortuna) con i "linguaggi".



Un'altra cosa da tener conto per i sistemi embedded è la dimensione del
mercato dello sviluppo per una data piattaforma hardware embedded. Cosa che
spesso genera l'assenza di tool di sviluppo "dell'ultima generazione" (leggi
compilatori C++ decenti).
A questa va inoltre aggiunta il fatto che spesso si lavora su prototipi
dell'hardware con la conseguente necessità di fidarsi ciecamente dello
strumento di sviluppo o, per meglio dire, è necessaria una conoscenza
approfondita del funzionamento del compilatore/linker. Questo perchè è
necessario poter distinguere tra bug software e hardware, o più
semplicemente inconsistenze nelle specifiche di progetto.
Per concludere, nell'ambiente dello sviluppo di sistemi embedded, con cui
sono entrato in contatto io, già utilizzare compilatori C è considerato
"possibile fonte di problemi" (e dopo aver perso una settimana su un bug del
compilatore per un pò ho avuto anch'io quella sensazione). L'idea di
utilizzare un compilatore C++, anche per progetti di medie dimensioni, credo
sia prematuro, almeno fino a quando non si vedrà un aggiornamento nel
mercato dei compilatori C++ anche nelle nicchie di mercato.
Sotto questo punto di vista il GCC è di grandissimo aiuto.
Ciao Pietro

 Sotto questo punto di vista il GCC č di grandissimo aiuto.
Un altro strumento che potrebbe valer la pena di prendere in
considerazione e' il compilatore Comeau C++
(
http://www.comeaucomputing.com/
), che e' uno dei piu' aderenti allo
standard e genera codice Ansi C. Sulle piattaforme su cui e' disponibile
costa 50$ e viene portato a richiesta verso specifici compilatori C,
pare per prezzi modici.
Ciao,
Nicola

 cosa doveva essere un ambiente di sviluppo su PC).
Il Turbo Pascal aveva anche definito quanto doveva costare un ambiente
di sviluppo (sbaglio o erano 99$ ?). Peccato che abbiano cambiato
strada...
Ciao,
Nicola

Il Turbo Pascal non era caro...
Parlo di Delphi.
--
Walkie...@Libero.It (ICQ# 8143647)

questione) un prodotto come Delphi cosa sopravvive ?
Il linguaggio di base e' una versione evoluta del Pascal, quindi da
questo punto di vista preservi le tue conoscenze (i linguaggi non
muoiono giusto ?).
La tecnica di programmazione e' orientata agli oggetti, quindi da
questo punto di vista preservi le tue conoscenze (i paradigmi di
programmazione non muoiono giusto ?)
Hai acquisito nel tempo un bagaglio tale di conoscenze che potrai
applicare con profitto a qualsiasi ambiente RAD che rimpiazzi Delphi.
Insomma, non mi va di cantare le lodi di Delphi, perche' sono in tanti
a sapere che e' un ottimo ambiente di programmazione, difficilmente
rimpiazzabile.  Tu gli stai tirando i piedi e non credo la cosa
piaccia a nessuno.  Ripeto : il mio punto di vista e' che alcuni
prodotti muoiono, altri si evolvono.
Delphi e', a mio avviso, uno di quelli che subira' un'evoluzione.
Ti invito ad usare Delphi per un po' di tempo, poi ne riparliamo ;)
--
Walkie...@Libero.It (ICQ# 8143647)

strada...
beh, da questo punto di vista si presto a spendere meno. I compilatori
free si sono dimostrati essere molto buoni. Un po' meno lo sono gli
IDE e soprattuto i debugger, IMHO. Però speriamo che la situazione si
evolva.
Anto
--
Antonio Cuni, 19 anni, studente
Brainbench Certification: 
Master C++: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688

 volta morto VC++).
Che VC cambi fino ad essere irriconoscibile dal lato della gestione dei wizard
e' probabile. Ma che muoia come compilatore C++ e' piuttosto difficile.
Cosa pensi che usino in MS per scrivere i SO? E cosa pensi che possa sostituire
VC come tool di sviluppo per i device driver?
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 supporto impressionanti.
Prego? VC non e' uno standard. Ed e' certamente un grn prodotto. Anche se la
vera maturità dal punto di vista dello standard del linguaggio sarà con la
versione 8.


 direi che il rischio fallimento e' molto lontano.
Fin'ora quando MS ha acquistato società nel mondo informatico i motivi sono
sempre e solo stati due:
1) total buyout: si e' comperata tutta la società
2) competitor keepalive: si e' comperata parte di una società concorrente (o
quasi) che aveva grossi problemi economici. L'acquisto parziale e' un modo
legale per regalare al concorrente dei soldi e farlo vivere. Farlo vivere e'
necessario per evitare di essere considerati monopolisti e dover spendere
avvocati il triplo di quanto serviva al concorrente per sopravvivere. Esempio
eclatante: Apple.


Dimmi a cosa ti riferisci...
Boh... mi sembra di ricordare di una serie preoccupante
di rossi. Di grossi rimescolamenti. Di cambi di direzione.
Forse pero' i miei ricordi degli articoli di PCWeek sono
effettivamente offuscati.


Ti invito ad usare Delphi per un po' di tempo, poi ne riparliamo ;)
Lo sto usando (poco) :) ...


Prego? VC non e' uno standard. 
Temo si intendesse uno standard "de facto".
Non e' un mistero che la maggior parte delle aziende che lavorano in
C++, utilizzino VC++.
--
Walkie...@Libero.It (ICQ# 8143647)

codice portabile dall'uno all'altro ?
Molto vicina al 100%.  
Entrambi si basano sulla *stessa* gerarchia di classi (CLX).
Comunque direi che abbiamo discusso abbastanza, ora siamo OT ;)
--
Walkie...@Libero.It (ICQ# 8143647)

senso paragonare Delphi al C++. 
E chi lo paragona al C++ ? ;)
Sono sempre stato contrario ai confronti linguaggi-prodotti.
--
Walkie...@Libero.It (ICQ# 8143647)

Comunque direi che abbiamo discusso abbastanza, ora siamo OT ;)
Non so come la pensino gli altri del newsgroup... ma non credo
che discutere delle differenze fra un linguaggio e un prodotto
sia troppo OT. Ricordo questo accenno nel talk di Stroustrup & C
sul futuro del C++ (in cui si e' anche parlato del Borland
Pascal e della fine che ha fatto il Pascal) di cui ci ha fornito
un prezioso puntatore Andrea Ferro.


VC come tool di sviluppo per i device driver?
Secondo me Windows non e' classificabile come "tool" ... la sua
longevita' e' sicuramente in prospettiva migliore di quella di un
prodotto anche se e' monofornitore. Questo non toglie che anche
legarsi inutilmente a windows piu' dello stretto indispensabile
e in una percentuale alta delle linee di codice ha le sue
controindicazioni.


Sono sempre stato contrario ai confronti linguaggi-prodotti.
Ahhhhh... ok :)
Allora questa discussione e' inutile.


 Qualcuno si ricorda di quel bellissimo prodotto chiamato Clipper ?
Se me lo ricordo? E' tuttora il mio strumento principe per lo sviluppo
di gestionali! Naturalmente ha subito varie evoluzioni ma il linguaggio
base è rimasto quello. Ora poi è diventato free opensource
multipiattaforma. E quindi non è più un prodotto... :-)
EMG

Ma non era VCL ?
Si affiancheranno. VCL e CLX.
--
Walkie...@Libero.It (ICQ# 8143647)

non hai mai visto un sistema integrato.
Non ho detto che Delphi e' integrato ed eviterei di condurre la
discussione sul piano dell'"io ho visto cose che voi umani...".
Io ti sto solo dicendo che oggi Delphi e' integrabile molto bene con
Interbase e non e' difficile capire che unendo un ottimo tool di
sviluppo ad un ottimo RDBMS, puoi raggiungere dei buoni risultati.
Che poi questi siano inferiori a quelli che avresti utilizzando altri
sistemi, per me, onestamente, e' irrilevante.
--
Walkie...@Libero.It (ICQ# 8143647)

sistemi, per me, onestamente, e' irrilevante.
Uh ? Qui ti ho perso. Dico semplicemente che esistono strumenti
*stupendi* in circolazione. Pero' sono prodotti, non linguaggi.
E come tali sono soggetti ai capricci di mercato.
Tu scriveresti il sistema informativo di una banca usando qualcosa
che dopo tre anni o anche cinque potrebbe non essere piu'
utilizzabile ? (perche' c'e' di meglio... nessuno discute su questo).


aggiornamento nel mercato dei compilatori C++ anche nelle nicchie di mercato.
Su sistemi embedded ci sono aree in cui il C++ non ha semplicemente
senso (almeno il C++ "full" ... non vedo nulla di brutto nelle
classi in se'; si mantiene ancora un controllo esplicito totale
sul codice che viene generato). Il problema e' che anche se la
tecnologia dei processori e delle memorie avanza, sara' sempre
piu' conveniente riuscire ad usare una CPU che costa $10 invece
di una che costa $50 se quella che costa $10 ha una potenza
sufficiente per fare i lavoro che deve fare.


utilizzabile ? 
Il fatto e' che io, al contrario di te, sono convinto che Delphi non
abbia solo tre o cinque anni di vita.  Capisci ?
Comunque questa discussione comincia a stancare parecchio.
--
Walkie...@Libero.It (ICQ# 8143647)

 utilizzabile ? (perche' c'e' di meglio... nessuno discute su questo).
Bella!
Peccato che nel 1993 i piu' diffusi sistemi di gestione sportello bancario
italiani (guarda caso uno rosso e l'altro bianco, ma lasciamo perdere questi
dettagli politici) stavano per essere aggiornati all'ultimissima versione.
Scritta in COBOL.


 un prezioso puntatore Andrea Ferro.
Dunque qualcuno se lo e' pazientemente scaricato e ascoltato!
Avevo postato il link ma dubitavo che avesse avuto molto seguito. Streaming o
non streaming e' un bel mattone da scaricare (o ascoltare online) e non tutti
sono sufficientemente "inglesicizzati" e con a disposizione una ADLS.


 Qualcuno si ricorda di quel bellissimo prodotto chiamato Clipper ?
Gia'. E Mario Lener oggi lavora per un ISP nazionale. Sigh.


 utilizzabile ? (perche' c'e' di meglio... nessuno discute su questo).
Penso che, comunque, qualsiasi scelta (alcune più alcune meno) sia una
scommessa.
EMG

 Gia'. E Mario Lener oggi lavora per un ISP nazionale. Sigh.
Ricordo! Scriveva su Computer Programming. E di passaggio lo lessi anche
su Fidonet alcuni anni fa.
EMG

multipiattaforma. E quindi non è più un prodotto... :-)
CLIPPER secondo me ha di molto comoda la gestione dei code-block...
se ci fosse qualcosa di simile anche in C++ vedrei molto piu'
interessante la programmazione basata su algoritmi.
Attualmente anche la definizione di un semplice criterio di
confronto per std::sort mi sembra un po' macchinosa e obbliga
a separare il punto in cui si fa l'ordinamento dalla logica
di ordinamento. Sia CLIPPER che PERL (che molti altri linguaggi)
offrono una comodita' secondo me molto maggiore.


Comunque questa discussione comincia a stancare parecchio.
Vero. E' offtopic e non porta a nulla di interessante.


scommessa.
Ovviamente e' un problema complicato... sino ad ora si andava
sul sicuro (COBOL). Forse il C++ con un opportuno framework
di supporto potrebbe essere abbastanza high-level da risultare
una scelta sensata.
Io su Java ad esempio avrei un bel po' di timore...


sono sufficientemente "inglesicizzati" e con a disposizione una ADLS.
Io in ufficio ho una connessione mega ... pero' il file me lo
sono scaricato con il mio modemuzzo 56k. Lo streaming e'
riuscito alla perfezione. Documento molto interessante.
Ho solo fatto fatica a riuscire a salvare il file in locale ...
veramente un giro dell'oca (passando dai preferiti a non mi
ricordo piu' quali porcate).


soddisfa di veder girare il suo codice.
L'azienda per cui lavoro produce macchine. Queste macchine sono
composte di parti... che a loro volta sono composte di parti.
Ci sono i centri di lavorazione, i tecnici, i fornitori specializzati
e i terzisti. La costruzione di una macchina a controllo numerico
e' una cosa molto complicata da descrivere e da gestire.
Figurati se poi l'azienda di macchine ne produce tante... e
molto diverse... e con varianti.
Perche' dovrei buttare ogni tre anni questo patrimonio di
conoscenze ? Arrivare ad una rappresentazione della problematica
di produzione e ad un insieme di procedure che manipolano
questa rappresentazione costa un sacco di tempo. Per non
parlare della messa a punto... del riuscire ad avere tutti
i numeri giusti al momento giusto. Dei bug.
Io dovrei pensare di riscrivere tutto da capo (gia' cosa che
porta via tempo) riscoprendo tutto da capo ... rifacendo il
debug da capo e questo solo perche' Microsoft ha perso la
causa con Sun sul suo non-Java ? Solo perche' Borland ha
segato il responsabile prodotti e ha deciso di cambiare
strategia eliminando quello che per loro e' un ramo secco
e per me e' l'unica possibilita' di salvare il mio lavoro ?
Il C++ secondo me e' oggi una valida alternativa al COBOL.
5 anni fa avrei considerato solamente C e COBOL.
Ovviamente scrivere un gestionale in C e' un suicidio...
e quindi quello che avevo fatto era scrivere un interprete
in ANSI C per un linguaggio piu' comodo... anzi *pensato*
da zero esclusivamente per la scrittura della parte
server-side di un gestionale utilizzando un RDBMS (generico,
non uno specifico) come supporto per la rappresentazione dati.
Oggi sto partendo con il C++. Con qualche piccolo strato
di base (gestione rollback in caso di exceptions, gestione
di passaggio richieste/risultati attraverso strutture
molto dinamiche) mi sembra qualcosa di comodo.
E comunque non perde le premesse per essere longevo.


Scritta in COBOL.
Avevo sentito di una banca del bergamasco che invece usava
qualcosa di alternativo... come client degli X-Terminal (!)
ma non conosco nulla dell'architettura che hanno scelto.


 ma non conosco nulla dell'architettura che hanno scelto.
La Banca Popolare di Bergamo, che otto o nove anni fa era il primo
cliente Sun in Europa ed il cui responsabile dei Sistemi Informativi era
il presidente di i2u, lo Unix user group italiano. Non so come siano
messi adesso...
Ciao,
Nicola

messi adesso...
Sono sempre su X.
Luc.

 ricordo piu' quali porcate).
La cosa piu' semplice e' partire da un documento che contiene il link al file
(se non c'e' puoi sempre crearlo). Poi click destro e save as invece che open.


Sono sempre su X.
Sai anche come e' strutturata la cosa ? 2 livelli ? 3 livelli
CORBA con backend in COBOL ? C++ ? Java ?
Mi sembra di aver capito che hanno avuto problemi di banda
passante per gli allineamenti... usano DB replicati ?


CORBA con backend in COBOL ? C++ ? Java ?
E' tutto quello che ho visto dallo sportello della mia filiale...
Luc.

    WHERE ID_FATTURA=:id_fattura;
Questo l'ho visto fare con del codice C; niente piu' che un preprocessore...
Se non ricordo male era proprio con Interbase...

Se non ricordo male era proprio con Interbase...
Esatto. Usare un preprocessore e' uno dei sistemi standard
di interfacciarsi ad un DB da C o C++.
I sistemi RAD di sviluppo gestionali prevedono invece questa
possibilita' come implicita direttamente nell'ambiente...
praticamente quasi non ti accorgi del confine fra SQL e il
codice usato per gestire gli eventi della GUI (questo, come
al solito, e' a mio parere sia un bene che un male). Nessun
preprocessore da invocare, tutto trasparente.
Con PowerBuilder, ad esempio, il controllo viene effettuato
direttamente quando chiudi la funzione o l'evento in cui hai
scritto quelle righe di codice e il controllo verifica la
correttezza dello statement sotto tutti i punti di vista
(c'e' anche ovviamente di piu'... come la costruzione guidata
di statement SQL complessi che vengono poi inseriti
direttamente nel tuo codice).
