🚀 go-pugleaf

harpo wrote:

> On Sat, 17 Sep 2005 21:04:24 +0200, Pierre Habouzit wrote:
> 
>> 
>> hmmm, c'est bien dommage.
>> 
>> J'ai des structures dont un des membres est l'indice dans le tableau de
>> mon union, du pointeur auquel il font r�f�rence. ca m'aurait permis de
>> faire des trucs du genre :
>> 
>>     bar->array[baz->some_index]
>> 
>> Mais lorsque j'y acc�de textuellement je voulais �viter des
>> bar->array[MY_UNION_FIRST] ... et donc pouvoir acc�der aux pointeurs du
>> tableau par leur "nom".
> 
> Excusez-moi, mais j'ai du mal � comprendre votre probl�me; ce n'est pas
> � la port�e d'un d�butant, est-ce que vous pourriez le pr�ciser pour
> que tout le monde suive ?

pour mettre un peu de background, j'ai (ou plutot j'aurais aim� avoir) une
premi�re structure :

struct message {
    [ ... pleins de choses dont pas mal de 'headers' ...];

    union {
        struct {
            const blob_t *original;
            blob_t *scratch;
        };
        blob_t *__bufs[2];
    };

    [ ... encore pleins de choses ...];
};


struct header {
    struct { /* expans�, en fait c'est un sous type */
        ssize_t start;
        ssize_t size;
    } value;

    [ ... qqs trucs ...];
    
    int modified:1;
    [ ... d'autres bits ...];
};


un blob_t est une structure qui me permet de g�rer des tableaux d'octets
quelconques (pour faire simple). et un header d�finit une sous partie d'un
des deux buffer (original ou scratch) de ma structure message.

j'ai potentiellement pas mal de header, et je ne veux donc pas y avoir de
pointeur sur un blob_t*, d'autant que j'ai d�j� d'autres bits dans la
structure.

avec une telle construction, ca m'aurait permis d'�crire :

    msg->__bufs[hdr->modified]

pour acc�der au bon blob_t qui contient la valeur du header. je voulais
�viter d'avoir � �crire :

   (hdr->modified) ? msg->scratch : msg->original;

si je n'avais gard� que la struct dans l'union, ou bien pire, d�finir des
MESSAGE_ORIGNINAL � 0 et MESSAGE_SCRATCH � 1 pour pouvoir acc�der aux deux
buffers dans mes fonctions o� je les manipule, via des
msg->bufs[MESSAGE_ORIGINAL].


mais du coup, vu que je ne peux garantir que scratch coincide avec la
deuxi�me case du tablea __bufs, je me suis r�sign� � avoir comme type pour
mes messages :

struct message {
    [ ... pleins de choses dont pas mal de 'headers' ...];

    struct {
        const blob_t *original;
        blob_t *scratch;
    };
    blob_t *__bufs[2];

    [ ... encore pleins de choses ...];
};

ce qui me force � maintenir l'invariant __bufs[0] == original et
__bufs[1]==scratch � la main, mais vu que ces pointeurs changent peu, c'est
pas trop g�nant pour moi, et autant je ne voulais pas perdre la taille d'un
pointeur en plus dans mes headers vu que j'en ai beaucoup et que j'avais
d�j� des champs de bits, mais perdre 16 octets dans la structure de message
n'est pas trop g�nant. (enfin 16 ou plutot sizof(blob_t*)*2)


-- 
�O�  Pierre Habouzit
��O                                                madcoder@debian.org
OOO                                                http://www.madism.org