Posté par rewind (Mastodon) .
En réponse à la dépêche Sortie de JDK 10.
Évalué à 10.
Dernière modification le 10 novembre 2018 à 14:40.
comment tu connais le type de retour de getNextValue()
On ne le connaît pas exactement mais on s'en fout, on sait que c'est un entier et ça suffit. On a géré le cas du dépassement de manière générique et donc, si jamais le type de retour de getNextValue() change, on aura rien à changer ici. Que cet entier soit un int, un size_t, un uint16_t ou autre chose, ça ne change rien, au code et à sa logique.
De plus, je ne suis pas fan du code que tu proposes, tester les limites des types en dynamique
Rien n'est dynamique ici, decltype(counter) est évalué à la compilation et max() est constexpr donc sera également évaluée à la compilation.
et je ne parle même pas des performances...
Niveau performance, ça ne changera rien et niveau typage, c'est plus générique donc plus maintenable que si tu avais spécifié le type directement.
[^] # Re: Inférence de types
Posté par rewind (Mastodon) . En réponse à la dépêche Sortie de JDK 10. Évalué à 10. Dernière modification le 10 novembre 2018 à 14:40.
On ne le connaît pas exactement mais on s'en fout, on sait que c'est un entier et ça suffit. On a géré le cas du dépassement de manière générique et donc, si jamais le type de retour de
getNextValue()change, on aura rien à changer ici. Que cet entier soit unint, unsize_t, unuint16_tou autre chose, ça ne change rien, au code et à sa logique.Rien n'est dynamique ici,
decltype(counter)est évalué à la compilation etmax()estconstexprdonc sera également évaluée à la compilation.Niveau performance, ça ne changera rien et niveau typage, c'est plus générique donc plus maintenable que si tu avais spécifié le type directement.