Newsgroup: it.comp.lang.c++
Titolo: modifica anche banrbara di un c++ reference (&)

Chi mi sa dare un modo (anche barbaro) x modificare il valore del un
reference in modo che punti ad un oggetto diverso ?
example :
int i = 1;
int j = 2;
int& x = i;		// a questo punto x = 1
eseguire qualche cosa tipo
x = &j; 		(non e' ammessa)
x a questo punto possa valere 2 (cioe' indirizzarsi a j e non piu' a i).
grazie zec.

int i = 1;
int j = 2;
int* x = &i;     // x punta a i
x = &j;            // x punta a j
Quindi (*x) vale 2

 grazie zec.
MLO@axcdf4 23 $ cat bar.cxx
#include <iostream>
 
using namespace std;
 
int main()
{
  int i=123, j=456;
  int &k = i;
 
  cout << "k = " << k << endl;
  k=j;
  cout << "k = " << k << endl;
  return 0;
}
MLO@axcdf4 24 $ g++ -ansi -pedantic -Wall bar.cxx
MLO@axcdf4 25 $ ./a.out
k = 123
k = 456
-- 
Maurizio Loreti                      
http://wwwcdf.pd.infn.it/~loreti/mlo.html
Un. of Padova, Dept. of Physics - Padova, Italy          
lor...@padova.infn.it

#include <iostream>
 
using namespace std;
 
int main()
{
   int i=123, j=456;
   int &k = i;
 
   cout << "k = " << k << endl;
   k=j;
   // questa viene vista come una assegnazione normale di valore e non come
una variazione del reference !
  cout << "k = " << k << endl;
   return 0;
 }
Il risultato e' (corretto) : 
 k = 123
 k = 456
ma il mio scopo e' non e' di avere 
  i = 456;    <--- e non piu' 123
ma di mantenerne lo stesso valore.
 
Ovviamente la soluzione non e' usando i pointer.
Se si riuscisse  a farlo si otterrebbe un analogo di quello che viene usato
da java.
di nuovo grazie 
zec.

 ma di mantenerne lo stesso valore.
Avevo frainteso; allora qualcosa tipo
  int i=123, j=456;
  int *k=&i;
  cout << *k << endl;
  k = &j;
  cout << *k << endl;
??


YES !!!
hai qualche idea anche con dei cast molto barbari o violenti, che dir si
voglia, o mi devo rassegnare ?
come sempre grazie zec.

da java.
La semantica dei riferimenti-a-oggetti in Java e` esattamente
un sottoinsieme di quella dei puntatori in C++:
    -- possono essere nulli,
    -- sono riassegnabili.
("sottoinsieme" perche` i r-a-o Java non supportano "aritmetica
d'indirizzi", i ptr C++ si`).
I reference C++ non possono essere standard e non sono
riassegnabili nel corso della loro lifetime.
Un buon compilatore C++ ne approfittera` per ottimizzare:
    int i = 23;
    int& k = i;
    k = 35;
produrra` ad es. esattamente lo stesso codice ottimizzato di
    int i = 35;
Puo` darsi che un dato compilatore C++ sia cosi` impedito
da non saper fare simili banali ottimizzazioni, ma ne dubito.
Se ne trovi uno, e sei disposto a legarti intrinsecamente ad
esso (e tenerti per sempre le sue orride limitazioni), potrai
forse anche scoprire qualche sequenza linguaggio-macchina
per "imbrogliare" il compilatore, ed il lettore/manutentore dei
tuoi programmi, al glorioso scopo di violare clamorosamente
lo standard C++ per fare esattamente quello che potresti fare
facilmente, pulitamente, "standardamente" coi puntatori, pero`
con tanta fatica in piu` e un legame a triplo filo ad un compilatore
veramente incapace (direi che vi meritereste a vicenda:-).
Della serie "facciamoci del male"...
Alex

 }
Attenzione: così facendo tu non hai cambiato l'oggetto riferito da k
(cosa che non è possibile fare) ma hai semplicemente assegnato j ad i.
Se aggiunti
cout << "i = " << i << endl;
ti rendi conto che il valore di i è stato alterato ed ora è 456.
EMG

 
Non avendo intenzioni di gloria e di inganno nei confronti del compilatore,
in quanto sarebbero solamente nei miei confronti, e ancor piu'
non avendo nessuna voglia di farmi del male sicuramente non lo faro',
(in effetti adesso sto usando i pointer).
Il motivo di un quesito simile e' che non mi andava di usare i caratteri *
o ->
per indirizzare o utilizzare i valori quando con un reference * si omette e
-> si trasforma un .
L'unica alternativa che ho trovato per risolvere il mio problema e'
inizializzare i reference nell'area di inizializzazione del costruttore
come nell'esempio sotto :
class xxx
{
	www&	wwwref;
.....
}
xxx::xxx()
 	: wwwref( *((www*) BindObject( "www" )) )
{
}
BindObject sarebbe una funzione che mi ritorna l'indirizzo di un qualche
cosa che ho registrato il un area comune.
Sarei comunque curioso di sapere come ragiona il preprocessore/compilatore
in questo caso.
Era solamente per una questione di piu' gradevole (mio parere strettamente
personale) leggibilita' del codice
non per quel che riguarda la fase di inizializzazione, ma bensi per
l'utilizzo successivo nelle funzioni della classe.
Tutto qui.
Comunque grazie. ZEC.

 voglia, o mi devo rassegnare ?
