[C] Leggere File Strutturati

[andbin]

Guarda ... dal mio punto di vista (non so dal tuo), leggere ed interpretare un file come quello che ho postato, è relativamente semplice ed è comunque il problema "minore".
La cosa a cui prestare maggiore attenzione, secondo me, è come gestire "in memoria" tutta la struttura della Tassonomia. Bisogna quindi utilizzare delle strutture dati apposite che facciano da "contenitori" per i dati della Tassonomia.
Volendolo fare in "C" e senza utilizzare librerie esterne, direi che bisogna pensare a come realizzare una struttura ad albero facilmente gestibile ed espandibile. Putroppo il "C" non ha di base delle funzioni e/o librerie standard per la gestione dei "contenitori" (siano essi Liste, Code, Hashtable, ecc....) come in altri linguaggi (vedi Java). E a meno di usare appunto librerie esterne, sono da costruire "a mano".

Vediamo il problema nel dettaglio. Intanto devo dire che mi ero sbagliato sulle proprietà: pensavo che dovessero avere un valore (avevo messo @proprietà=...) ma rileggendo il documento ho capito che non è così ed ho già corretto il mio post.

Ogni nodo della Tassonomia è composto da:
- Il nome della categoria.
- Un numero N di proprietà.
- Un numero M di sottocategorie.

Per le proprietà e le sottocategorie si può usare una semplice lista linkata, se non ci sono altre esigenze specifiche (es. cercare velocemente una proprietà o una sottocategoria).
Adesso ci penso.

[leadergl]

riguardo la struttura da utilizzare per memorizzare al meglio i dati credo di aver già postato la soluzione migliore per questo caso.

ad ogni modo devo usare una struttura ad albero, e credo che l'esempio fornito sia ad ok in quanto prevede che i nodi dello stesso livello (fratelli) siano trattati come una lista linkata in modo da non avere limitazioni sul numero e da poter variare il numero degli elementi ad ogni livello dell'alberto, uguale per quanto riguarda invece il "sotto-albero" di ogni nodo che va trattato allo stesso modo...

[andbin]

Ok, partiamo dalle proprietà, che è una parte abbastanza semplice. La struttura dati per le proprietà io l'ho pensata così:

/*-------- Proprieta` --------*/
#define LEN_NOME_PROPRIETA  40    /* Lunghezza che si vuole */

typedef struct tassonomia_dati_prop
{
    char nome[LEN_NOME_PROPRIETA+1];
} TASSONOMIA_DATI_PROP;

typedef struct tassonomia_nodo_prop
{
    TASSONOMIA_DATI_PROP         datiprop;
    struct tassonomia_nodo_prop *prev;
    struct tassonomia_nodo_prop *next;
} TASSONOMIA_NODO_PROP;

typedef struct tassonomia_list_prop
{
    TASSONOMIA_NODO_PROP *head;
    TASSONOMIA_NODO_PROP *tail;
} TASSONOMIA_LIST_PROP;

Ovviamente una TASSONOMIA_LIST_PROP (una lista di proprietà) farà poi parte di ogni categoria e quindi di ogni nodo della Tassonomia. A questo punto ci sarebbe da scrivere (come minimo) le funzioni per a) inizializzare la lista, b) inserire una proprietà, c) liberare (free) la lista e se si vuole, d) enumerare le proprietà.
Nota, ho pensato di usare le liste double-linked perché le trovo sempre le più comode e veloci da gestire. Cosa ne pensi?

[leadergl]

la parte che non capisco è questa:

typedef struct tassonomia_list_prop
{
    TASSONOMIA_NODO_PROP *head;
    TASSONOMIA_NODO_PROP *tail;
} TASSONOMIA_LIST_PROP;

mentre questo:

/*-------- Proprieta` --------*/
#define LEN_NOME_PROPRIETA  40    /* Lunghezza che si vuole */

typedef struct tassonomia_dati_prop
{
    char nome[LEN_NOME_PROPRIETA+1];
} TASSONOMIA_DATI_PROP;

typedef struct tassonomia_nodo_prop
{
    TASSONOMIA_DATI_PROP         datiprop;
    struct tassonomia_nodo_prop *prev;
    struct tassonomia_nodo_prop *next;
} TASSONOMIA_NODO_PROP;

è in pratica la struttura che avevo proposto prima più o meno...dove:
*prev = figlio
*next = fratello

non capisco bene che struttura verrebbe fuori inserendo l'altra parte, ti ricordo inoltre che anche l'esercizio parla di "Alberi Radicati"...

cmq spiega meglio l'idea della tua struttura...

=== AGGIUNTA ===
dalla tua struttura verrebbe fuori una lista di Alberi Radicati....giusto?

[leadergl]

la mia idea era una struttura di questo tipo:

#define LEN_NOME_PROPRIETA  40

struct Albero_Tassonomia
{
    char[LEN_NOME_PROPRIETA+1] Valore_Nodo;
    struct Albero_Tassonomia *figlio;
    struct Albero_Tassonomia *fratello;
};

#define Albero struct Albero_Tassonomia

[andbin]

No no .... alt. Io ho voluto inziare dalle proprietà ma non ho ancora completato tutta la struttura della Tassonomia. Io in genere preferisco scrivere il codice in modo che sia molto modulare e le strutture dati molto "incapsulate".
Le strutture che ho fatto con il nome xxx_PROP sono solo esclusivamente per le proprietà, non c'è alcun figlio! È solo una lista di proprietà e basta.
Una variabile di tipo TASSONOMIA_LIST_PROP farà poi parte di un'altra struttura che costituirà una categoria. (calma che ci arrivo!)

