91–100 of 130 posts
Maybe Ada's approach of every number type requiring explicit bounds is a good one.
I think that's a good part of ADA that should have been copied 30 years ago. That and you should be able to define overflow semantics as well.
Earlier quoted context omitted.
> but with a library like this, it has to make a subroutine call. I mean, before I wrote my comment I checked and it's `constexpr` all the way down to the add instruction so if it's going to make a call, I'm not seeing it. There is definitely a lot of template machinery, but I can't be the judge of that immediately. > I personally feel that libraries like this are taking C++ in the wrong direction ("ranges" is anothe…
constexpr functions are not inlined in debug builds. They can't be: the whole point of debug builds is that you can attach a debugger and step through the code. Illustration, compare the assembly for "foo1" and "foo2": https://godbolt.org/z/t9Zkx-
Earlier quoted context omitted.
I think that's a good part of ADA that should have been copied 30 years ago. That and you should be able to define overflow semantics as well.
It was indeed copied, by Pascal, Turbo Pascal, Delphi, Modula-2, Modula-3, unfortunately not by the languages that won.
Oh, that's nice. I wanted that decades ago, when I was working on program verification. Templates have made a lot of progress if this can be done entirely in C++ templates. I once wrote, but never published, "Type Integer Considered Harmful", back when there were still 16-bit integers in most C programs. I wanted ranges on everything, like Ada. As a practical matter, integer overflow became less of an issue with 32-b…
Earlier quoted context omitted.
it does not have to. A smart compiler can narrow it down to machine size integers then possible.
> A smart compiler can narrow it down to machine size integers then possible. A smart compiler will be able to narrow it down in a limited set of scenarios, but all we need to do is put an accumulator into a loop to see that bounding an integer is equivalent to the halting problem. Or for another example, should we expect our "smart" compiler to bound y in the following? The bound on x is a freebie. bigint n(uint64_t…
At this point, when I see libraries like this all I can think is ”oh good, my compile times aren’t long enough, lets make EVERY INTEGER a template”. Also, while I can reasonably beliveve that most of the overhead goes away at -O2 or -O3, this has to just trash performance for debug builds, which is not unimportant.
I don't think you even looked at the library, but from I can tell, debug perf would not be impacted at all.
That's a variation of "did you even read the article", which the HN guidelines specifically ask users not to post, so please edit those out of your posts. The comment would be just fine without that bit.
Weird. Ive been programming in C/C++ professionally for over a decade and have been using built-in integer types mostly without issue. Might want to qualify your hyperbole- is it worth reading on?