GCC 4.9.4 support

[mtnmbr]

Hi, I would like to use result for an embedded project I am working on. Having programmed some rust in my free time, coming back to error handling in C++ without exceptions feels tedious. Therefore I was really amazed to see your project.

Sadly I'm stuck to a rather old version of gcc... namely gcc 4.9.4. Which does support most of c++11 and c++14. But sadly not all of it.
When trying to compile result, it failed because the following std functions are missing.

• std::is_trivially_move_constructible
• std::is_trivially_copy_constructible
• std::is_trivially_move_assignable
• std::is_trivially_copy_assignable

Check out the example at https://godbolt.org/z/5cazj64j4

I tried to modify the code to use a wrapper like bitwizeshift::is_trivially_x_x which would forward the declaration if available but use some sort of default that return true or false when its missing.
nonstd::optional (another project i am using to get some newer c++ features into my ecosystem) follows this approach.

Maybe we could provide something similar to your project? My first copy and paste try from nonstd::optional did succeed to build locally with my compiler. But a was not able to run the testsuite sadly.

Also I dont really know the effect this will have on the performance of your lib. I would love to hear what you think about the idea to get better backwards compatibility.

Best regards
Michael

[bitwizeshift]

👋🏻 Hi @mtnmbr!

It's been a while since I've look into GCC-4.9.4 support, but it was a bit of a mixed bag last time I tried to get it working which was why I eventually dropped support for it.

I can't recall the specifics of the issue as it was so long ago; but I recall experiencing compile-errors for valid C++ code that, if fixed, resulted suboptimal code-generation. I think this might have had something to do with the way the constructors and assignment operators are disabled, which uses base-classes and inherited constructors/assignment operators. I haven't checked in a long time, so it's also possible that later refactorings fixed these issues after support was dropped.

With respect to adding just the traits; that's actually the easier part. I've done similar in other projects such as my BackportCPP project, though the behavior is not 1-1 with standard C++. Support for those traits in 4.9.4 is a little wonky. The compiler provides non-standard traits std::has_trivial_copy_constructor and std::has_trivial_copy_assign, and exposes an intrinsic __has_trivial_destructor -- all of which work largely like their standardized counterparts. The issue is that, to my knowledge, there is no move equivalent to these functions -- which means large portions of logic can't be toggled correctly, and I believe this can run the risk of valid code not compiling in 4.9.4 but working in 5 (though I might be mistaken on this).

I will try to take a look later this week on what issues there are with re-introducing 4.9.4 support and can report back. I'm not against supporting it provided that the code-gen doesn't suffer on conforming compilers. PRs are also welcome if you happen to get to this first!

[mtnmbr]

Hey, thanks for the reply. I totally understand that the support should not be introduced if the generated code suffers performance wise! If it will work though, I will be glad to use it!

Currently I sadly don't have the time to take a deeper dive into this topic. Most likely I will be able to change to a newer compiler using a more up to date version of clang than digging into this issue. Still for others that wont be able to easily migrate to a newer compiler (e.g. because of certification issues) this would be interesting if possible!