Trouver la prochaine puissance de 2 avant et après fusaka.

Le répartiteur de fonctions Solidity est un arbre où : - Les nœuds internes effectuent des divisions binaires. - Les nœuds feuilles contiennent jusqu'à 4 sélecteurs de fonction, testés de manière linéaire. Astuce 1 : le bytecode de la fonction `fallback` est généré deux fois dans le bytecode. Pour réduire la taille du bytecode, encapsulez la logique de fallback dans une fonction interne. Astuce 2 : si vous avez une fonction très fréquemment utilisée, créez un alias avec un sélecteur de fonction `0x00000000`, ce qui la rend le moins coûteuse à rechercher.

- L'un des défis dans la conception d'une bibliothèque sera de déterminer quel algorithme doit être utilisé. Renseignez-vous sur pourquoi la map de C++ est un arbre, alors que unordered_map n'est apparu que 15 ans plus tard. - Les bibliothèques avec des génériques dépendent fortement de la capacité du compilateur à effectuer une abstraction sans coût avec un minimum de nudges. Dans Solady, nous faisons parfois des choses très dégoûtantes pour inciter le compilateur. La raison pour laquelle écrire en Rust et en C++ est agréable, c'est que le compilateur est assez intelligent pour ne pas avoir besoin de tous ces nudges. Ainsi, le cœur de Solidity aurait besoin d'un très bon optimiseur pour aller au-delà des douceurs syntaxiques des génériques. - Soyez prudent face à une possible situation Python 2 contre 3. J'espère que les enseignements du cœur pourront et vont revenir à la version classique. - Dans un monde de Solidity classique et de cœur, Solady prévoit de maintenir et de développer pour les deux. Les langages avec une bibliothèque standard folle ont toujours des bibliothèques tierces (par exemple, Eigen), pour des connaissances spécifiques à un domaine.