0
\$\begingroup\$

What are some off the open source, popular choices for a C++ compatible RTOS (besides mbed)? I've heard that FreeRTOS doesn't provide official support for C++ compilation and it's a nightmare getting into work.

\$\endgroup\$

closed as primarily opinion-based by PlasmaHH, Jeroen3, MCG, pipe, winny May 29 '18 at 13:48

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

3
\$\begingroup\$

The short answer to your question is:

"Real" RTOS and "real" C++ are mutually exclusive. So, you can't.

Long story:

C++'s syntax allows resource allocation and deallocation during runtime. In fact, most C++ developers (and judging by your question, you belong to these) won't even notice when that happens. In fact, chances are high you want C++ exactly because it can do that (and you don't have to do your own memory management and/or preallocate everything). It's a language feature C++ has, but C hasn't.

That's an idea incompatible to an RTOS, because it's non-deterministic in complexity (depends on instantaneous memory fragmentation, which depends on what your system has been doing before).

You can use C++ in a manner that doesn't do any run-time allocations. That requires a very high degree of discipline during development; and you can't use any of the standard library things (especially no std::string, std::vector…) and ABSOLUTELY no exceptions (you can probably even disable exception handling in the compiler).

People who develop RTOSes for automotive applications do allow C++ in some kernels, but they replace all the standard library's allocators by one that allows object creation during "bootup", but then a switch is flipped and at runtime, they stop doing anything but just signal a fault to the OS when they're used at all, which then stops operation.

As you can imagine, that's a nightmare to write code for. The software doesn't look like C++ code much anymore.

I'll be blunt: C++ is not the language you want to use here, already because FreeRTOS often runs on systems where you wouldn't even want the C++ runtime memory overhead in the first place... So do yourself a favor, learn C99 and a bit of C11, and do things in C.

\$\endgroup\$
  • \$\begingroup\$ Well, the application I have in mind should be able to get by without dynamic memory allocation, so I'd like to at least give C++ a go. It would really be used as a nice way to compartmentalise my code. \$\endgroup\$ – 19172281 May 29 '18 at 13:26
  • 3
    \$\begingroup\$ AFAIK C++ never forces you to use dynamic memory allocation. Indeed in a an embedded application, you can and should avoid dynamic memory allocation. If you really need to use stuff requiring it, you practically always have the option to specify your own allocator for containers like std::string if you really feel like using them, allowing you to reserve N bytes statically for that custom allocator to use. \$\endgroup\$ – jms May 29 '18 at 13:55
  • 1
    \$\begingroup\$ @jms, also, I'm not even sure why we're even arguing: I specifically said that yes, it's possible, there's people doing it, you need to use your own allocators. So, you're basically agreeing with me while attacking me? I haz a confusion. \$\endgroup\$ – Marcus Müller May 29 '18 at 13:59
  • 1
    \$\begingroup\$ If you agree that C++ doesn't force you to use dynamic memory allocation, then what are you disagreeing about? C++ isn't perfect, I have a love and hate relationship with it, but I do think it is quite well suited for embedded programming. The fact that you should avoid certain features (notably dynamic memory allocation and exceptions) and be careful with templates doesn't take away from all the other features. \$\endgroup\$ – jms May 29 '18 at 14:20
  • 1
    \$\begingroup\$ I think we never disagreed, you know, and I've been saying that for a couple of comments now :) So, all set here. \$\endgroup\$ – Marcus Müller May 29 '18 at 14:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.