Originariamente inviato da leadergl

#define Albero struct Albero_Tassonomia

Non fare mai una cosa del genere!
Semmai:

typedef struct Albero_Tassonomia Albero;

Questo in generale.

[leadergl]

Quello che non capisco è perchè creare una struttura dati così complicata quando quella che ci basta è un semplice albero non binario in cui ogni livello dei nodi può avere un numero variabile di nodi....e questa struttura è proprio quella di figura:


che non è altro che un generico albero che non impone alcuna limitazione sul numero di figli di ciascun nodo (compreso la radice)...

perchè vuoi usare quella struttura complicata? dov'è che stai cercando di arrivare? vorrei capire anche io...



========== AGGIUNTA ==========
quella figura altro non è che questo albero:

[andbin]

Originariamente inviato da leadergl

Quello che non capisco è perchè creare una struttura dati così complicata quando quella che ci basta è un semplice albero non binario in cui ogni livello dei nodi può avere un numero variabile di nodi....e questa struttura è proprio quella di figura:

che non è altro che un generico albero che non impone alcuna limitazione sul numero di figli di ciascun nodo (compreso la radice)...

perchè vuoi usare quella struttura complicata? dov'è che stai cercando di arrivare? vorrei capire anche io...

L'immagine che hai riportato, è giustissima. Il classico albero gestito a liste linkate in cui ogni nodo ha N figli e M fratelli. Nel disegno, ogni rettangolo arrotondato rosso è una categoria ("Veicoli da trasporto", "Per Mare", ecc...) ma tieni presente che ognuno di essi dovrà avere anche una lista di proprietà!

[leadergl]

scusa la lista di proprietà non può tranquillamente essere definita da altri nodi dell'albero di livello maggiore?

come ad esempio il nodo centrale di livello 1 ha 4 figli che potrebbero tranquillamente essere 4 proprietà oppure 3 proprietà ed una ulteriore categoria che a sua volta avrà altri figli=proprieta e/o categorie....

che ne pensi?

[leadergl]

no, hai ragione, i nodi dell'albero (come dice il testo) devono contenere solo i nomi delle categorie; quindi le proprietà di ciascusa categoria vanno messe a parte e le possiamo benissimo rappresentare come una lista...

si ok, mi trovo con te....ma a questo punto potremmo semplicemente
aggiungere un campo alla struttura:

#define LEN_NOME_PROPRIETA  40

struct Lista_Proprieta
{
    char[LEN_NOME_PROPRIETA+1] valore;
    struct Lista_Proprieta     *next;
};

typedef struct Albero_Tassonomia
{
    char[LEN_NOME_PROPRIETA+1] Categoria;
    struct Lista_Proprieta   *proprieta
    struct Albero_Tassonomia *figlio;
    struct Albero_Tassonomia *fratello;
} ALBERO_TASSONOMIA;

visto che cmq ogni categoria avrà le sue proprietà...

che ne dici?

[andbin]

Originariamente inviato da leadergl

scusa la lista di proprietà non può tranquillamente essere definita da altri nodi dell'albero di livello maggiore?

come ad esempio il nodo centrale di livello 1 ha 4 figli che potrebbero tranquillamente essere 4 proprietà oppure 3 proprietà ed una ulteriore categoria che a sua volta avrà altri figli=proprieta e/o categorie....

che ne pensi?

Che così non ha molto senso. Primo, ti complichi la vita. Secondo, come la gestisci? Come differenzi tra categoria e proprietà? Ci metti una variabile che fa da tag? Sia la categoria che la proprietà hanno un nome (es. char nome[...]; ). E se volessi farli lunghi diversi? E se volessi aggiungere un campo ad ogni proprietà?

Insomma ... io cerco sempre di incapsulare il più possibile, anche se la cosa può risultare lunga o strana.

[leadergl]

ti sei perso un mio post, questo: http://www.hwupgrade.it/forum/showpo...5&postcount=30

[andbin]

Guarda <questo> post che avevo fatto in un thread iniziato da -Ivan-.
Avevo postato una semplice gestione di una coda (queue) in "C".
Osserva le funzioni queue_insert() e queue_extract(). Hanno un parametro di tipo queue_data* e la struttura queue_data contiene solo ed unicamente il dato da gestire. Non contiene next, prev o qualunque altra cosa che non sia attinente al dato da gestire. In questo modo ho disaccoppiato il dato dalla gestione interna della coda.
Così, a chi usa le suddette funzioni, non gliene frega niente di sapere come è fatta la coda e che c'è un prev o un next nella coda!!

Per il momento ti devo salutare, ci risentiamo nei prossimi giorni. Adesso sto per uscire e stasera c'è la finale di ballo su Rai1 (e non la perdo!).

[leadergl]

...up...

[leadergl]

ok, alla fine ho scelto questa come struttura file:

Veicoli da trasporto|3|proprieta1
Per Mare|0|proprieta1
Da Terra|2|proprieta1
Su Rotaia|0|proprieta1
Su Ruote|0|proprieta1
Per Aria|0|proprieta1

in pratica è:

Nome_Radice|numero_sottonodi|proprieta_1|...|proprieta_N
Nome_nodo|numero_sottonodi|proprieta_1|...|proprieta_N
...
Nome_nodo|numero_sottonodi|proprieta_1|...|proprieta_N

ovviamente se il <b>numero_sottonodi</b> di Nome_Radice o di Nome_Nodo è maggiore di ZERO allora successivamente verranno elencati i suoi sottonodi per poi proseguire normalmente.

Il tutto sarà opportunamente analizzato da una funzione ricorsiva....credo che così vada bene, che ne dite?