On Saturday, 17 May 2014 at 17:31:18 UTC, bearophile wrote:
I am reading all the slides in this page (some are still
missing and will be added later):
https://github.com/boostcon/cppnow_presentations_2014
Here are the slides of a nice talk, "Removing undefined
behavior from integer operations: the bounded::integer library":
https://github.com/boostcon/cppnow_presentations_2014/blob/master/files/bounded_integer.pdf?raw=true
Some design decisions are not good (like not throwing at
run-time on default, the long name, and more). Near the end of
the slides pack it shows that a bit of language support can
help improve both the syntax and the usage.
Bye,
bearophile
Hello bearophile. I am the presenter / author of said library, so
I feel I should comment on this.
First, the default overflow policy. This is an issue I have
struggled with a bit. The current default is to mirror built-in
integers in terms of performance. If a user types
bounded::integer<0, 10>, they get a type with no run-time checks.
I did consider making bounded::throw_policy the default (right
now, the typedef for that is bounded::checked_integer<0, 10>). My
reasoning for this that I suspect this is the behavior that most
people want. I could be convinced otherwise primarily by way of
proving that compilers can optimize away the run-time bounds
check for common cases: situations like the integer increment for
a loop index variable. I've also considered a debug assert
statement for the default.
Second, the name. If you have suggestions for something better, I
am listening. I definitely understand the importance of common
types being short. The previous version of this library had the
namespace as bounded_integer and the class type as
bounded_integer, so instead of bounded::integer<0, 10>, you had
to refer to it as bounded_integer::bounded_integer<0, 10>, which
was even worse. My ideal would probably be something like int<0,
10>, but I'm not getting that for fairly obvious reasons. I do
find myself not typing out the name of the type very often,
though, preferring to let auto deduce the types for me.
You say you have more criticisms of the library design, so I hope
they are nothing too fundamentally flawed. I would like to hear
them so that I can fix them (or perhaps I addressed the issue in
my talk? The video is not yet posted).
Thank you for the link :)
