Newsgroup: it.comp.lang.c++
Titolo: Dimensioni massime matrici

Salve a tutti, premetto che ho già cercato su google ma non ho trovato nulla 
in merito.
Sto scrivendo un programma molto semplice in C++ per un esame, ma non riesco 
ad uscire dal seguente maledetto errore (per brevità vi posto solo il pezzo 
di codice che mi da' problemi):
# include<iostream>
const int vertex = 500;
int main ()
{
     float adiacenze[vertex][vertex][5];
system("PAUSE");
return (0);
}
Appena eseguo (uso Dev-C++ su XpSP2, se mai fosse utile da sapere) mi killa 
il processo, e non è confortante considerando che il mio valore di vertex 
reale è intorno a 1500...
Considerando che la mia disperazione è ad alti livelli, non è che qualcuno 
saprebbe ridrmi un po' di speranza e farmi capire dove e perchè sbaglio?
Grazie a tutti!
F.P. 

 di codice che mi da' problemi):
Prova così:
# include<iostream>
const int vertex = 500;
float adiacenze[vertex][vertex][5];
int main ()
{
system("PAUSE");
return (0);
}
Oppure allora adiacenze dinamicamente.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 }
Ok, funziona!!! Grazie!!!
Sapresti anche dirmi perchè dichiarando la matrice nella main non funziona? 

 Sapresti anche dirmi perchè dichiarando la matrice nella main non funziona?
Perché le variabili locali vengono allocate sullo stack che ha una dimensione 
limitata mentre quelle esterne vengono allocate nell'heap che è molto più 
grande.


 grande.
Aggiungo anche per completezza, che potresti incrementare la dimensione 
dello stack, volendo; ma le altre due soluzioni che ti hanno proposto 
sono quasi certamente migliori.
  bye
	av.

 grande.
uhm ... pensare che ero convinto che la memoria per le variabili 
static e/o di scope globale , o cmq a ciclo di vita persistente 
e preallocate prima che si entri in main e distrutte dopo che si 
esce da mein, fosse distinta dallo heap (che ritenevo essere la 
memoria riservata alle sole variabili "dinamiche" e gestita a 
mano da new/delete e a ciclo di vita variabile).
Sei sicuro che la stessa regione di memoria possa contenere 
variabili di queste categorie liberamente mixate ?
Per quanto riguarda le extern, la sola direttiva extern può 
anche essere solo una dichiarazione (dal che non si capisce il 
tipo di storage class e il ciclo di vita della variabile) o 
anche definizione (e di solito in questo caso è global o static 
... forse anche heap, non saprei, non l'ho mai visto ma ciò non 
implica niente).
Mi interessa capire bene questo punto, perché forse mi troverò a 
doverlo spiegare a mia volta a terzi e non vorrei cominciare 
subito con una cavolata
ciao
Soviet_Mario


 Per quanto riguarda le extern,
Ho detto esterne, non extern. Esterne nel senso di definite esternamente alle 
funzioni.


 queste categorie liberamente mixate ?
No, di certo non vengono mixate. Infatti le variabili esterne non sono 
dinamiche (nel senso che hanno un indirizzo fissato per tutta la durata 
del programma) e quindi vengono "allocate" al momento dell'avvio 
dell'eseguibile. Credo che sostanzialmente all'avvio il programma chiede 
al sistema operativo un blocco di memoria per metterci tutte le 
variabili statiche (le dimensioni di questo blocco sono note a priori) e 
  le inizializza. Lo heap viene gestito chiedendo al sistema operativo 
altri blocchi di memoria, da utilizzare quando il programma chiede una 
nuova allocazione. Lo stack pure verrà richiesto all'inizio 
dell'esecuzione... e se sfori le dimensioni non c'è alcun controllo (se 
non dal sistema operativo).
E.

 che lo standard imponga qualcosa al riguardo.
In effetti, lo Standard non prevede nulla a proposito di come la memoria
deve essere organizzata. L'unico concetto definito nello Standard che ha
rilevanza in questa discussione è quello di 'lifetime', che può essere
'statico', 'dinamico' o 'automatico'. Il primo è quello degli oggetti
globali (variabili globali e membri statici), il secondo è quello degli
oggetti allocati con 'new' e il terzo è quello delle variabili locali e dei
temporanei.
Max

      float adiacenze[vertex][vertex][5];
