4 ms·

May I ask why you choose to use inline on the non-template class-methods? Did it make any difference in the code produced? For the rest: this seems very well do

by stinos 12y ago

May I ask why you choose to use inline on the non-template class-methods? Did it make any difference in the code produced? For the rest: this seems very well done. Love all the proper comments and the huge amounts of static_asserts.

robert_tweed 12y ago
Not the author, but since the whole thing is defined in a header, everything has to be declared inline to avoid violating the one definition rule. Inline hasn't had anything to do with performance for years (compilers just do what they want anyway), but it's somewhat confusing that the meaning was changed.
- rav 12y ago
  > everything has to be declared inline to avoid violating the one definition rule. Actually, methods defined inside the class definition are implicitly marked inline.
- byuu 12y ago
  I found a cool trick around that recently. Use anonymous namespaces when you want to have "standard-library/boost"-like template header libraries. Anything inside of an anonymous namespace has no external linkage, and it can transparently use anything inside its parent namespace. For instance: namespace nall { namespace { void foo() { } }} You can include this in multiple compilation units, invoke it with nall::foo(), and have no issues with multiple symbols. (and of course as rav said, as long as you put the function definition inside the class definition, that can also work. But my trick will work if you want the functions declared outside the class, or want non-class functions.)
  - T-zex 12y ago
    Wouldn't that become a separate function per translation unit?
    - byuu 12y ago
      I want to say that GCC will do the same thing with the inline trick. It has the option to inline the function (where there won't be any actual functions in the resulting binary), or declare it as a unit-unique function (where the actual function will be repeated in the binary, one for each object that includes our header and uses the function), or recognize it's the same function in each unit and merge it back to just one function for the entire binary (which seems even more likely to happen with LTO.) Theoretically, the same thing should happen here. The only difference is you don't have to hint that you want the function inlined (and maybe you really don't), but you can still mark the function inline (or always_inline) if you want to ask GCC to please do that, and it doesn't ignore you. However, I haven't actually analyzed the resulting binaries comparing the two approaches, so I can't say for sure if GCC can optimize the multiple functions to one in the former case (inline) but not the latter case (anonymous namespace). It would seem like an oversight if that were true.
cameron314 12y ago
It's a matter of personal coding style preference. That's all :-) I like to document which functions I'd prefer to be inlined. It should make no difference in the output, since I believe all the methods are implicitly 'inline' anyway. And it certainly doesn't affect correctness.

by stinos 12y ago

robert_tweed 12y ago

Not the author, but since the whole thing is defined in a header, everything has to be declared inline to avoid violating the one definition rule. Inline hasn't had anything to do with performance for years (compilers just do what they want anyway), but it's somewhat confusing that the meaning was changed.

rav 12y ago
> everything has to be declared inline to avoid violating the one definition rule. Actually, methods defined inside the class definition are implicitly marked inline.
byuu 12y ago
I found a cool trick around that recently. Use anonymous namespaces when you want to have "standard-library/boost"-like template header libraries. Anything inside of an anonymous namespace has no external linkage, and it can transparently use anything inside its parent namespace. For instance: namespace nall { namespace { void foo() { } }} You can include this in multiple compilation units, invoke it with nall::foo(), and have no issues with multiple symbols. (and of course as rav said, as long as you put the function definition inside the class definition, that can also work. But my trick will work if you want the functions declared outside the class, or want non-class functions.)
- T-zex 12y ago
  Wouldn't that become a separate function per translation unit?
  - byuu 12y ago
    I want to say that GCC will do the same thing with the inline trick. It has the option to inline the function (where there won't be any actual functions in the resulting binary), or declare it as a unit-unique function (where the actual function will be repeated in the binary, one for each object that includes our header and uses the function), or recognize it's the same function in each unit and merge it back to just one function for the entire binary (which seems even more likely to happen with LTO.) Theoretically, the same thing should happen here. The only difference is you don't have to hint that you want the function inlined (and maybe you really don't), but you can still mark the function inline (or always_inline) if you want to ask GCC to please do that, and it doesn't ignore you. However, I haven't actually analyzed the resulting binaries comparing the two approaches, so I can't say for sure if GCC can optimize the multiple functions to one in the former case (inline) but not the latter case (anonymous namespace). It would seem like an oversight if that were true.

cameron314 12y ago

It's a matter of personal coding style preference. That's all :-) I like to document which functions I'd prefer to be inlined. It should make no difference in the output, since I believe all the methods are implicitly 'inline' anyway. And it certainly doesn't affect correctness.