constexpr for UUID.h about bsf HOT 5 CLOSED

Hey, sorry for the late response, I forgot to put the repository on my watch and didn't notice the issue until now.

Most of those would be very welcome, constexpr, default keyword and inline value initializes especially. I tend to make these updates myself as I come across older code as well.

I don't think we need noexcept as we don't throw exceptions. String is generally only used in non-performance critical bits of code, and even then I'm pretty sure I avoid copying them around, but if you can find a good place for it, it wouldn't hurt.

C++17 I think we should wait for a bit. I tried switching to nested namespaces in a few places and was getting warnings on macOS, but maybe I just need to update something.

from bsf.

Thanks for the feedback!

I'm really happy to hear that you're open to constexpr, default keyword, and inline value initializers. So many projects out there straight up refuse to accept pull requests for those.

I'd actually argue that the noexcept keyword has value specifically because BSF doesn't use exceptions much. (Unless you're disabling exceptions at compile time?). The noexcept keyword, for functions that aren't inline in the header file, allow the compiler to assume that no exceptions will be thrown, and drop any exception handling code that may be generated as a result of the function call.

It's mostly useful for low level library code that gets called everywhere. At my day job we started using it and found a small drop in binary sizes as a result. Mileage may vary, though.

As for the StringView thing, I implemented a similar feature at my day job and saw a pretty nice reduction in temporary object creation... That being said, we have some 200+ developers all hacking away, so mistakes are significantly more likely there.

If I get bored sometime, I'll implement a StringView like class and demonstrate how it would be integrated, but I wouldn't say to hold your breath :-).

As for C++17, I'd be all for adopting it fully, but I'm not too worried about it. Feel free to switch as you see fit based on the other platforms.

from bsf.

Exceptions are fully disabled at compile time. I do wish to move everything to C++17 eventually, at the moment backwards compatibility is not a concern. When they are more mature, I want to do a full refactor with C++ modules as well.

from bsf.

Modules weren't approved for the c++17 version of the standard, were they?

So for exceptions, is the plan for those to stay disabled? If so, then yea, noexcept doesn't do any good. Though, if there's uncertainty on if they'll be enabled in the future, we might want to add them where appropriate for sake of not killing performance if someone enables exceptions.

from bsf.

Sadly no :(

I don't have plans on enabling exceptions. The code isn't written for handling exceptions so enabling them probably wouldn't have much benefit, so I really doubt someone would do so.

from bsf.