Ciao, ti hanno dato tutti risposte molto valide ma la mia osservazione è 
che con dimensioni di memoria così grandi è meglio puntare 
sull'allocazione dinamica.

 standard imponga qualcosa al riguardo.
Nello standard l'unico uso della parola heap è quando descrive la
struttura dati nella libreria standard. Idem per lo stack. 
Non c'è scritto come deve essere gestita la memoria.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 funzioni.
Ops, hai ragione ! Ho capito e tradotto letteralmente in 
inglese, e poi ne è uscito un significato errato. Esterne come 
lo intendevi è circa sinonimo di "globale", in effetti, per cui 
il senso era giusto, lo avevo frainteso io.
ciao
Soviet


 <?Manu*> sulla gestione concettuale dei tre blocchi distinti 
La distinzione tra memoria "statica", "dinamica" e "automatica"  viene 
citata anche nello Stroustroup. Penso che, al di la' delle 
implementazioni, sia il modo "giusto" di pensare.
E.

 sull'allocazione dinamica.
Perché se l'array ha dimensione fissata?
E.

 ha scritto nel messaggio 
news:4zzPh.3165$tx6....@tornado.fastwebnet.it...

Condivido.


proprio errata, secondo voi ?
Diresti una mezza verità, probabilmente, anche perché il C e il C++
sono linguaggi studiati per lavorare su piattaforme che manco lo sanno
cos'è lo stack o l'heap :-)

 cos'è lo stack o l'heap :-)
Non mi posso permettere impostazioni troppo rigorose. Cmq vorrei 
evitare di instillare gravi vizi di forma già dal principio 
(anche se già ne hanno, in quanto non sanno il concetto id 
funzione e pensano che il programma sia MAIN e le direttive 
include le incollano all'inizio, ma di nuovo l'idea di libreria 
non è ancora nota. Insomma, sono in pista ma senza ruote e senza 
volante).
A essere sincero non so io come proverei a risolvere il 
problema. Le ore di informatica sono poche, moltissimi, benché 
siano/saranno (lo saranno ? mah) periti elettronici, non sono 
interessati o non capiscono molto facilmente anche concetti 
elementari, perché poveracci arrivano dalle medie come mamma 
l'ha fatti. Sono anche da sempre convinto che la programmazione 
non la puoi studiare solo su un libro perché lo devi fare ma in 
fondo non ti piace, senza una vasta esplorazione in proprio e 
tanti bisticci col compilatore e il debugger che ridimensionano 
le varie fantasie.
Boh
Cmq grazie a tutti dei vari pareri
ciao
Soviet

problema. 
Se vuoi un consiglio, cambiate rotta e dirigetevi su Python.
Python ha meno complicazioni, ha un interprete che ti fa dialogare
subito col sistema, ha maggiori astrazioni per le strutture dati e che
possono rivelarsi più divertenti da usare. Non diventeranno dei maghi
di Python, ma gli piacerà sicuramente pasticciare un po' col
linguaggio e vedere da subito i successi o gli errori.

 lunga piů importanti).
+1 su tutta la linea.
E tra l'altro mi chiedo quale sia il vero senso di fare "C/C++" alle
superiori. C++ č troppo complesso per affrontarlo bene (oltre che ho
dubbi sul fatto che i docenti in media siano in grado di spiegarlo per
bene invece che come C + Classi).
Su C, beh, ci si puů chiedere se sia meglio un approccio didattico che
parta dal basso e dalla macchina (per cui lavorando in C si vedono come
funzionano le cose a basso livello) oppure se sia il caso di fare
ragionare i ragazzi sul 'problem solving' e scegliere un linguaggio che
riduca al minimo i problemi estrinseci al compito svolto. Sono due
approcci distinti, ciascuno dei quali ha dei vantaggi. Ma la scelta
dovrebbe essere meditata e non a caso.


 linguaggio e vedere da subito i successi o gli errori.
+1


 non dal sistema operativo).
In effetti i problemi di stack overflow non dovrebbero più esistere su 
piattaforme recenti. Si tratta solo di memoria usata concettualmente per 
scopi diversi. Più che altro si tratta di un limite "mentale" di cui 
molti OS, compilatori e programmatori non riescono a liberarsi.
Kiuhnm

