Passaggio di un numero arbitrario di parametri

[clros]

• 

Cosa  pensate del sistema TagList che usa Amiga (liste di strutture tag/valore) per passare un numero arbitrario di parametri ad una funzione?

[TheKaneB]

• 

Mi sembra un metodo utile, in mancanza di strumenti più adeguati lato linguaggio.

[clros]

• 

Mi sembra un metodo utile, in mancanza di strumenti più adeguati lato linguaggio.

Ok, c'è però una cosa che mi lascia qlk dubbio:nel caso in cui il secondo membro del tag (il valore) indichi un indirizzo.
Nella struttura di commodore è di tipo ULONG (32 bit (??) senza segno)
Esiste un modo per indicare il tipo un generico indirizzo che si "adatti" all'architettura della macchina/compilatore (32 o 64 bit?)

[TheKaneB]

• 

chiaro che sia a 32bit, infatti gli indirizzi virtuali del 68000 sono proprio a 32bit (anche se alcuni modelli di CPU avevano meno linee fisiche, ma i registri avevano quella ampiezza).

Il tipo generico che si adatta da solo è size_t, che è un typedef definito come un tipo intero di lunghezza adeguata a contenere la differenza di due puntatori.

void * (oppure char * per compilatori molto vecchi) è esattamente della stessa dimensione, ma ha il significato proprio di puntatore.

Quindi per parametri generici è meglio usare void *, mentre per numeri interi di lunghezza pari a quella di un indirizzo della macchina, meglio usare size_t. In base ai vari #define, infatti, size_t potrebbe essere un unsigned long, unsigned int, unsigned long long, ecc... (dipende da OS e compilatore).

[rebraist]

• 

Dopo la spiegazione di shinkuro che mi ha aperto il cielo in merito a set e get, proprio in questi giorni sto buttando giù delle cosette nelle quali necessito delle taglist.
Se sono un meccanismo che per alcuni versi facilitano la scrittura di funzioni con numero variabile di argomenti dall'altro hanno, derivata dalla stessa intrinseca implementazione di boopsi, una serie di "peculiarità" che a mio avviso sono strane. Non limitanti, ma strane.
La guida di morphos a riguardo porta tutta una serie di operazioni fattibili con le taglist e alcune sono esoteriche a dir poco. Ma se tali operazioni sono possibili significa che qualcuno ne ha sentito la necessità.

[TheKaneB]

• 

Il problema non è tanto della libreria, che è discreta. Il problema è del C che ti costringe a fare i salti mortali se vuoi implementare qualcosa che sia Object Oriented, inventandosi design pattern eccessivamente convoluti che tentano di modificare il linguaggio stesso tramite uso massiccio di #define che non fanno altro che offuscare ancora di più il reale codice nascosto dietro certe strutture.

[clros]

• 

Se sono un meccanismo che per alcuni versi facilitano la scrittura di funzioni con numero variabile di argomenti dall'altro hanno, derivata dalla stessa intrinseca implementazione di boopsi, una serie di "peculiarità" che a mio avviso sono strane. Non limitanti, ma strane.

Per esempio?

[TheKaneB]

• 

Evitate l'uso dei variadic parameter, sono unsafe e non ottimizzabili. Ci sono alternative decisamente migliori

in questo caso specifico mi pare che non si parla di ellipsis e vararg, ma si parla di normali array di struct, costruiti usando delle macro per semplificarne la costruzione e lettura. Il problema di questo approccio è che l'insieme di macro crea una sorta di linguaggio dentro il linguaggio, una feature del C che odio sinceramente "cu tuttu u sintimentu" (con tutto il cuore).

[TheKaneB]

• 

Mi correggo, effettivamente questi taglist vengono creati usando delle funzioni helper che contengono ellipsis/vararg  :twisted:

cfr: http://code.google.com/p/guidetoamigaco ... /CAP_4.txt

[clros]

• 

Evitate l'uso dei variadic parameter, sono unsafe e non ottimizzabili. Ci sono alternative decisamente migliori

Quali?

[clros]

• 

@TheKaneB:
Sai di cosa mi sono accorto? Che se metto il campo della struttura TagItem a void *, non posso passare costanti (almeno, non credo si possa risalire all'indirizzo di una costante e, se anche fosse, questo non sarebbe più valido all'uscita dello scope). Ecco perchè nella struttura TagItem di Commodore il campo ti_Data è un ULONG. Questo consente di fare cose del tipo:

MYTAG_NameTag,true,
MYTAG_NameTag2,5,

cosa che non poso fare usando come tipo void *.

Stavo pensando ad una soluzione alternativa...

[clros]

• 

@TheKaneB:
Sai di cosa mi sono accorto? Che se metto il campo della struttura TagItem a void *, non posso passare costanti (almeno, non credo si possa risalire all'indirizzo di una costante e, se anche fosse, questo non sarebbe più valido all'uscita dello scope). Ecco perchè nella struttura TagItem di Commodore il campo ti_Data è un ULONG. Questo consente di fare cose del tipo:

MYTAG_NameTag,true,
MYTAG_NameTag2,5,

cosa che non poso fare usando come tipo void *.

Stavo pensando ad una soluzione alternativa...

[TheKaneB]

• 

certo che puoi passare costanti, basta fare il casting (void *)5. Ma void * è utile SOLO per passare indirizzi, per parametri interi che siano lunghi quanto un indirizzo, usa size_t.
Quasi sempre size_t è un typedef che rimanda a unsigned long.

[clros]

• 

certo che puoi passare costanti, basta fare il casting (void *)5. Ma void * è utile SOLO per passare indirizzi, per parametri interi che siano lunghi quanto un indirizzo, usa size_t.
Quasi sempre size_t è un typedef che rimanda a unsigned long.

Hai ragione, ho provato ora  fare il casting e funziona! Perchè mi faccio sempre queste seg*e mentali??  :lol:
 Però...void * a questo punto è "universale" (posso usarlo per indirizzi e costanti), size_t posso usarlo con la stessa disinvoltura anche per memorizzare indirizzi che siano dipendenti dalla piattaforma in uso (32/64 bit)?

[clros]

• 

insomma..esiste un tipo in cui poter memorizzare "tutto" in C?