Quello che proprio non riesco a immaginare e` a cosa ti serva fare una cosa
simile, anziche` usare i puntatori

 l'utilizzo successivo nelle funzioni della classe.
mmmm... il C++ e` un linguaggio molto flessibile, ma non bisogna esagerare. I
puntatori sono un elemento essenziale del linguaggio, e i reference sono stati
introdotti, se non ricordo male, piu` che altro per risolvere problemi legati
alla "data abstraction", cioe` per permettere cose come un overloading degli
operatori di assegnamento coerente col comportamento dei tipi base, senza dover
passare intere classi per valore, che sarebbe stato un po' difficile da
accettare. Tentare di trasformare il C++ in una specie di Java, temo che
equivalga ad andare in cerca di rogne... Inoltre e' difficile usare con
disinvoltura ed efficacemente un linguaggio se non si lasciano da parte remore
di carattere  "estetico" riguardanti lessico e sintassi. Per un programmatore
C++ gli operatori -> o * non hanno nulla di "poco leggibile", sono parte
integrante e fondamentale del linguaggio. Anzi, i reference possono essere
considerati in certe situazioni "fuorvianti" perche` nascondono l'uso dei
puntatori, cosa che in un linguaggio esplicito e poco protetto come il C++ puo`
anche essere pericoloso. E cercare di usarli al posto dei puntatori e` una
forzatura non da poco... 
Forse provieni dalla programmazione con qualche altro linguaggio di cui senti
ancora la nostalgia?
Saluti
Paolo

 
Non e' una questione personale.
Ho iniziato a programmare i 'C' nel 1987 su dei sistemi Xenix, ho visto
nascere i primi PC
con il dos 1.1 ecc, ed ho scritto parecchio codice in 'C', utilizzando
puntatori, struct, puntatori a funzioni
ed altre cose del genere, e sono circa 4 anni che sono sulla programmazione
ad oggetti ed intendo il C++.
Capirai che non e' un problema per me usare questo tipo di funzionalita'
del linguaggio, puntatori o cose
del genere, ma e' molto difficile se non oneroso (per motivi di costi del
personale dipendente) trovare delle persone
con una certa esperienza che protrebbero non avere problemi con del codice,
che per forza di cose diventa crittico.
Altresi dalle scuole superiori escono persone con conoscenza del COBOL, che
e' totalmente diverso come concetti
dal C/C++. E' gia' un problema insegnargli a non utilizzare i 'goto'.
L'intenzione sarebbe di avere due staff di sviluppo dei prodotti
(gestionali contabilita'/bolle/fatture/produzione/ecc.),
uno per lo sviluppo dell'ambiente di base con persone qualificate in grado
di comprendere a dovere le sfaccettature del
linguaggio e un altro con persone meno qualificate che tramite una serie di
classi/librerie/oggetti/tools ottiene del codice
su una scala molto piu' vasta.
 
ciao zec.

 su una scala molto piu' vasta.
E perche` allora non usare direttamente un altro linguaggio, ad esempio Delphi,
che tra l'altro per applicazioni DB e` particolarmente indicato (considerando
anche il gran numero di componenti di terze parti, freeware o a basso costo, che
possono semplificare notevolmente il lavoro)?
Oppure, se ci fosse la necessita` di riutilizzare del codice C++ che non viene
bene interfacciare con DLL, si potrebbe usare il C++Builder, e le persone con
meno esperienza potrebbero occuparsi della costruzione delle interfacce e
dell'implementazione delle funzionalita` DB piu` semplici, gestibili in buona
parte coi componenti a design time, lasciando agli altri le parti piu`
complesse.
Saluti
Paolo

che per forza di cose diventa crittico.
Personalmente credo che in questo modo non risolveresti il problema.
Simili azioni producono codice che necessita di una attenzione ed una
esperienza maggiore, se un programmatore ha problemi con i puntatori
utilizzati in modo pulito quali problemi avrebbe con del codice "barbaro"
che tende a "spezzare" le regole del linguaggio?
Paolo
----------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
  e-mail: 
mar...@cli.di.unipi.it
 
----------------------------------------------------------

 
Il codice "barbaro" verrebbe circoscritto in zone del programma in cui non
verrebbe
concessa la modifica, incapsulato dentro a delle macro.
Sbaglio o le macro della Microsoft x la gestione degli eventi e dei
messaggi
non sono il massimo della linearita' pulizia o quant'altro, ma tanta gente
le usa e magari non sa nemmeno
cosa fanno di preciso, per non parlare di come implementa i COM con le
classi wrapper ?
Che dire del fatto che i dialog generati in automatico sempre dalla
Microsoft hanno violato
il concetto del data hiding esponendo le variabili nella parte pubblica,
che se non sbaglio e' un'altro dei fondamenti della OOP ?
Anche quello che faccio lo viola in modo spudorato, registrando il pointer
di un oggetto in
una lista di associazioni label/void* per poi reperirmelo da un'altra parte
tramite la label e forzandone il cast,
d'altro canto mi funziona egregiamente.
Il discorso assume un termine filosofico piu' generale a questo punto, e
cioe' quanto di quello che e' stato
fatto dall'uomo e' stato usato a fin di bene o per scopi violenti ?
E se comunque il suo utilizzo anche per il verso sbagliato ha poi portato a
cose buone ?
Per me e' difficile rispondere o dare un giudizio.
Personalmente ritengo che riducendo il numero di istruzioni, operandi e
operatori, si ridurrebbero
le potenzialita' di introduzione di errori, (anche se il compilatore c++ e'
piu' selettivo
e quindi pone un filtro miglire rispetto al c), e quindi aumenterebbe di
conseguenza la produttivita' individuale.
Ciao ZEC.

 
Deplhi se non sbaglio e' il Pascal ad oggetti della Borland. C++ Builder
non lo conosco.
L'unica cosa che mi sembra li accomuni al DevStudio (che uso), e' la
piattaforma.
Esiste un Deplhi o un C++ Builder (con anche tutti i tools e free software
ecc.)
anche per Linux o piu' in generale x Unix ?
La mia cultura e' di matrice Unix e nel mondo Microsoft per forza maggiore
ci si adegua, 
ma tenermi una porta aperta non mi dispacerebbe.
Questo sarebbe il motivo dei due gruppi di lavoro di cui quello
"sistemistico" si occuperebbe di
sviluppare la piattaforma comune per il gruppo "gestionale".
Tieni presente che un prodotto gestionale deve (per motivi di redditivita')
avere una vita superiore ai 7/10 anni.
Comunque come dice il proverbio informatico :
Non e' certo WORD che ti scrive una bella lettera se non sai l'italiano. 
Nello stesso modo non e' il sistema di sviluppo che determina la bonta' del
codice, ma e' chi lo scrive.
Zec.

le potenzialita' di introduzione di errori,
Perfettamente d'accordo, ma non conta solo la quantita` ma anche la qualita`...
ad ogni modo bisogna anche valutare caso per caso.
Saluti,


 codice, ma e' chi lo scrive.
Sulla bonta` del codice penso influisca anche il linguaggio e la qualita` degli
strumenti che si usano. Se poi si considerano i tempi di sviluppo, le cose
possono cambiare completamente a seconda degli ambienti di sviluppo.
Saluti
Paolo

su una scala molto piu' vasta.
Intenzione certamente ragionevole, ma, se questo si vuole
fare usando solo C++, non si puo` spingere la "minore
qualifica" del secondo gruppo di persone al di sotto di certi
limiti: almeno certi elementi sintattici di base, come la sintassi
dei puntatori, per usare il C++ bisogna conoscerli.
Un'ottima alternativa puo` essere di far si` che le "persone
qualificate" confezionino le "classi/librerie/oggetti/tools"
come controlli ActiveX (e altri tipi di server COM); a questo
punto, le "persone meno qualificate" possono connettere e
comporre questi componenti senza nessun bisogno di avere
la pur minima competenza C++, bensi` usando praticamente
qualsiasi altro linguaggio: Java (con JVM Microsoft, tutti i
controlli ActiveX possono essere trasparentemente usati come
JavaBeans), Visual Basic (il COM e` il suo pane), perl, Python,
Delphi, linguaggi di scripting (JScript/Javascript e/o VBScript,
ma anche Perlscript, Tclscript, ecc ecc) magari in un ambito
HTML Dinamico... naturalmente, i componenti COM (scritti
magari in C++) possono anche essere rivestiti, arricchiti, e
composti in componenti sempre COM di livello superiore (sia
in C++, sia in VB, ecc ecc, e oggi anche con linguaggi di
script e HTML Dinamico ["scriptlet"]...).
La produttivita` raggiungibile in questi altri ambienti, secondo
me, soprattutto per operatori meno qualificati, e` MOLTO, ma
MOLTO superiore a quella che costoro potrebbero avere in C++,
per quanto gli si possa "edulcorare" quest'ultimo.  (Anche per
una persona con profonde competenze di informatica, e parlo
basandomi sulla mia esperienza personale, questi linguaggi, a
seconda del tipo di problema, possono facilmente offrire un
aumento di produttivita` nella gamma 20%-50%; nulla di
"drammatico", se vogliamo, ma, considerando le retribuzioni,
ovvero il costo orario, di personale informatico altamente
preparato e qualificato, si tratta sempre di risparmi importanti;
incapsulando in serventi COM il codice C++ che interagisce
coll'ambiente, esegue operazioni cruciali per le prestazioni, e
cosi` via, anche il personale qualificato puo` dunque, e con
frutto, passare ad usare linguaggi piu` produttivi per buona
parte del codice).
Questa strategia, oggi, non e` pienamente applicabile ad
ambienti non-Win32; se questo risultasse un problema per
una data azienda, penso che potrebbe comunque essere
interessante prendere in considerazione strategie simili,
cioe` "di componentizzazione", basate magari su Corba, o
forse su Java+JNI.
Alex

conseguenza la produttivita' individuale.
Anch'io penso che usando linguaggi piu` facili per tutti i
compiti ai quali si prestano la produttivita` aumenti; invece
di pervertire il C++, suggerisco dunque di ricorrere appunto
a strumenti piu` appropriati per i (moltissimi!) compiti facili,
riservando il C++ ai pochi piu` difficili, quelli dove la sua
indiscutibile potenza e` effettivamente sfruttata.
Alex

 
Infatti il c++ mi ispira per il fatto che il compilatore e' veramente molto
piu' restrittivo rispetto al C,
forzando gli utilizzatori delle classi a restare nei 'binari' stabiliti dal
loro ideatore.
Zec.

 
Il c++ ha molti pregi, e uno dei primo lo eredita dal suo predecessore il
C, che e' la versatilita'.
Io posso fare quello che mi pare con il C++, con qualche altro strumento no
o comunque
devo aspettare chi me lo fornisce.
E' un peccato relegarlo ad applicazioni specifiche e/o speciali, e non
divulgarlo su vasta scala come un Cobol o un RPG
quando potrebbe tranquillamente sostituirli e mandarli finalmente in
pensione.
Zec.

 
Non ho la pretesa che le persone ignorino componenti importanti del
linguaggio
come i puntatori, e' semplicemente per evitare un eventuale disagio in un
primo approccio
ad un certo modo di lavorare.
Hai per caso visto cosa ha fatto IBM con VisualAge for Java ?
Secondo me li hanno sforato tutti i limiti del buonsenso,
utilizzando un metodo visuale per impostare il codice, non le maschere
video o i frame,
nascondendo completamente quello che sta sotto come tecnologia ad oggetti.
Se non l'hai gia' visto merita una profonda riflessione.
 
Zec.

pensione.
Non sei certo l'unico a pensarla cosi`, ma e` una tesi che non mi
trova d'accordo; ritengo che un linguaggio appropriato (probabilmente
non Cobol o RPG al giorno d'oggi, ma ad esempio qualcosa come
Delphi, Python, Java, Visual Basic, PowerBuilder, ecc ecc) possa offrire, 
anche a parita` di perfetta preparazione sui due linguaggi, vantaggi di
produttivita` attorno al 20-50% per problemi tipici/normali/adatti, rispetto
alla produttivita` ottenibile in C++; a questo va aggiunto il fatto che
ottenere una preparazione "perfetta" sul C++ puo` "costare" _molte
volte_ di piu` che ottenerla per linguaggi piu` facili e semplici.
Alex

 
Cosa intendi per problema tipico/normale/adatto ?
Un saluto con piacere (non sarcasmo) ZEC.

Cosa intendi per problema tipico/normale/adatto ?
Quei problemi su cui questi vantaggi di produttivita` si realizzano:-).
Specificamente, le mie esperienze Java e VB comprendono: tipiche implementazioni
di protocolli proprietari basati su socket, con marshaling/unmarshaling di parametri, e 
cosi` via; preparazione piu` o meno RAD di interfacce GUI per funzionalita` fornite da 
"motori" gia` esistenti (controlli ActiveX, "visti come" Javabeans nel caso Java);
applicazioni GUI per il controllo di coerenza di assiemi di file con riferimenti
reciproci (ancora, usando componenti separati per certi nuclei funzionali, ma
qui inserendo anche quantita` non irrilevanti di logica operativa nell'applicazione);
parsing ed elaborazione di file di testo secondo certe sintassi; questo tipo di cose.
Non ho avuto occasione di usare "sul serio" Java ne` VB per l'accesso a database,
ho solo "giocato" col tema, ma sospetto che (sopratutto con VB+ADO) il delta di
prestazioni potrebbe essere un poco piu` rilevante in questo caso.
Al contrario, per tipici "programmi di sistema", come uno che, interagendo
con le API del sistema operativo, prenda il controllo di un altro processo
esistente e mi permette di bloccarlo, esaminarlo, modificarlo, eccetera (un
"debugger di sistema"), non prenderei in sostanziale considerazione altro
che il C++ (magari, incapsulerei le funzionalita` C++ con COM/ActiveX, per
fare poi in VB o Java la GUI e una parte della logica applicativa); e cosi` pure
per quei programmi (o componenti di essi) che necessitano di prestazioni
assolutamente ottimali (pesanti calcoli matematici, ad esempio).
Alex

 loro ideatore.
Beh, come si dice, il mondo e` bello perche` e ` vario. La tua idea di adattare
il C++ ad uso di programmatori inesperti la trovo francamente un po' strana
(come del resto quella di considerare il C++ "restrittivo"); saranno i fatti a
dimostrarti se e` una strada percorribile.
Saluti
Paolo

 
Capisco la complessita di gestione degli esempi che mi hai fatto, ho avuto
modo anchio di sviluppare del codice per RAD o usare i socket, non ho mai
usato COM, ma anni fa scrissi dei driver di sistema su un sistema
proprietario in assembler non x86.
D'altro canto non pensare che un programma gestionale sia meno complesso o
contorto. Magari non ha bisogno di certe cose particolari, magari e' molto
piu' rilevante il disegno del DB, ma su questo devono lavorarci svariate
persone per svariati anni, per poterlo implementare e manutenere senza
(ovviamente) rifarlo ogni 2 anni. La complessita' probabilmente c'e' ma e'
di tipo diverso, e' del tipo come gestire le risorse per cui piu' uno
strumento e' stabile alle fondamenta e piu' riesci a portare avanti quello
che gli hai costruito sopra. Considerare anche il fatto che le persone
vanno e vengono e i costi di avvio sono abbastanza alti.
Una curiosita', hai mai lavorato su UNIX ?
Grazie ZEC.

 
Di sicuro i fatti mi daranno ragione o torto, per tua informazione i primi
riscontri mi fanno ben sperare.
Il compilatore del C++ e' (a mio avviso) molto piu' restrittivo del C,
anche solo nel controllo formale dei parametri tra le funzioni.
Ciao e grazie ZEC.

Una curiosita', hai mai lavorato su UNIX ?
Si capisce molto...?-)  Sino a 3-4 anni fa, facevo piu` che altro il guru
di Unix (con occasionali puntate in VMS, Dos, Windows, ecc); gradualmente,
mi sono riciclato come guru di Win32, man mano che il cambiamento del
mercato ci convinceva che la domanda per le nostre applicazioni (CAD
meccanico) era sempre piu` su PC e sempre meno su Unix -- oggi
rilasciamo solo su PC con NT o Win95/98.  Il momento piu` triste e`
stato quando ho spento per l'ultima volta il PC con Linux (splendido
sistema, il piu` stabile, robusto, e performante di tutti gli Unix...!)...
non ho proprio il tempo di tenermi Unix, o Linux, come "hobby", dovendo
sapere vita-morte-e-miracoli di Win32, che e` complicato assai...:-(.
Non e` stato piu` traumatico di quanto non fosse stato in passato
riciclarmi come guru Unix "in uscita" dai mainframe e midrange IBM...:-).
C'e` un bell'articolo di Don Box (un tempo guru Macintosh, oggi guru
COM, quindi Win32 lui pure) sui "5 passi verso l'accettazione" che
inevitabilmente attraversa il "super-tecnico" costretto a migrare dal
suo sistema preferito verso Win32... si dovrebbe trovare in rete alla
sua homepage (in inglese; fu originalmente pubblicato su C++ Report).
Alex

 contorto.
Infatti. E questo soprattutto perché un gestionale deve normalmente
soddisfare le esigenze specifiche del cliente rispettando il suo, magari
assurdo, metodo di lavoro. Non sempre si riesce a convincerlo di
cambiarlo e quindi si deve per forza di cose venire ad un compromesso. E
questo rende il software spesso molto meno lineare e cristallino di
quanto uno vorrebbe.
EMG

 portabilita' ho ?
Quesito interessante. Sono curioso di sentire la risposta...
EMG

nostri governanti.
Questa "business logic" starebbe al suo meglio in "stored procedures"
del database, almeno con database decenti (Oracle, SQL Server, ecc).
Alex

Quesito interessante. Sono curioso di sentire la risposta...
Ho gia` risposto ma ricapitolo: compilare da sorgenti a codice
intermedio eseguibile su di una macchina virtuale mi offre la
possibilita` di trasportare i binari eseguibili; ma un ulteriore passo
di compilazione, dal codice intermedio a codice binario finale
_direttamente_ eseguibile, non toglie certo la portabilita` dei
*sorgenti*, che restano comunque molto piu` portabili di qualsiasi
equivalente sorgente C++ (potendo contare, nell'ambito del
paradigma Java, su forme standardizzate di accesso a GUI,
database, eccetera).
Un programma C++ "perfettamente portabile" e` limitato all'I/O a
caratteri e non puo`, non dico accedere a un database, ma neppure
scoprire che file ci sono nel directory corrente -- la libreria standard
del C++ non offre questa funzionalita`, per la quale dunque un
programma C++ deve necessariamente ricorrere a componenti
"fuoribordo".  Un programma Java perfettamente portabile e` del
tutto in grado di compiere una grande varieta` di operazioni (GUI,
database, e quant'altro).  *Inoltre*, la forma compilata-a-nativo del
programma Java puo`, volendo, essere distribuita *accanto* a
quella "di riferimento" compilata a bytecode (ho gia` portato l'esempio
di GIB) senza particolari problemi tecnici.
In pratica, un programma commerciale va testato e supportato
su tutte le piattaforme dichiarate, quindi il motto "write once, run
anywhere" (WORA) del Java e` "ingannevole" -- "write once,
debug everywhere" (WODE) sarebbe piu` vicino alla realta`.
Tuttavia, le caratteristiche di portabilita` di Java restano comunque
superiori a quelle di qualsiasi altro linguaggio, come ad es. C++.
Oggi, queste caratteristiche sono molto meno importanti di pochi
anni fa, visto che il mercato si concentra sempre di piu` su di
una architettura (per la maggioranza delle tipologie di programmi
applicativi); ma il mercato puo` "esplodere" nuovamente domani,
da questo punto di vista, e allora chi ha applicazioni scritte in Java
avra` vantaggi su chi le ha scritte in C++, anche C++ fatto con
buona attenzione alla portabilita` (naturalmente, chi avesse usato
Delphi, o Visual Basic, sarebbe allora piazzato ancor peggio).
Nel frattempo, chi scrive in Java il grosso delle sue applicazioni
(riservando il C++ ai componenti piu` cruciali per le prestazioni,
o destinati a profonde interazioni di sistema, ecc), gode comunque
di un 20%-50% di vantaggio di produttivita` (a parita` di completa
padronanza dei linguaggi), a mio giudizio; in un mercato a forte
competitivita`, un vantaggio del genere puo` essere decisivo,
soprattutto accoppiato al fatto che la maggioranza dei programmatori
puo` cosi` evitare completamente le difficolta` e sottigliezze del C++
(Java ha le sue, ma sono comunque molto meno).
Alex

questa cosa di Java interpretato... :-))
Il Patriot e` un anti-missile, usato per "difesa di punto" contro gli
attacchi di missili avversari (soprattutto missili attaccanti in tipologia
terra-terra, ma vi e` anche una capacita` anti-missile aria-terra).
Che l'asserzione sull'"essere interpretato" sia "terra terra", e`
certo vero, ma, piu` che un missile, mi pare un pistolotto (viene
si` da dire "bum!", ma non decollera` mai).
L'uso di sistemi d'arma come il Patriot sarebbe dunque inappropriato,
e voi sapete quanto io tenga all'uso appropriato della tecnologia
(sono anche socio WWF!).  La tecnologia appropriata e` qui
evidentemente costituita da torte alla panna da spiaccicare in
faccia a chi fa queste farsesche asserzioni, e ne ho gia` prenotato
una buona quantita` presso la mia pasticceria preferita.
Alex

 (Object Pascal, e C++, rispettivamente).
Scusa. Pur avendo letto RAD avevo in mente CASE che non sono la stessa
cosa. Il mio "condivido pienamente" si riferisce dunque all'uso dei CASE
ai quali peraltro si attagliano perfettamente le critiche esposte
dall'amico Mauro.
EMG

ai quali peraltro si attagliano perfettamente le critiche esposte
Beh, dipende dallo strumento CASE (Computer-Aided Software
Engineering), direi; Rational Rose, ad esempio, pur certo non privo
di difetti, non merita certo la critica che "se tu vuoi fare una virgola
anche diversa da quello che e` previsto iniziano i dispiaceri"; e`,
sostanzialmente, uno strumento di supporto per varie metodologie
di programmazione OO molto flessibili (al giorno d'oggi, anzitutto
UML, ma credo sia ancora possibile usarlo per supportare i vari
metodi che UML ha sussunto -- Booch, Rumbaugh, Jacobsen),
che permette di tenere allineate fra loro le svariate "viste" dello stesso
progetto offerte dai numerosissimi tipi di diagrammi previsti da
UML, e anche (sino a un certo punto) di avere "round trip" da UML
a codice e da codice di nuovo ad UML ("reverse engineering").
Rational Rose (essendo oggi la Rational comproprieta` dei "tres
amigos", Booch, Rumbaugh e Jacobsen, i tre piu` noti studiosi
della progettazione OO, che hanno appunto deciso di unire in
essa le proprie forze) puo` essere considerata la forza numero
uno sul mercato dell'OO Design, e quindi uno strumento CASE, 
pur, insisto, con tutti i suoi difetti, non certo ignorabile nel parlare 
del CASE nel suo complesso.  Mi sembra, comunque, che anche
altri strumenti, come ad esempio i prodotti CASE della Object
International di Coad (altro ricercatore molto noto), cioe` i vari
Together/questo e Together/quello, non siano poi da meno.
La mia soggettiva impressione (ammetto pero` di non avere
approfondito l'argomento con significative esperienze pratiche)
e` che il CASE sia maturato negli ultimi anni, con l'avvento delle
metodologie moderne di progettazione ad oggetti (che ne traggono,
direi, notevole beneficio); forse le tue esperienze risalgono a
strumenti CASE piu` antichi, come "Software through Pictures",
o altri di quella (venerabile ma superata) generazione?  Su quelli,
a suo tempo, mi ero formato anch'io il convincimento (non basato
su esperienze vastissime, ma sufficiente per convincere me e
l'azienda a non spenderci tanto tempo e soldi) che non avessero
una utilita` davvero proporzionata ai rilevanti costi.  Ma con l'OO,
mi sembra, e` diverso.  Sono comunque molto interessato a
sentire di esperienze in merito, sia positive, sia negative, e non
sono certo l'unico fra i lettori del gruppo, penso...
Alex

Salve a tutti,
Nuovo su internet e in questo ng, spero di ottenere molti contatti e
consigli, non ho alcuna conoscenza di programmazione, ma desidero cimentarmi
a traduzioni di software e ricerco un editore di risorse (possibilmente
Italiano) del tipo "RESSOUCES WORKSHOP, della Borland,   ma capace di
leggere,  files scritti in 32 bytes.  Purtroppo non ho nessuna indicazione e
quindi non so' se questo tipo di programa esiste ancora in commercio.
Ringrazierei quanti vorranno darmi indicazioni o magari vorranno spedirmi
una copia anche a pagamento delle spese reali.
Grazie a tutti  per l'aiuto che potrete darmi.

 
D'accordo i database decenti, ma non le stored procedures.
Ci verrebbe un legame troppo stretto con il DBMS.
Non mi paragonare Oracle a SQL server.
ZEC.

 mi sembra, e` diverso.
E' sicuramente cosě. Almeno lo spero.
EMG

 sono certo l'unico fra i lettori del gruppo, penso...
Secondo me i CASE OO hanno un taglio completamente diverso rispetto ai CASE
della tecnologia tradizionale.
parliamo comunque di Flussi di programma, non di ERD o OODBMS.ů
Il taglio e' generato dal fatto che e' la tecnologia sottostante che e'
fondamentalmente diversa.
ZEC.

 
Non sono d'accordo ma accetto la tua opinione.
ZEC

Alex Martelli wrote:
Riguardo ai Patriot lo spirito e' abbastanza scarso,
attento solo che le torte non ti ritornino in faccia.
ZEC

 
Grazie per l'amico, spero di essere stato accettato, nonostante le mie
tante baggianate.
opinione personale sui CASE :
Quelli x la generazione automatica del codice sono il 'cappello' ai 4gl e
quindi si rifanno a quanto detto da EnricoMaria.
Non quelli per l'analisi dei flussi.
Per quel che riguarda i RAD, sono frutto, probabilmente di quella
esperienza e viene garantita la possibilita' di sviluppare in una modalita'
standard (occorre poi stabilire quale) o libera, come se fosse un
compilatore semplice.
Il problema sorge quando ci si aggiungono le librerie fornite che estendono
quel che viene fornito insieme al RAD.
Cosa sarebbe meglio fare ?
ZEC.

 Cosa sarebbe meglio fare ?
Probabilmente utilizzarle se non si ha la portabilità come obiettivo
primario.
EMG

 eng.." di un gruppo di programmi.
Detto così sembra una cosa molto simpatica. Bisogna vedere alla lunga...
EMG

 nostri governanti.
Se stai usando Java e vedi che *veramente*, alla prova dei fatti, anche
compilato il programma e` troppo lento per le tue esigenze, puoi sempre
utilizzare un modulo separato per i calcoli scritto in C++, seguendo il
principio di usare strumenti potenti ma difficili solo quando la potenza e`
realmente necessaria.
Saluti
Paolo

processore ?
Mi pare che sia la stessa domanda che hai appena posto.
Si`, esistono "codici interni non standard ma proprietari" -- hai
gia` citato quello usato da Visual Basic, eccetera.  Naturalmente,
anche per Visual Basic come per Java, nulla impedisce, volendo,
di generare codice nativo; non si tratta di linguaggi intrinsecamente
interpretativi (esistono anche ottimi interpreti per il linguaggio C,
per facilitarne il debug -- questo non fa del C "un linguaggio
interpretato"... d'altronde, esistono, e sono commercialmente
MOLTO importanti, degli interpreti per il *CODICE MACCHINA*
[tipicamente quello di processori vecchi]: e` attraverso simili
interpreti che un PowerMac gira codice macchina 68000, un
Alpha codice macchina VAX, eccetera -- ancora una volta, non
e` certo l'esistenza di simili interpreti [generalmente chiamati
"emulatori", cosi` come la JVM e` chiamata "macchina virtuale",
ma la sostanza non cambia -- sempre traduttori e/o interpreti
sono] a rendere "linguaggi interpretati" il linguaggio macchina
del VAX, quello del Motorola 68000, eccetera eccetera).
Fra i linguaggi intrinsecamente interpretativi puoi trovare certi
dialetti del LISP (dialetti storicamente molto importanti, ma i
LISP moderni, come CommonLISP e Scheme, sono stati invece
ridefiniti in modo da perdere la caratteristica di "intrinsecamente
interpretati", e infatti esistono oggi per essi ottimi compilatori a
codice nativo), Smalltalk, SNOBOL (non certo COBOL, che su
tutti i mainframe di questo mondo gira compilato in nativo),
Tcl, Python e alcuni altri moderni linguaggi di scripting.  Spesso
gli elementi di un linguaggio che lo rendono "intrinsecamente
interpretativo" possono esserne rimossi, rendendo possibile
la compilazione nativa, a prezzi pratici molto modesti, come e`
stato fatto ormai da tanti anni per il Lisp.
Alex

 
Indipendentemente dal compilato preferisco stare su un linguaggio solo e
con quello fare quello che devo.
A questo punto la mia preferenza cade ancor piu' sul c++ (che bella la
rima!).
CIAO ZEC.

 
Mi sembra una questione di lana caprina.
Il bytecode di Java potra' essere standard ma fintanto che non ci sara' un
processore, e mi sembra che siano progetti in tal senso da parte delle
grandi case, che lo esegue direttamente senza bisogno di interpretarlo non
potra' essere un codice nativo eseguibile.
Altresi' se il codice nativo (vedi MAC e Windows o gli esempi che hai
citato) deve essere interpretato o emulato per poter essere eseguito su un
processore diverso da quello per cui e' nato, mi sembra si trasformi in un
interpretato con tanto di runtime e decadimento delle prestazioni. O
sbaglio ? 
Vorrei aggiungere che in certi casi tipo quelli che hai citato, venivano
affiancati insieme ai processori 'nuovi', nelle stesse CPU anche le vecchie
(mi sembra Honeywell facesse cose del genere), per garantire la
compatibilita' del codice eseguibile.
Domanda ?
Per poter definire un codice eseguibile, chi deve essere il runtime : la
CPU o un programma apposito ? (spero sia chiaro il senso della domanda).
CIAO a tutti. ZEC 

 CPU o un programma apposito ? (spero sia chiaro il senso della domanda).
Chiarissimo. Domanda interessante. Normalmente si intende la CPU ma in
effetti non c'è molta differenza.
EMG

 Ma questa e' una operazione veramente costosa in termini di calcolo.
Ancora non capisco in che maniera influisca il *linguaggio* che stai usando (se
e` un linguaggio general purpose)
Saluti
Paolo

 
Spero tu abbia capito io mio esempio. Per quel che riguarda la tua domanda
sul linguaggio,
probabilmente ho formulato male io la questione.
L'importanza del linguaggio e' associata al fatto che deve permettermi un
controllo totale sulle operazioni che vado a fare
senza arzigogoli che inevitabilmente peggiorerebbero la situazione. La
questione della Prepare/Parsing l'ho evidenziata poiche' mi sembrava avessi
chiesto che cosa rallentava e quando nella operazione SQL.
CIAO ZEC.