🚀 go-pugleaf

On Sun, 18 Sep 2005 11:40:18 +0200, Pierre Habouzit wrote:

>> 
>> Pourquoi cela au-dessous ne suffirait-il pas ? :
>> 
>> struct message {
>>     [ ... pleins de choses dont pas mal de 'headers' ...];
>>     blob_t *__bufs[2];
>>     [ ... encore pleins de choses ...];
>> };
> 
> parce que lorsque je code et que j'utilise ma structure de message, je ne
> veux pas passer par __bufs et �crire des msg->__bufs[0] ou msg->__bufs[1]
> et me souvenir lorsque je code que __bufs[0] est mon buffer originel, et
> bufs[1] celui o� je fait mes modifs.

#define ORIGINAL 0
#define MODIFIED 1
( ou l'�quivalent avec enum )

Quand on veut explicitement acc�der � un des buffers.
soit : 
msg->__bufs[ ORIGINAL ] 
msg->__bufs[ MODIFIED ] 

Quand on veut  y acc�der sans savoir s'il a �t� ou non modifi�, se
servir du bit modified,
Je ne vois rien d'obfuscant l� dedans.

Je ne pense pas que rajouter des donn�es inutiles dans des structures
puisse simplifier la lecture d'un programme, personnellement c'est
plut�t un truc qui me laisserait perplexe et soup�onner une siouxerie
pas nette en le lisant.

> Dans mon module C je veux utiliser msg->original et msg->scratch qui eux
> sont clairs, et en plus comme original a un const en plus, il m'�vite
> la b�tise d'aller le modifier si je ne suis plus tr�s r�veill�.

Le const en plus peut, par contre �tre un bon argument, mais je ne pense
pas qu'il soit d�terminant.

Dans ce cas mets juste 2 pointers et des macros ou fonctions inline
get_buf_original( msg )
get_buf_modified( msg )

et une autre macro qui se sert du bit modified.

Je ne vois vraiment pas la raison pour s'emb�ter avec des struct et des
unions, c'est obfuscatoire.