piattaforme recenti.
I problemi di stack overflow permangono fintantoché le nuove
piattaforme gestiscono lo stack come spazio limitato.
Tu conosci piattaforme che allocano stack dinamicamente?
p.s.: siamo OT.

 Tu conosci piattaforme che allocano stack dinamicamente?
Se parliamo di hardware, è possibile accrescere lo stack in modo 
efficiente già a partire, in ambito Intel, dall'80386 (forse anche 
dall'80286).
Il metodo è semplice. Si riservano i soliti (Windows) 3 GiB di spazio al 
programma (il GiB più alto è condiviso), ma li si suddivide in dati e 
stack nel seguente modo:
----- D
stack
stack
vvvv  C
^^^^  B
dati
dati
dati
----- A
Il descrittore dei dati (ds, es) avrà base A e dimensione B-A, mentre 
quello dello stack (ss) base D (sic) e dimensione D-C. Quando viene 
generato un segfault, si procede incrementando B se si tratta di ds o 
es, o decrementando C se si tratta di ss (naturalmente si mappano le 
pagine mancanti). Quando C-B < delta, si comunica che lo spazio 
d'indirizzamento è insufficiente e quindi l'utente può decidere se 
uscire da alcune chiamate ricorsive o deallocare strutture dati.
Con i processori IA-64 viene meno pure il limite dei 4 GiB (si passa a 
2^34 GiB) quindi stack e dati possono estendersi praticamente senza 
limiti (in realtà si potrebbero già usare "pagine grandi" per arrivare a 
64 GiB, ma vi sono problemi di granularità da risolvere).
Kiuhnm

 linguaggio e vedere da subito i successi o gli errori.
eh .... Si, il feed back sin da subito in effetti sarebbe molto 
utile per rendere appetibile uno strumento più di uno che ti 
presenta uno schermo nero con due cifre stampate (quando 
sottobanco poi già decantano la versione craccata di Vista e le 
varie finestre trasparenti ... c'è troppo scollamento, mi rendo 
conto, ahimè).
E Python ha framework o librerie grafiche per realizzare 
semplici interfacce utente, finestre e altri ammennicoli, senza 
impazzirci dietro ? Mi daresti qualche link se ti ricordi ?
ciao
Soviet

impazzirci dietro ? Mi daresti qualche link se ti ricordi ?
http://www.metaslash.com/python10/
Ma in ogni caso, cercando GUI Python su Google viene fuori
l'impossibile (come al solito) ;-)

 Tu conosci piattaforme che allocano stack dinamicamente?
Aggiungo a quanto detto da Kiuhnm: solitamente il limite dello stack e'
solo una sicurezza (e.g. per bloccare una ricorsione andata male), non
una limitazione tecnica. Su linux, ad esempio, il limite di 8MiB può
essere modificato a piacere (a patto di avere i privilegi necessari);
tecnicamente lo stack e' limitato solo dallo spazio virtuale
disponibile, che su piattaforme a 64bit e' una buona approssimazione di
infinito ;)
Luca
-- 
"La Via prosegue senza fine."
	Bilbo Baggins - Il Signore degli Anelli - J.R.R. Tolkien

