Dimensioni dinamiche degli array. perchè si e perchè no?

di il
31 risposte

Dimensioni dinamiche degli array. perchè si e perchè no?

Avvicinandomi alla programmazione in java ho notato che non è praticamente possibile creare e riempire un array con un numero di variabili sconosciuto a priori, bensì questo deve avere una dimensione standard conoscoita sin dall'inizio.
Poi se non ho capito male, per creare set di dati dinamici bisogna ricorrere alle collection.

Ma mi chiedo come mai alcuni linguaggi non sono così schizzinosi, e se io dichiaro un array poi posso tramite 10000 push aggiungergli altrettanti elementi senza alcun problema..

Perchè in java è stato deciso di impedire questo approccio che sicuramente più facile? Ci sono pro e contro che sfociano in altrettante diverse filosofie di pensiero per cui l'uno è meglio dell'altro?

31 Risposte

  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    Puoi usare Vector in java anche se è un pò obsoleto...se non ricordo male nella prima stesura di java, gli array non c'erano!
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    Devi studiare le collection di Java:

    java.util.*

    Collection -> List -> ArrayList, LinkedList, Vector, ...
    Map ->HashMap -> Hashtable

    In Java c'e' tutto quello che avresti voluto avere e mai osato chiedere .

    E se non bastasse quello che c'e' nelle librerie standard (che poi e' la parte piu' difficile dello studio di un linguaggio di programmazione: sapere che cosa le librerie standard mettono a disposizione), vai a guardarti le tonnellate di librerie della serie "commons" del progetto Apache.

    E se non ti basta, beh ci sono miliardi di altre librerie aggiuntive. E se non bastasse ancora: allora potresti inventare tu una nuova libreria .
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    migliorabile ha scritto:


    Devi studiare le collection di Java:

    java.util.*

    Collection -> List -> ArrayList, LinkedList, Vector, ...
    Map ->HashMap -> Hashtable

    In Java c'e' tutto quello che avresti voluto avere e mai osato chiedere .

    E se non bastasse quello che c'e' nelle librerie standard (che poi e' la parte piu' difficile dello studio di un linguaggio di programmazione: sapere che cosa le librerie standard mettono a disposizione), vai a guardarti le tonnellate di librerie della serie "commons" del progetto Apache.

    E se non ti basta, beh ci sono miliardi di altre librerie aggiuntive. E se non bastasse ancora: allora potresti inventare tu una nuova libreria .
    Si ho precisato che per tali eventualità ci sono pur sempre le collection, ma la mia curiosità era appunto rivolta al fatto sul perchè la libreria base di java lavora solo su array statici e perchè è stato deciso di farla lavorare così
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    Semplicemente perchè accedi a due aree di memoria diverse.
    Quando dichiari qualcosa di "statico" usi lo stack di conseguenza devi sapere a priori la sua dimensione.
    Quando invece non conosci la dimensione allora usi un'altra memoria,quella di heap.
    Ogni linguaggio permette in maniera diversa di gestire la memoria di stack e di heap,e in molti linguaggi sembra adirittura di utilizzare la stessa memoria.
    Quindi una collection userà una memoria dell'heap,mentre qli array verranno creati direttamente nello stack.
    Per ulteriori chiarimenti ricercati in internet la differenza fra stack ed heap.
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    vbextreme ha scritto:


    Semplicemente perchè accedi a due aree di memoria diverse.
    Quando dichiari qualcosa di "statico" usi lo stack di conseguenza devi sapere a priori la sua dimensione.....
    E R E S I A!

    E questa dove l'hai letta? vbextreme

    Allora: la keyword static viene usata per definire qualcosa CHE NON STA' SULLO STACK, non l'incontrario. Ma e' un oggetto globale, la cui visibilta' dipende se usi 'private' 'protected', 'public'. Comunque sia, e' sempre un oggetto GLOBALE.

    A parte i tipi primitivi, (byte,short...double che vengono allocati direttamnte nello spazio globale o nello stack), TUTTI GLI ALTRI oggetti (stringhe, vettori, classi, collezioni, ....) vengono trattati via reference ed allocati nello heap. Il reference (il puntatore in terminologia C/C++) invece, segue le regole dei tipi primitivi.

    In Java non scrivi

    static int v[128]; // NON E' supportata almeno fino alla versione JDK 8 !!!

    ma

    static int v[] = new int[128];

    e quindi usi lo heap per il vettore di interi, mentre l'area di memoria globale per la variabile 'v'.


    x American horizon: la libreria standard (o di base come dici tu) COMPRENDE le collezioni.

    Anzi, la libreria di base e' fornita con le stesse API su qualunque piattaforma Java giri.
    (Stiamo parlandao d Java e non Android o J2ME, parenti, ma non strettissimi).

    Con il solo compilatore, senza la libreria standard, puoi solo compilare, ma non eseguire alcunche', perche' ti mancherebbe l'intero framework di esecuzione (classloader, accesso al filesystem per la lettura della classe, input/output, ...).

    E poi chi ha detto che devi usare per forza una costante numerica per allocare la dimensione del vettore?

    N=2

    int v[] = new int[N*N^N];

    Genera un vettore di quanti elementi?

    Dove sta' il problema?



    Sempre se si sta parlando di Java

    PS: forti le faccine, ma serviva quella che viene bruciata sul rogo
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    migliorabile ha scritto:



    x American horizon: la libreria standard COMPRENDE le collezioni.
    Con il solo compilatore, senza la libreria standard, puoi solo compilare, ma non eseguire alcunche', perche' ti mancherebbe l'intero framework di esecuzione (classloader, accesso al filesystem per la lettura della classe, input/output, ...).
    Ne sono consaevole, ma resta il dubbio sul perchè c'è una distinzione tra array (statici) e vettori (dinamici). Non sarebbe stato meglio mettere a disposizione i vettori e bona, considerando che sono più flessibili degli array? E' chiaro che se ciò non è stato fatto una spegiazione deve pur esserci..

    Provendendo da actionscript 3 sta cosa degli array statici mi suona prorpio limitante, e se tiriamo in ballo pure il package collection, le hashmap, i vettori, bhe mi viene semplicemente il mal di testa perchè non capisco il motivo di un tale calderone di metodi che alla fine potevano essere semplificati in uno (magari non nel caso delle hashmap, ma i vettori e gli array si dato che sono praticamente la stessa cosa)
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    E poi chi ha detto che devi usare per forza una costante numerica per allocare la dimensione del vettore?

    N=2

    int v[] = new int[N*N^N];
    vabbè ma è la stessa cosa scusa ... comunque impongo una dimensione standard all'array correndo 1) il rischio di istanziare più settori di quanto in realtà ne utilizzo, 2) il rischio di non istanziarne abbastanza
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    Se ci ragioni, ci arrivi!

    Considera questo:

    1) come implementeresti, in modo ragionevolmente efficiente, un vettore dinamico?
    2) poiche' Java ha il compito di controllare le allocazioni di memoria (e occuparsi delle deallocazioni) quali sono le entita' primitive che ti servirebbero per il tuo vettore?

    E poi' perche' ti sei fissato con gli array?

    Fai finta che non esistano.

    Hai a disposizione qualcosa di alternativo, che soddisfa le tue necessita'?

    A te l'ardua sentenza.


    Mettiamola in un'altro modo: per capire perche' esistono gli array statici, e perche' sono necessari, dovresti studiare algebra (astratta) applicata alle strutture dati. O meglio, teoria dei linguaggi di programmazione. C'e' ovviamente un motivo algebrico.

    A grandi linee, viene seguita la seguente logica:

    se R e' l'insieme dei numeri reali, R^2 e' l'insieme delle coppie di numeri reali (ad esempio le coordinate bidimensionali), R^3 e' l'insieme delle terne di numeri reali (ad esempio le coordinate tridimensionali). Piu' in generale

    R^N

    e' un vettore di N numeri reali, in uno spazio a N dimensioni.

    Il vettore Java, come il concetto di vettore in tutti i linguaggi di programmazione, e' la rappresentazione computazionale di tale oggetto.

    L'array, e' l'UNIONE DI:

    R^0 U R^1 U R^2 U R^3 U .... R^infinito

    ('U' starebbe per il simobolo insiemistico di unione.)

    Tale insieme in generale viene indicato con R* (R alla star)

    Quindi il vettore e' uno dei possibili elementi di un array.

    Capito qualcosa?
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    American horizon ha scritto:


    Provendendo da actionscript 3 sta cosa degli array statici mi suona prorpio limitante, e se tiriamo in ballo pure il package collection, le hashmap, i vettori, bhe mi viene semplicemente il mal di testa perchè non capisco il motivo di un tale calderone di metodi che alla fine potevano essere semplificati in uno (magari non nel caso delle hashmap, ma i vettori e gli array si dato che sono praticamente la stessa cosa)
    Compito di una libreria standard e' quello di fornire le strutture dati piu' comuni usate per implementare algoritmi ed applicazioni nel modo piu' efficiente possibile.

    Ogni struttura dati ha specifici utilizzi e specifiche caratteristiche di performance, dinamicita', quantita' di memoria allocata, tempo di accesso, tempo di modifica.

    Quando dovrai scrivere applicazioni che devono trattare migliaia o milioni di dati al secondo, o che devono rispondere in un millisecondo o in un microsecondo, ti assicuro che la scelta della struttura dati corretta e' FONDAMENTALE. Ed averle preimplementate in nativo e' altrettanto fondamentale.
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    American horizon ha scritto:


    migliorabile ha scritto:



    x American horizon: la libreria standard COMPRENDE le collezioni.
    Con il solo compilatore, senza la libreria standard, puoi solo compilare, ma non eseguire alcunche', perche' ti mancherebbe l'intero framework di esecuzione (classloader, accesso al filesystem per la lettura della classe, input/output, ...).
    Ne sono consaevole, ma resta il dubbio sul perchè c'è una distinzione tra array (statici) e vettori (dinamici). Non sarebbe stato meglio mettere a disposizione i vettori e bona, considerando che sono più flessibili degli array? E' chiaro che se ciò non è stato fatto una spegiazione deve pur esserci..

    Provendendo da actionscript 3 sta cosa degli array statici mi suona prorpio limitante, e se tiriamo in ballo pure il package collection, le hashmap, i vettori, bhe mi viene semplicemente il mal di testa perchè non capisco il motivo di un tale calderone di metodi che alla fine potevano essere semplificati in uno (magari non nel caso delle hashmap, ma i vettori e gli array si dato che sono praticamente la stessa cosa)
    Ciao,

    in risposta (parziale) alla tua domanda, ricordo qui una risposta che già ho dato altrove sul forum; se un linguaggio di programmazione ti scatena forti dubbi e perplessità, allora quel linguaggio di programmazione NON è il linguaggio adatto a te.

    Nello specifico, Java deriva in un certo modo da C++
    Nel linguaggio C e C++ (versioni standard ovvio) non esiste neppure il concetto di un vettore ridimensionabile in automatico, perchè questa cosa è totalmente al di fuori della filosofia del linguaggio C (e quindi del C++)

    Molti programmatori che leggono e scrivono qui sul forum sono giovani programmatori, e purtroppo non hanno avuto l'opportunità di vivere in prima persona le evoluzioni storiche dell'informatica moderna (diciamo dagli anni '70 in avanti). Avendo tu queste informazioni, ti renderesti conto immediatamente che la tua stessa domanda risulta comprensibile certo, ma totalmente priva di fondamento.

    A parte il fatto che il linguaggio Java in futuro potrebbe anche essere modificato completamente, tutto è possibile, si deve partire nel ragionamento dalle caratteristiche interinseche del linguaggio C (e quindi del C++). Tale linguaggio trova la sua massima potenza nella gestione dei puntatori a oggetti in memoria, quindi gli ideatori del linguaggio hanno ben pensato che ogni struttura dimamica dovesse essere risolta via codice esplicito, nella forma di funzioni (oppure di classi).

    Inoltre il linguaggio C è stato ideato con lo scopo di offrire un linguaggio di programmazione di livello quantomeno intermedio, ovvero che permettesse una compilazione in assembly la più efficace possibile, con lo scopo quindi di evitare al programmatore la stesura di codice assembly, sollevandolo da tale compito improbo attraverso il C (o C++) e lasciando la generazione dell'assembly al compilatore. In particolare il C++ ha una filosofia ibrida, nel senso che è stato creato come un linguaggio OO comunque compatibile con il C, e le estensioni OO offrono al programmatore una "marcia in più", caricando però maggiormente il compilatore (che in effetti a volte deve generare codice un poco arzigogolato, a causa delle caratteristiche della programmazione OO, aliena al linguaggio C originario)

    Seguendo la medesima filosofia, ovvero della massima efficienza sul codice assembly (e quindi NON della massima comodità per il programmatore), si ha che ogni manipolazione di strutture dinamiche (vettori, code, alberi ecc.) deve essere ideata dalla mente del programmatore (o dai programmatori che hanno scritto le librerie di classi) perchè ogni struttura di dati dinamica necessità di suoi algoritmi specifici per essere manipolata, nel modo più efficiente possibile (non importa se poi risulti scomodo da usare, i "vecchi" programmatori erano ben abituati a soffrire... )

    E' per quello che il concetto di "vettore con auto-resize" è del tutto alieno al linguaggio C e ai suoi derivati (una soluzione generica sarà sempre inefficiente ove applicata ad un caso specifico)

    In un certo senso il linguaggio Java si accoda (e anche il C#), sostituisce i puntatori (pericolosi da gestire) con i riferimenti, ma la filosofia è quella, le strutture dinamiche le devi fare a codice, non sono automaticamente integrate nel linguaggio medesimo (nello specifico le trovi già pronte sotto forma di libreria, e non a caso non si tratta di un UNICO grande oggetto dimamico che soddisfa ogni possibile esigenza in modo inefficiente, bensì una miriade di classi specializzate che tentano di risolvere un determinato problema nel modo più efficiente possibile)

    Questa è la filosofia di base; prendere o lasciare.
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    Ok grazie per le risposte.

    Ma quindi il succo del discorso è: perchè linguaggi come php o AS3 offrono unicamente l'utilizzo di array dinamici mentre java sia l'utilizzo di array statici che di vettori dinamici?
    Ho capito che è una questione di filosofia nonché di ereditaretà da un certo linguaggio, ma c'è un reale motivo per cui si aderisce ad una determinata filosofia piuttoche che un'altra? Chessò, ci sono vantaggi di performance in java che con php e as3 non si possono avere?

    E' azzardato dire che php e as3 nel tentativo di essere più "user-friendly" peccano in efficenza risultando difatto dei linguaggi "minori" rispetto a java o c++ ?
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    Esatto!
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    American horizon ha scritto:


    ok grazie per le risposte.

    Ma quindi il succo del discorso è: perchè linguaggi come php o AS3 offrono unicamente l'utilizzo di array dinamici mentre java sia l'utilizzo di array statici che di vettori dinamici?
    Ho capito che è una questione di filosofia nonché di ereditaretà da un certo linguaggio, ma c'è un reale motivo per cui si aderisce ad una determinata filosofia piuttoche che un'altra? Chessò, ci sono vantaggi di performance in java che con php e as3 non si possono avere?

    E' azzardato dire che php e as3 nel tentativo di essere più "user-friendly" peccano in efficenza risultando difatto dei linguaggi "minori" rispetto a java o c++ ?
    Non è che sono linguaggi "minori", sono semplicemente dei linguaggi di programmazione con filosofia alternativa (e ce ne sono molti, ad esempio Occam, Prolog, Lisp ecc. ecc. )

    In particolare, i linguaggi che adottano direttamente questo genere di "utility" (esempio i vettori dinamici) io li vedo come linguaggi molto utili per uno sviluppo RAD di applicazioni, ovvero nel
    caso in cui sia necessario mettere in piedi un software funzionante in poco tempo.

    I linguaggi C e C++ in un certo senso sono scolpiti nella pietra, così sono... stop. Difficili da usare, indispensabili ove si voglia produrre codice molto efficiente, codice che deve durare anni e anni oppure girare su milioni e milioni di device (esempio splendido... il Kernel Linux)

    Java (e il C#, che in un certo senso è un suo cugino) lo hanno costruito come lo vedi oggi, ma non è detto che nel futuro non si possa cambiare filosofia, dotandolo di costrutti più "user frendly". Dipende anche molto dal feedback degli sviluppatori a livello mondiale.
  • Re: Dimensioni dinamiche degli array. perchè si e perchè no?

    Grazie ancora a tutti per le spiegazioni.
    Tirando le somme si può dire quindi che se conosco a priori la grandezza massima di una collezione di dati conviene usare sempre e comunque un array in quanto generalmente più veloce del vettore, viceversa, se proprio non posso stabilirne una grandezza precisa di una collezione, allora sono obbligato ad usare i vettori.

    Tornando ai paraogoni tra i vari linguaggi e le diverse filosofie, si può comunque affermare che l'accesso ad una collezione di dati in un linguaggio come PHP che mette a disposizione solo array dinamici (che corrispondono quindi ai vettori di java) non raggiungerà mai le prestazioni di un medesimo codice java basato su array statici.
Devi accedere o registrarti per scrivere nel forum
31 risposte