Newsgroup: it.comp.programmare
Titolo: Struct e Array

Mi servirebbe un chiarimento:
E' preferibile (dal punto di vista del software intendo, non del
programmatore) usare una struct tipo:
struct foo
{
    double A;
    double B;
    double C;
};
oppure un array tipo:
double foo[3];
Grazie per le eventuali risposte.
Martino.

 double foo[3];
E' preferibile la seconda forma in quanto le strutture sono proprio state
create per "racchiudere" oggetti diversi.
Usarle per 3 double non ha senso e, per lo stesso motivo, non hanno la
comodità degli indici.
Prova a scrivere una struttura equivalente a:
double foo[1024];
:-)
oppure a realizzare il seguente ciclo usando una struttura anzichè un array:
for (int i = 5; i < 256; i++)
    foo[i] = foo[i-5] * foo[i-4];
Kiuhnm

 ha scritto nel messaggio
news:sXZY8.88112$vm5.3...@news2.tin.it...

Grazie!
Era la conferma che volevo... ;-)
Martino

 comodità degli indici.
non vedo perche` devi generalizzare in questo modo; come in ogni cosa, 
dipende dai casi; tanto per fare un esempio banale:
struct Point {
        int x;
        int y;
};
vuoi forse dire che tu useresti un array?
ciao Anto
-- 
Antonio Cuni, 20 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 vuoi forse dire che tu useresti un array?
Ci puoi scommettere!
 typedef int point[2];
 point p1, p2;
 p1[0] = 3;
 p1[1] = 5;
 p2[0] = 6;
 p2[1] = 5;
In questo modo posso usare indici numerici, cosa che con la struttura non
puoi proprio fare.
La tua struttura non offre nessun vantaggio rispetto al mio array :-)
Per es. nei motori grafici ho sempre visto usare e usato personalmente:
class vector
{
    double v[3];
public:
    vector();
    ~vector();
    ecc...
};
Kiuhnm

La tua struttura non offre nessun vantaggio rispetto al mio array :-)
A parte essere 10000 volte più leggibile.
-- 
Marco Barisione (ICQ 84277092)

 wrote in message
news:1rkbjusf10for8rji...@4ax.com...


Questione d'abitudine...
Kiuhnm

 comodità degli indici.
a parte il piccolo particolare che "oggetti diversi" non dipendono solo
dal tipo ma anche dalla semantica dei valori!
senza sapere che voglio dire A,B,C non puoi dire nulla...
l'esempio del punto con x e y e' in questo senso IMHO a meta' via,
ed interpretabile correttamente in entrambi i modi.
prova pero' a fare lo stesso ragionamento con la seguente struct:
struct foo
{
    double velocita;
    double spazio;
    double tempo;
};
credi ancora che un array sia "preferibile"?
(si intende come usabilita', giusto?)
potra' essere al massimo uguale ma moooooolto meno leggibile!
--
Ciao by Allanon
"The programmer, like the poet, works only slightly removed from pure
thought-stuff.
He (or she!) builds his castles in the air, creating by exertion of the
imagination.
Few media of creation are so flexible, so easy to polish and rework, so
readily capable
of realizing grand conceptual structures."
              -- Fred Brooks (The Mytical Man Month)

 potra' essere al massimo uguale ma moooooolto meno leggibile!
Se pensi che forse ti serviranno gli indici è preferibile.
const int velocita = 0;
const int spazio = 1;
const int tempo = 2;
typedef double foo[3];
foo[velocita] = .3e7;
foo[spazio]  = 0;
foo[tempo] = 0.5;
Ma veniamoci incontro:
typedef struct
{
    union
    {
        struct
        {
            double velocita;
            double spazio;
            double tempo;
        };
        double v[3];
    };
} foo;
foo prova;
prova.tempo = 0;
prova.velocita = 3;
prova.spazio = prova.v[0];
prova.v[1] = prova.tempo;
:-))))
Kiuhnm

 Questione d'abitudine...
il codice non deve essere leggibile dal solo programmatore che lo ha 
scritto, ma anche dagli altri.
E se un tuo collega non e` "abituato"?


 E se un tuo collega non e` "abituato"?
Si abitua...
Kiuhnm

Si abitua...
Spero di non lavorare mai con te (o meglio spero di essere il tuo capo
:-)).


 :-)).
Questo sarą difficile :-))) (mi riferisco alla seconda che hai detto)
Kiuhnm

 Questo sarà difficile :-))) (mi riferisco alla seconda che hai detto)
Fortunatamente per lui ;)
Io uno come te lo licenzierei ;))

 La tua struttura non offre nessun vantaggio rispetto al mio array :-)
Offre il vantaggio (ENORME) che cio' che e' contenuto al suo interno
puo' essere una collezione di dati logicamente legati tra loro e
questo ha molta importanza in fase di design del programma.  Spiegami
come sostituiresti con un vettore una struttura contenente i dati
eterogenei relativi ad una persona (nome, cognome, eta, stipendio,
...).  Conosco gia' la tua risposta, solo che ancora non l'ho scritta
perche' sto aspettando che il brivido sulla schiena mi passi: scrivo
tanti vettori per ogni proprieta'.  BRAVO ! avrai quindi, che la
funzione che accetta i dati di una persona, anziche' assumere la
forma:
void ElaboraDati(TPersona P);
sara' 
void ElaboraDati(const char *cognome, 
                 const char *nome,
                 int eta,
                 double stipendio);
Oltre a risultare assolutamente illeggibile rispetto alla prima forma,
assolutamente "error-prone", visto che posso dimenticare facilmente un
campo o passarne uno per un'altro, in questo modo disaccoppi
informazioni che, per loro definizione, *devono* rimanere accoppiate,
con lo scomodo svantaggio risultante che se decidi di aggiungere un
campo alla struttura della persona in questione, sei tenuto a
modificare TUTTE le funzioni che accettano i dati di una persona come
parametri e ricordati che piu' scrivi, piu' sbagli.
Comincia a scrivere programmi da qualche centinaia di migliaia di
codice e poi ne riparliamo ;)

 wrote in message
news:bfaaa329.02071...@posting.google.com...

Anche questo sarà difficile :-) (mi riferisco alla seconda che hai detto)
Kiuhnm

 tanti vettori per ogni proprieta'.  BRAVO !
[cut]
Spero solo che Kiuhmn avesse scelto l'array visto che i 3 campi della struct
sono dello stesso tipo (scelta che cmq non condivido). Se veramente volesse
usare l'array al posto della struct anche in presenza di campi
eterogenei.....mi sta salendo il tuo stesso brivido :)
Ciao, Davide :)


Kiuhnm

"Davide Hops" <david...@REMOVEyahoo.it> wrote in message
news:h1TZ8.101256$vm5.3...@news2.tin.it...

Chi va con lo zoppo.......
Solo un *coglione* userebbe
la struttura
struct vector
{
    double x, y, z;
}
Garantito...
Kiuhnm


Ok, mi scuso x il tono del post precedente e cerchiamo ora di tornare su un
discorso piu' serio.
Ho scritto di non condividere la tua scelta perche', dai tuoi post, mi
sembra di capire che tu sceglieresti sempre ed incondizionatamente la
soluzione con l'array[1].
Io invece penso che la scelta vada fatta in base al dato da rappresentare
(dato che va visto nell'ottica dell'applicazione).
Supponiamo che tu debba rappresentare i dati di una persona (Cognome e Nome)
useresti un array di 2 elementi o una struttura contenente due campi
stringa?
[1]Ovviamente mi sto riferendo al caso in cui i campi della struct siano
dello stesso tipo; in caso di campi eterogenei penso che entrambi
conocordiamo nell'uso di strutture.
Ciao, Davide :)

 stringa?
Userei una struttura perchè i due campi Cognome e Nome non hanno relazioni
matematiche definite o almeno il mio prg. probabilmente non ne farebbe uso.
Nel caso di un vettore (x, y, z), le operazioni matematiche sono invece
innumerevoli (prod. esterno, interno, matriciale, ecc...) e quindi è stupido
non poter usare le definizioni matematiche (che usano guarda caso gli
indici) perchè si è deciso di usare una struttura.
E comunque ripropongo la struttura che ho già postato in un altro messaggio:
typedef struct
{
    union
    {
        struct
        {
            double velocita;
            double spazio;
            double tempo;
        };
        double v[3];
    };
} foo;
foo prova;
prova.tempo = 0;
prova.velocita = 3;
prova.spazio = prova.v[0];
prova.v[1] = prova.tempo;
:-))))
In più quando uso il C per cose di basso livello uso questa bella union:
typedef union
{
    BYTE *b;
    WORD *w;
    DWORD *d;
    void *v;
    DWORD dd;
} mptr;
Mi evita un mucchio di cast inutili ed irritanti...
Kiuhnm

 Anche questo sarà difficile :-) (mi riferisco alla seconda che hai detto)
difficile ma non impossibile, mi riferisco alla prima che hai detto
-- 
"The problem with the world is that everyone is a few drinks behind"
-- Humphrey Bogart, actor

 difficile ma non impossibile, mi riferisco alla prima che hai detto
No, no è proprio impossibile (dovrei licenziarmi da solo :-))) )
Kiuhnm
P.S. il mio tono è scherzoso...conoscendomi non avresti motivo di
licenziarmi....

 diversi...svegliati che è meglio...
Amico, sei tu che dai l'idea di vaneggiare: hai affermato che solo un
coglione racchiuderebbe x, y, z in una struttura.  Parli di non-sense
quando il vero non-sense e' nelle tue parole.  Se gli elementi hanno
lo stesso tipo o se il loro tipo e' diverso non cambia affatto le
cose: una struttura che racchiude tutti i membri e' oggettivamente
piu' vantaggiosa di tanti array di oggetti quanti sono i membri.  Non
e' possibile usare un vettore per contenere oggetti di tipo diverso,
quindi nessuno stava parlando di questo.

 racchiuse in un'unica struttura.  Tra l'altro, prova con il tuo
Nessuno lo vieta, ma
struct vector
{
    double v[3];
}
è consigliato rispetto a:
struct vector
{
    double x, y, z;
}
oppure se serve:
struct vector
{
    union
    {
        double x, y, z;
        double v[3];
    }
}
E' inutile che io continui a risponderti: le premesse erano sbagliate...
Kiuhnm

}
Anche se penso che funzioni su qualsiasi piattaforma e con qualsiasi
compilatore correttamente, sei sicuro che sia completamente standard?


 compilatore correttamente, sei sicuro che sia completamente standard?
Non vedo perchč non dovrebbe esserlo. La union č sempre esistita...forse lo
standard obbliga che le venga dato un nome: non ricordo...
E comunque avete preso le mie affermazioni e avete incominciato a costruirci
sopra cercando di confutarle in tutti i modi possibili.
La domanda originale posta da "Anonymous" (bel nome) era:
------
Mi servirebbe un chiarimento:
E' preferibile (dal punto di vista del software intendo, non del
programmatore) usare una struct tipo:
struct foo
{
    double A;
    double B;
    double C;
};
oppure un array tipo:
double foo[3];
------
Ho risposto che č preferibile la seconda. Lui mi ha chiesto "dal punto di
vista del software". La seconda forma č equivalente alla prima in tutto e
per tutto (sono sempre 3 QWORD) perň la seconda forma porta generalmente a
scrivere codice piů compatto (specialmente se i double diventano tanti).
La forma che preferisco č comunque questa:
typedef struct
{
    double v[3];
} vector;
Kiuhnm

Non vedo perchè non dovrebbe esserlo.
Il problema è che non è detto che la struttura formata da "x", "y" e
"z" occupi tre volte la dimensione dei double. Un compilatore potrebbe
decidere di aggiungere un byte dopo ogni double e penso sarebbe
comunque conforme allo stadard (anche se non so se avrebbe senso in
questo caso).


 scrivere codice più compatto (specialmente se i double diventano tanti).
Si potrebbe obiettare che il codice scritto e` piu` compatto perche` usi
cicli, ma il compilato, al di la` di ottimizzazioni, puo` essere piu` grosso e
lento, perche` usa cicli e verifiche al posto di semplici move in memoria. :)
Cmq, io sono dell'idea che la cosa migliore e` scrivere il codice come lo si
comprende meglio, soprattutto con programmi lunghi.
E fare un vector puo` essere intuitivo quando si ragiona in vettori, ma
completamente disorientante quando si parla di altro.
Per farti un esempio di cattiva programmazione, sto bestemmiando su un
software che usa una variabile che si chiama priv2 per definire un delay e
magic per definire un lock...
In pratica il modo migliore e` quello piu` intuitivo, secondo me. Meglio se e`
intuitivo per tutti (uno standard di qualche tipo, come puo` essere la
notazione fisico/matematica per i vettori)
Bye.

 ha scritto nel messaggio
news:ahh6m7$st90p$1...@ID-94575.news.dfncis.de...

Infatti ho cmq. usato una struct perché in relazione al mio stile di
programmazione mi piace di più e l'ho ritenuto più leggibile.
Il dubbio mi è nato spulciando alcuni sorgenti che usavano degli array per
la rappresentazione di quei dati usando delle macro per riferirsi
correttamente ai singoli elementi, e mi sono domandato se fosse derivato da
esigenze differenti rispetto alla praticità.
Martino.

 wrote in message
news:bs6oju8o2ifjbdah0...@4ax.com...

Sarebbe un compilatore un po' stupido...un allineamento di 64 bit dovrebbe
proprio bastare...e comunque non aggiungerebbe mai un byte dopo ogni double
(9 bytes???) al limite dopo i 3 double...e questo lo farebbe anche con
l'array.
Kiuhnm

 magic per definire un lock...
Non lamentarti: almeno hai il codice sorgente in medio/alto livello... :-)
Kiuhnm

Sarebbe un compilatore un po' stupido...
Probabile, ma quello che chiedevo č se puoi esserne (secondo lo
standard, non secondo il buon senso) certo che funzioni.


 standard, non secondo il buon senso) certo che funzioni.
Sě, ne sono certo perchč la union puň essere utilizzata soltanto per
racchiudere oggetti di stessa lunghezza e quindi non modificherebbe in alcun
modo la struttura.
Kiuhnm

 }
Huh ? Consigliato ? ma dove ? ma quando ? e soprattutto DA CHI ???
A mio avviso, non e' affatto vero cio' che affermi, non vedo perche'
dovrebbe essere cosi'.  La prima forma mi sembra molto meno leggibile
della seconda e non ha ALCUN vantaggio rispetto alla seconda.

 scrivere codice più compatto (specialmente se i double diventano tanti).
 
Assolutamente falso, dimostra cio' che affermi con i fatti.

 racchiudere oggetti di stessa lunghezza
Ma dove sta scritto ???
Chi mi vieta di scrivere:
union MyMix {
  char     c;
  int      i;
  long     l;
  unsigned u[50];
};

racchiudere oggetti di stessa lunghezza
Come della stessa lunghezza?


 Come della stessa lunghezza?
Avete ragione entrambi :-)
Pensavo che le union si usassero solo con elementi della stessa lunghezza,
invece accettano anche elementi che si sovrappongono soltanto per qualche
byte iniziale.
Comunque il discorso non cambia. Se il C mette a disposizione una "union"
allora avrà l'accortezza di non paddare la parte "sovrapposta". Mi sembra
ovvio, altrimenti le union servirebbero a poco...
Kiuhnm

Vi saluto....si vede che non avete proprio nient'altro da fare che parlare
di queste cazzatine......
Usate {x, y, z} e andate a quel paese!
Kiuhnm
P.S. Con questo post mi estrometto da questo "thread perditempo"

 farebbe anche con l'array.
da nessuna parte dello standard sta scritto:
1) quanti byte occupa un double
2) quanti bit formano un byte
3) quandi byte di allineamento puo'/non puo` mettere il compilatore
hai dimostrato a piu` riprese di ignorare alcune regole del C... fossi in 
studierei il linguaggio prima di discutere di elementi stilistici...
ciao Anto
-- 
Antonio Cuni, 20 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

allora avrà l'accortezza di non paddare la parte "sovrapposta".
Perché?


 Perché?
Perchè le union sono state fatte anche per accedere una stessa parte di
memoria in modi diversi. Se paddi la struttura sovrapposta all'array come
fai ad accedere ai dati indistintamente con entrambi i metodi? E allora a
cosa servirebbero le union?
E comunque nel caso in cui la struttura venisse paddata, come qualcuno ha
suggerito, verrebbe paddato anche l'array visto che hanno elementi della
stessa dimensione.
Kiuhnm

 della stessa dimensione.
no, lo standard specifica esplicitamente che gli elementi di un array 
devono essere contigui in memoria.


 devono essere contigui in memoria.
E non parla delle union? Che cosa dice?
Kiuhnm

 E non parla delle union? Che cosa dice?
dice che gli elementi di una union anno lo stesso allineamento che 
avrebbero se fossero gli unici elementi di una struttura.