infinito ;)
No, aspetta, un conto è parlare di limite virtuale (e su questo siamo
banalmente d'accordo: ovviamente dipende dallo spazio disponibile), un
conto è il limite fisico impostato: lo stack, da che so io, è *sempre*
limitato, quindi lo "stack overflow" non è un'eventualità del passato,
è voluta e persiste.

 C++ per DOSSSSSSSSSS :.( 
Non usare ASSOLUTAMENTE questo compilatore per insegnare il C++, faresti 
solo danni. Lo dico per esperienza personale, io ho iniziato il C++ 
proprio su quello, e mi ci è voluto un mezzo lavaggio del cervello per 
poi riuscire a imparare il vero C++. Il problema non è della Borland, ma 
quel compilatore è uscito quando il C++ non era ancora maturo.
E.

 diretto di fare certe cose.  
Mi pare che abbia già risposto. Quei ragazzi dovranno addirittura 
imparare l'assembler. Dunque il C è un ottimo compromesso. Io penso al C 
come ad un ottimo linguaggio assembler indipendente dal processore.
Se gli capiterà di programmare un microprocessore per un forno a 
microonde, dubito che potranno usare python. Invece conoscere il C gli 
sarà utile.
E.

 Se parliamo di hardware,
<snip su tutto il polpettone OT>
Non si sta parlando di hardware, per cortesia.  Lo so bene che lo
stack è espandibile e come ho affermato io stesso lo è da sempre.
Quella che hai dato nel tuo messaggio è un'informazione imprecisa, lo
"stack overflow" è un'evenienza comunque possibile.

 "stack overflow" è un'evenienza comunque possibile.
Parlare con te è una perdita di tempo. Stravolgi tutto quello che gli 
altri dicono.
Kiuhnm

 altri dicono.
Io non stravolgo un bel niente, tu invece sforzati di capire ciò che
gli altri dicono.
Tu hai affermato:
"In effetti i problemi di stack overflow non dovrebbero più esistere
su
piattaforme recenti"
E questa è una cosa errata, perché i "problemi" di "stack overflow"
persistono eccome, a prescindere che una piattaforma sia "recente" o
meno.
Che lo stack sia, poi, manualmente modificabile non aggiunge nulla al
discorso di base.

 microonde, dubito che potranno usare python.
Be', Python è un linguaggio che si sta evolvendo e la cui applicazione
sta divenendo sempre più consistente.
Non è detto che presto non sia utilizzabile anche per la
programmazione embedded.
Io eviterei d'avere certi dubbi ;-)

 piattaforme recenti"
Da quanto ho scritto in seguito, si dovrebbe capire che quel 
"dovrebbero" è usato come in "Dovrebbero proprio smettere di fumare!".
Quindi sto dicendo che tale limite non dovrebbe più esistere, ma 
purtroppo esiste ancora. In questo caso l'italiano è un po' ambiguo.
Kiuhnm

 Io eviterei d'avere certi dubbi ;-)
Boh, cmq (e chiudo il thread che avrà già stufato i più), il 
linguaggio in programma è un dato di fatto immodificabile, la 
piattaforma non so (spero di no, e infatti premevo per 
aggiornare il Turbo per Dos in quanto davvero datato e anche 
limitato, ma in realtà temo di si). E in tutta la faccenda 
volevo giusto un parere se fosse appropriato definire una 
gestione logica della memoria in quelle aree funzionali di cui 
si era detto. Al riguardo ho sentito pareri non del tutto 
universalmente condivisi. Ci penserò su tenendo conto delle 
varie opinioni.
Ah, e se mi capita, consiglierò di nuovo di buttare a mare 
TurboC++ per DOS, che sarebbe già un obiettivo.
Ciao a tutti
Soviet




 limitato, ma in realtà temo di si).
Piuttosto che usare il Turbo C++, esiste, per esempio, il djgpp, che
altro non è che il porting del gcc per DOS/Windows, con tanto di RHIDE
che sostituisce perfettamente l'IDE del Turbo C++ con lo stile Turbo
Vision dell'epoca. Almeno il gcc è aggiornato.

 Tu conosci piattaforme che allocano stack dinamicamente?
Su piattaforma PPC lo stack in se e per se *non* esiste. E non esistono
nemmeno istruzioni privilegiate push e pop.
Semplicemente *per convenzione* i sistemi operativi che girano su PPC
scelgono un'area di memoria da usare come stack. Ma ribadisco, è una
convenzione: potresti fare il LaforgiaOS che non soffre di
stack-overflow.


 è voluta e persiste.
Non ti seguo. Limitato da cosa? Non sono pratico degli internals di
windows, ma ti posso dire con certezza che con Linux lo stack può
crescere indefinitamente, nei limiti dello spazio di indirizzamento
disponibile (e della memoria fisica, se l'overcommit non è abilitato) e
di eventuali restrizioni imposte dall'amministratore.
Luca
-- 
Non ho ancora capito se il mio cane e` maschio o femmina:
quando fa la pipi` si chiude in bagno

 nemmeno istruzioni privilegiate push e pop.
Sì però in realtà si stava parlando del C/C++, e in questi linguaggi 
esiste il concetto di stack, di heap, e di memoria statica (ad essere 
precisi lo heap non fa parte del linguaggio C, in quanto l'allocazione 
dinamica si ottiene solo tramite funzioni di libreria). E' importante 
distinguere questi concetti. E bisogna sapere che lo stack (come pure lo 
heap e la memoria statica) non sono illimitati.
E.

stack-overflow.
Non ho nessuna intenzione di fare un LaforgiaOS (potremmo discutere,
di grazia, senza ricondurre ogni cosa sul piano personale?).

Non ti seguo. Limitato da cosa? 
E' strano perché in fondo non mi sembra di affermare cose così
difficili da capire.  Te la faccio semplice: lo stack è un'area di
memoria.  Quest'area di memoria ha una dimensione 100,
all'applicazione je parte una ricorsione di troppo, tenta di usarne
101 e... bam! va in stack overflow. Due soluzioni:
1) lo stack si espande a "run-time" al crescere delle esigenze, quindi
lo stack overflow non lo si raggiunge mai;
2) per il prossimo utilizzo, lo ridimensiono a 200, col rischio che a
201... bam! si rivà in stack overflow.
La faccio semplice, quindi: 1 o 2 ?

 La faccio semplice, quindi: 1 o 2 ?
