Mais une question que j'avais posée est : qu'est-ce qui peut pousser un développeur à utiliser cette fonction en dehors des bornes 0 .. 63 ?
Là tu veux dire que tu trouves rare ce genre de situation ?
la majorité des codes l'utilisant se retrouveraient pénalisés d'un test inutile sur X86
Et là tu veux dire que finalement tu trouves fréquente ce genre de situation ? J'avoue que suis un peu perdu dans ce que tu me dis.
Mais c'est plus drôle qu'une fonction stationnaire, et c'est joli un donut !
Tu diras ça à mes étudiants qui ont cherché pendant une semaine d'où pouvait venir le problème alors que leur algo était parfaitement cohérent arithmétiquement parlant :)
Un langage de haut niveau peut régler ce problème en fournissant deux solutions: l'une avec un type contraint qui garantit la cohérence du code tout en permettant l'optimisation sur X86 et l'autre avec un shift_right prenant un amount quelconque qui respecte ce qu'est censé faire un shift_right arithmétiquement parlant.
Haskel, Python, Ada, Eiffel le proposent. D'autres langages de haut niveau ne font rien de plus que le jeu d'instruction X86 et je trouve que c'est une faiblesse (générateur de bugs). De toute façon, laisser des comportements non définis sur une partie des plages des types fournis comme arguments d'une fonction c'est casse gueule (à tout le moins on lève une exception, là c'est totalement silencieux en plus).
Et puis bon, c'est quand même étrange de fournir, à haut niveau, un opérateur qui fournit le même quotient par 2^{64} que par 1 dans un langage de haut niveau sous prétexte que certains processeurs ont ce comportement pour de simples raisons d'optimisation.
[^] # Re: Du haut niveau pour gérer correctement du bas niveau
Posté par snowball (site web personnel) . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.
Là tu veux dire que tu trouves rare ce genre de situation ?
Et là tu veux dire que finalement tu trouves fréquente ce genre de situation ? J'avoue que suis un peu perdu dans ce que tu me dis.
Tu diras ça à mes étudiants qui ont cherché pendant une semaine d'où pouvait venir le problème alors que leur algo était parfaitement cohérent arithmétiquement parlant :)
Un langage de haut niveau peut régler ce problème en fournissant deux solutions: l'une avec un type contraint qui garantit la cohérence du code tout en permettant l'optimisation sur X86 et l'autre avec un shift_right prenant un amount quelconque qui respecte ce qu'est censé faire un shift_right arithmétiquement parlant.
Haskel, Python, Ada, Eiffel le proposent. D'autres langages de haut niveau ne font rien de plus que le jeu d'instruction X86 et je trouve que c'est une faiblesse (générateur de bugs). De toute façon, laisser des comportements non définis sur une partie des plages des types fournis comme arguments d'une fonction c'est casse gueule (à tout le moins on lève une exception, là c'est totalement silencieux en plus).
Et puis bon, c'est quand même étrange de fournir, à haut niveau, un opérateur qui fournit le même quotient par 2^{64} que par 1 dans un langage de haut niveau sous prétexte que certains processeurs ont ce comportement pour de simples raisons d'optimisation.