Après, avec les inlining etc., il est possible que cela ait un effet sur la fonction englobante bsearch (pour laquelle le param key n'est naturellement pas défini en restrict).
Si le param key n'est pas défini en restrict mais que tu a le droit de considérer qu'il l'est, j'ai du mal à comprendre pourquoi le code n'est pas considéré comme étant invalide.
Dans tout les cas, si la fonction de tri se fait assez inliner et que la valeur à chercher ne sort pas trop d'un coin paumé ou d'une arithmétique de pointeur foireuse, le compilo va s'en rendre compte tout seul qu'il n'y a pas d'aliasing possible. En fait je vois même pas l'intérêt de mettre du restrict ou du const sur une fonction qui va se faire inliner la tronche.
Dans tous les cas, effet du restrict ou pas, les perfs resteront supérieures ou égales au code c++. Le restrict est juste une petite indication supplémentaire au compilo mais cela n'est pas le coeur de la solution, celui-ci étant l'inlining.
Il va falloir m'expliquer comment la perf dans ce cas pourrai être supérieure au code C++. Que ça soit égal, c'est ce à quoi je m'attend, mais supérieure ?
[^] # Re: C - inline - restrict
Posté par Batchyx . En réponse au journal Si si, le C++ peut parfois être plus rapide que le C. Évalué à 2.
Si le param key n'est pas défini en restrict mais que tu a le droit de considérer qu'il l'est, j'ai du mal à comprendre pourquoi le code n'est pas considéré comme étant invalide.
Dans tout les cas, si la fonction de tri se fait assez inliner et que la valeur à chercher ne sort pas trop d'un coin paumé ou d'une arithmétique de pointeur foireuse, le compilo va s'en rendre compte tout seul qu'il n'y a pas d'aliasing possible. En fait je vois même pas l'intérêt de mettre du restrict ou du const sur une fonction qui va se faire inliner la tronche.
Il va falloir m'expliquer comment la perf dans ce cas pourrai être supérieure au code C++. Que ça soit égal, c'est ce à quoi je m'attend, mais supérieure ?