1.
Luca
-- 
Il coraggio non mi manca.
E` la paura che mi frega...

 di grazia, senza ricondurre ogni cosa sul piano personale?).
Non è questione di 'personale' è un modo breve per indicare "il tuo
personale sistema operativo fatto da te". Mi spiace che te la sia presa.
Il punto è questo: se vuoi fare su PPC un OS che non soffre di stack
overflow, puoi. Beh, certo, alla fine puoi esaurire tutta la memoria, ma
quel punto il fatto critico non è lo stack overflow, ma il fatto che hai
finito la memoria.


 dinamica si ottiene solo tramite funzioni di libreria).
Il concetto di heap non compare da nessuna parte nello standard del C++,
e nemmeno quello di stack. O per lo meno ne io ne il find lo abbiamo
trovato, potrebbe comunque essermi sfuggito.


 gli stack overflow.
Riformulo: la strada per prevenire gli so nel software non passa per la
loro impossibilità teorica su un'eventuale piattaforma.


 trovato, potrebbe comunque essermi sfuggito.
La memoria dello "heap" è quella allocata con "new" e "delete". Quella 
dello stack è la memoria allocata dalle dichiarazioni non static 
all'interno delle funzioni e dalle variabili temporanee. Tutto il resto 
è memoria statica. Anche il "tempo di vita" di una variabile è un'altro 
modo per vedere questa triplice suddivisione: la durata del programma è 
il tempo di vita delle variabili statiche, tra "new" e "delete" quello 
delle variabili dinamiche, dalla chiamata al "return" di una funzione 
quello delle variabili automatiche.
E.

 all'interno delle funzioni e dalle variabili temporanee. 
Ma il termine *heap*, non compare. In C++ la differenza da standard fra
memoria statica e dinamica riguarda la policy di allocazione e
deallocazione (e guarda caso visto la semantica della memoria statica si
presta benissimo ad essere implementata con uno stack. 
Ma in se e per se lo standard C++ non dice nulla oltre il comportamento
di allocazione e deallocazione: se sotto la macchina tenesse tutto in
heap, gestendo però correttamente la semantica delle variabili
automatiche, sarebbe tutto a posto.
Un comportamento come quello di sopra potrebbe essere quello di un
*interprete* C++ (per esempio usato per farci degli studi etc). 


 convenzione *software*, ma non deriva da come funziona l'hardware.
Chi ha mai detto che c'entri l'hardware?

 meri tecnicismi di basso livello.
Molto dipende da cosa devi fare invece; all'università ho avuto un 
professore fissato per il Java che ne decantava inesorabilmente le 
grandissime "qualità"....ma che cazz...perchè devo usare un linguaggio 
che decide per me tutto? (binding dinamico sempre, allocazione di 
oggetti dove vuole lui, passaggio degli argomenti come vuole lui....ecc 
ecc). E poi mi vengono a dire: "java è portabile"....per forza gira su 
una macchina virtuale!!
Insomma, secondo me C è un linguaggio che insegna a programmare molto 
più di tanti altri linguaggi ed è giusto che sia studiato a fondo. Dopo 
accenni a python, non l'ho mai usato e quindi non so dire niente, però 
java, che è da molti ritenuto "il linguaggio didattico" è una gran 
schifezza! Va bene per la programmazione web, ma per il resto...? Non so 
se hai mai avviato eclipse; bhè se hai intenzione di usarlo dopo pranzo 
allora avvialo prima di andare a mangiare, che forse dopo il caffè è 
partito (guarda caso, è scritto in java!)
Saluti, Alberto

 partito (guarda caso, è scritto in java!)
Suggerirei allora che tu cambiassi abitudini alimentari o computer.
Sulla mia macchina (tra l'altro MacOS X, dove Java è un po' più lento
che altrove) ci impiega 30 secondi a partire per il primo avvio, una
decina di secondi per i successivi.
Quindi o tu mangi davvero in fretta, oppure hai un computer davvero
antidiluviano.
Tra l'altro visto quello che lasci intendere (fare notare che è scritto
in Java) denota chiaramente che non hai perfettamente compreso il
problema.
Python è (per esempio) un linguaggio di livello ancora più alto di Java:
ma *parecchio* più alto. Sfortunatamente questo fa si che sul codice
computazionale sia ancora più lento. Eppure gli IDE in Python non sono
affatto lenti: partono velocissimamente.
Il problema di Java non è che è lento (se vai a vedere un po' di bench,
ti accorgerai che è si più lento di C++, ma parecchio veloce nella media
dei linguaggi), ma che le sue librerie grafiche sono lente. E lo sono
perchè sono overingegnerizzate alla follia.
Tra l'altro il fatto che Java 'sia interpretato' è una mezza verità:
infatti alla fine la roba passa per un JIT, per cui dopo le primissime
computazioni, viene in effetti eseguito codice macchina nativo,
compilato a tutti gli effetti. 


 Chi ha mai detto che c'entri l'hardware?
Pardon: avrei dovuto dire la macchina astratta di livello inferiore.
Nel caso di un compilato C su PPC, la macchina astratta di livello
inferiore è appunto dato da OS (che nel caso riguarda le ABI) e
hardware.


 una macchina virtuale!!
Beh, io avrei qualcosa di ridire sulla portabilità di Java. Mi è 
capitato diverse volte di non riuscire ad eseguire i codici dei 
tutorial! In effetti il linguaggio è portabile, il problema è che non è 
detto che su due macchine ci siano le stesse librerie. Ad esempio 
programmare in Java sui telefonini è un vero inferno. Per avere un gioco 
che funziona su tutti i modelli bisogna farne circa un centinaio di 
versioni diverse.
E.

 perchè sono overingegnerizzate alla follia.
Appunto, e i sostenitori di questo linguaggio elogiano le swing come se 
fossero la manna del programmatore!
Ciao, Alberto

 decina di secondi per i successivi.
Io, quando lancio un programma, dopo 5 secondi penso che si possa essere 
impallato e dopo 10 lo termino. :-)
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 
Grazie! Uno che la pensa come me :-) Io i 10 secondi li concedo solo a 
quei 2-3 programmi con i quali sono amico intimo....tipo kde o openoffice!!!

 fossero la manna del programmatore!
E a me cosa me ne frega dei talebani di Java? Dicano quello che
vogliono. Tu digli GridBagLayout e li vedrai impallidire.


 impallato e dopo 10 lo termino. :-)
O beh, come vuoi. Ma non iniziare ad usare Photoshop  (C++).


 bottiglia sono gli accessi a db 
Ahahah vorresti scrivere un web-server in java....parli per parlare 
allora, non c'è dubbio! E comunque nelle TUE applicazioni forse i colli 
di bottiglia sono negli accessi ai db
 > o ad altre risorse e/o chiamate di sistema in genere.
Ok...accesso ai dischi? Creazione di socket? Dimmi te..in ogni caso Java 
non può competere.
Ma poi...se Java non ti piace, perchè lo difendi? :D
Interrompiamo questa discussione, sta diventando faticosa e tanto ognuno 
resta delle proprie idee
Ciao, Alberto

 Ma poi...se Java non ti piace, perchč lo difendi? :D
Perchč tu dici cose false. Se tu dici che Berlusconi ha tre braccia, io
ti faccio notare che di braccia ne ha solo due, anche se mi sta sulle
palle.


 partito (guarda caso, è scritto in java!)
Eclipse lo uso tutti i giorni, ma ho visto ambienti di sviluppo Java
che sono veramente degni di nota (vedi IntelliJ e Net Beans).  La
questione, come sempre, non è il linguaggio in sé, ma ciò che con esso
si realizza e come lo si realizza.  Vorrei evitare una trita e ritrita
guerra di religione sui linguaggi, comunque.

 fossero la manna del programmatore!
Swing ?!... ma a che versione sei rimasto?

 di bottiglia sono negli accessi ai db
I colli di bottiglia di QUALUNQUE applicazione sono l'I/O (accesso ai
file, al DB, ecc...)

 
Le awt? fa lo stesso...anzi, pur avendole usate molto poco, mi paiono 
ancora più lente

 versioni diverse.
Vedi sopra: è un problema di supporto da parte del particolare
telefono.

 basso livello.
In realtà, no, non è *necessario*. Diciamo che è il modo più comodo e
che porta una serie di altri vantaggi, per cui la stragrande maggioranza
dei linguaggi 'portabili' girano su vm.


 dimmi anche che, ad esempio, la parte per il supporto alle gui fa cagare!!
Java è un linguaggio la cui vocazione e impiego principale è lo
sviluppo web e tutto ciò che ruota attorno a Java tende ad ottimizzare
la creazione di *QUESTO* tipo di interfaccia, *NON* delle GUI.  Oggi
praticamente nessuno utilizza Java per scrivere applicazioni con GUI
come le intendi tu.  Lo sviluppo "serio", con Java, viene fatto con la
piattaforma JEE (ex J2EE).

 ancora più lente
Si, come no.


 sicuri, affidabili non li useresti? 
non è una questione di Aut Aut, comunque.
Se ti serve fare una serie di case più o meno standard, convene 
usare più pezzi prefabbricati possibile. Ogni volta che dovessi 
avere bisogno di adattare il design a contesti abbastanza 
particolari, saper usare i mattoni e la cazzuola non guasterebbe 
però.
Ai nostri periti a volte serve dialogare con gingilli che si 
autoprogettano, di cui stabiliscono i protocolli e tutto quanto. 
Non è il caso in quel contesto scomodare una libreria gigantesca 
quando ti basta scriverti due funzioni di lettura/scrittura su 
campi di bit su porte logiche a indirizzi prefissati di memoria.
Poi nel futuro professionale probabilmente chi diventerà 
programmatore amplierà assai il suo arsenale.
CUT ALL
ciao
Soviet

Quello che mi pare di aver capito da questa discussione, è che la 
portabilità del codice dipende in gran parte dalla disponibilità di 
buone librerie. Il Java le ha perché la SUN ci ha speso un sacco di 
risorse per rendere il nuovo linguaggio appetibile. Inoltre (per vari 
motivi) non ci sono librerie che competono con quelle ufficiali. Il C++ 
pure ha delle ottime librerie, ma non c'è un unica fonte, e quindi 
nessuna libreria è ubiquamente diffusa.
E.

 nessuna libreria è ubiquamente diffusa.
Tutt'altro, il C++ è portabile proprio perché standard e la libreria
standard è molto ricca.
Il problema è che con le sole caratteristiche standard, generalmente
ci fai molto poco di concreto, quasi sempre, invece, devi integrarti a
meccanismi specifici della piattaforma (ma questo vale anche in Java).

 meccanismi specifici della piattaforma (ma questo vale anche in Java).
Ma io sto pensando a libreria per i socket, per la gestione di finestre, 
per la stampa etc... Perché se uno si limita alla libreria standard di 
sicuro il C++ (ma anche il C) non ha (quasi) nessun problema di portabilità.
Un'altra peculiarità del Java (in quanto interpretato) è che dà la 
possibilità di eseguire i programmi in modalità sicura, in una sandbox 
(si dice cosi?), in modo tale che si possa eseguire codice senza il 
rischio di compromettere il sistema.
E.

 sicuro il C++ (ma anche il C) non ha (quasi) nessun problema di portabilità.
Se trascuri quisquilie come endianess, dimensione degli interi e altre
questioni correlate. Per esempio nello standard C99 c'è una sezione
intera di cose implementation defined. Molte sono sciocchezze, altre
invece possono nascondere seri problemi di portabilità.


 file, al DB, ecc...)
Sei un po' troppo GENERALE nelle tue osservazioni, quando uno scrive 
qualunque tutto maiuscolo obbliga quasi chi ha un'esperienza contraria a 
rispondere, e` per questo che questo innocuo thread e` arrivato a sto 
numero assurdo di messaggi :)
Bye,
  Gabry