Arm Mbed OS support forum

Code contribution "modern" c++

Hello,
i made some minor pull request lately and during the process i stumbled uppon a question.
i read the Styleguide here and it was helpful. i try to use astyle for every commit.
But it does not say anything about what featues of c++14 i can use.
for example i saw that a lot of preprocessor defines used in mbed, i myself tent to use constexpr.
same for ifdef and if constexpr, or auto.
so my question is what is wanted by the maintainers. is it allowed to use more modern c++ or is it better to stick to a more classic approach and orient myself on the exitsting code so it does not get to messy.
cheers

Edit: another question is: since C++14 is nearly 6 years old should we go on and update to c++17?

2 Likes

Reading your PR’s and the reviews, I was asking myself the same questions.

I hope mbed’s team will lean on the side of modern C++.

I think it is advisable to use current C++ features, especially when the compiler can produce better code.
The release of C++14 for Mbed is not so long ago, so most parts of Mbed are using more conservative coding. One reason is that Mbed supports several compilers and all must be on the same level, and it introduces more testing again.
So I would not say its a matter of the Mbed team is too conservative, e.g. the chrono features are used now and look how much code is affected.

I worry more about the different styles that are used now, before camel case was used most, now lower case with underscore is used also. Event BufferedSerial / UnbufferedSerial differ: e.g. format() vs. set_format().

regarding:

One reason is that Mbed supports several compilers and all must be on the same level, and it introduces more testing again.

the styleguide states here https://os.mbed.com/docs/mbed-os/v6.2/contributing/style.html#compiler-settings

  • Uses the GNU11 standard for C.
  • Uses the GNU++14 standard for C++.

so at least c++14 features should be ok.

regarding:

I worry more about the different styles that are used now, before camel case was used most, now lower case with underscore is used also. Event BufferedSerial / UnbufferedSerial differ: e.g. format() vs. set_format().

The question is what do the maintainers want. when we want to migrate to a modern approach we have to start somwhere. for example all new PR are allowed to use C++14 featues, or it is encuraged to create PRs where we refactor the existing code. but if this is not wanted creating such PRs could cause a lot discussions and troubles

I guess that improvements in speed or code size are welcome. My experience is, that Mbed was constantly growing, but newer releases with usage of constexpr or reducing virtual interfaces has reduced code size now.

And I wish that the Mbed team publishes a roadmap (at least rough) with priority of some topics.

This does seem quite limiting as we have almost have C++20.

Defaulting to C++17 shouldn’t break anything, but offers lots of potential performance improvements (especially copy mandatory elision).

Alternatively, at least let me set std=c++17 for my project and I’ll take the hit?

mbed is always going to be constrained why what standards the three supported compilers can handle (iar, gcc, and armcc). As per a comment on this PR https://github.com/ARMmbed/mbed-os/pull/13881 you can see that C++17 support is nearing possibility. After that , it’s about generated code size, ram, and speed.

You can edit the profiles or add your own with the c++17 flag. That’s what I do.

1 Like

Thanks, I couldn’t see how to do that and couldn’t find any documentation.

Could you describe how/where you make the change?

Here is the documentation:

Here are the profiles:

You can create your own profile like this:

And then when compiling, you can point to it:

mbed compile --profile=debug --profile=path/to/your_profile.json

:warning: Unless you’ve copied one of mbed’s profiles to add your arguments, don’t forget to also use the --profile=debug/develop/release

1 Like

Thank you that’s perfect.

Really appreciate you help.