Hacker News new | past | comments | ask | show | jobs | submit login

I don't think you even looked at the library, but from I can tell, debug perf would not be impacted at all.



> I don't think you even looked at the library

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.

https://news.ycombinator.com/newsguidelines.html


Of course it will be impacted. Libraries like these are "zero-cost" only because of very aggressive inlining (not generally available in debug builds), otherwise all its operations happen in subroutines. Operator overloading is the most obvious example: for regular integers, addition is basically a single instruction even in debug, but with a library like this, it has to make a subroutine call. A call which has who knows how many layers of abstraction that compiler optimizations hasn't shaken off.

In fact, the README says as much: it has only zero time/space overhead "assuming basic compiler optimizations like inlining".

And I did actually look at the code, but at a glance I couldn't get much sense of it. The main header imports like two dozen other headers, and the "detail" folder is filled to the brim with more headers. I tried cloning and using it, but I couldn't get it to compile (which is probably mostly my fault, but I really didn't want to spend too much time on it). I did run just the preprocessor though, and "#include <bounded/integer.hpp>" expanded to 48000 lines. 48000 extra lines to compile in order to use integers. For every file you use it in.

I don't want to be too harsh here, I'm sure it's an excellent library and it does what it says brilliantly, and if you need bounded integers I'm sure it's awesome. But language like "[integers in C++] are mostly unusable" rankles a bit, and the the implication in this file is that this is something you should regularly use instead of integer types.

I personally feel that libraries like this are taking C++ in the wrong direction ("ranges" is another obvious example) and making the language less and less usable in my profession.


> 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 another obvious example)

I think you're making an emotional argument based on some preconceived twitter-verse sentiment. I'm in games too (graphics specifically) and people are up and arms about the wrong thing. Maybe there are corner cases that are a bit overly complex, but what's wrong with being able to write `std::sort(container)` instead of `std::sort(container.begin, container.end)`. There may be things we don't like, but I don't think we should resort to hyperbole either.

Incidentally, I wouldn't use this library if only because for what I do, having explicitly sized data types is important.


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-


Ah ok, my mistake, I read "debug" as "-g" not "-O0." I generally run with optimizations on but with symbols.


For what is worth they are optimized out with -Og (if that doesn't count as debug build I don't know what does).




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: