🚀 go-pugleaf

En <news:dg8rse$ha3$1@reader1.imaginet.fr>, Charlie Gordon va escriure:
> "Antoine Leca" <root@localhost.invalid> wrote in message
> news:dg3hhd$kuf$1@shakotay.alphanet.ch...
>> En <news:mn.52367d59df2fc1aa.31483@laposte.net>, Pierre Maurette va
>> escriure:
>>> Je pense qu'il n'y a qu'une seule alternative: soit respecter les
>>> conventions d'appel, soit d�velopper la fonction inline.
>>
>> [...] si les conventions de passage sont par pile, en g�n�ral
>> cela va cr�er une contrainte d'ordre partiel.
>
> Ne m�lange pas les conventions d'appel et l'ordre d'�valuation des
> param�tres, ceux-ci peuvent �tre �valu�s dans n'importe quel ordre,

Je ne m�langeais pas : l� o� tu �cris � peuvent �, j'avais �crit � en
g�n�ral �, avec exactement la m�me id�e.

> voire de facon concommitante et les r�sultats sont ensuite mis sur la
> pile dans le bon ordre pour respecter la convention d'appel.

M�me la mise en pile peut se faire en d�sordre (les empilages sont la
plupart des cas des �critures en m�moire, qui est index�e et non pas � acc�s
s�quentiel ; sans compter les effets du cache). J'ai d�j� vu des
compilateurs � r�utiliser � les arguments de la pile d'un pr�c�dent appel �
une fonction (locale), en particulier this.
La seule chose qui importe, c'est que le processeur � voit � dans le
contexte de la fonction appel�e les param�tres � la place attendue, le
nettoyage de la pile, et la pr�servation des invariants ; le reste, c'est de
la cuisine.


Antoine