5 ms·

I will soon be making a library and will be used on micrcontrollers and PCs. I'd like to use C++ but past experiences suggest that using C and writing a C++ wr

by 2bluesc 11y ago

I will soon be making a library and will be used on micrcontrollers and PCs. I'd like to use C++ but past experiences suggest that using C and writing a C++ wrapper later will save me frustration with things like code size and manual memory management. If I could turn off a number of features, C++ would be great. I keep flashing back to blog posts [0][1] written by the ZeroMQ author trying to settle on C being the way to go. [0] http://250bpm.com/blog:4 http://250bpm.com/blog:4 [1] http://250bpm.com/blog:8 http://250bpm.com/blog:8

vardump 11y ago
A few words of advice: don't use C++ on microcontrollers or in kernel code. Explicitness is important for those applications.
CyberDildonics 11y ago
One of the first things he says is that constructors and destructors can't be used. Is that true? If so, why? Exceptions should be able to be turned off in the compiler, but destructors, move semantics, simple template type substitution, and lambdas should be zero overhead in modern C++11/14. I think a lot of people think about C++ and think inheritance and exceptions, but after having done modern C++11 for two years, those are two of the features I've used the least.
- lucozade 11y ago
  It's not that constructors and destructors can't be used. What he said IIRC is that you can't manage errors in them without either using exceptions or using trivial constructors/destructors plus a state machine for the remainder of the lifecycle (initialisation etc). As he's mostly into writing libraries not applications, both approaches were, in his opinion, more hassle than they were worth.
- pjc50 11y ago
  Many embedded style guides argue against dynamic memory allocation altogether. So you statically allocate all the variables you will ever need. And in an embedded environment there may not be a loader to run the constructors, or you don't want to run them at bootup until you've configured the DRAM or suchlike. Edit: the ZeroMQ point is that, if you have a constructor or a destructor, then it must not do anything that can fail because the mechanism for recovery is an exception and clean recovery from exceptions bubbling up through code is quite hard to achieve. This is basically the Go/Rust argument against exceptions and in favour of explicit error return.

by 2bluesc 11y ago

vardump 11y ago

A few words of advice: don't use C++ on microcontrollers or in kernel code. Explicitness is important for those applications.

CyberDildonics 11y ago

One of the first things he says is that constructors and destructors can't be used. Is that true? If so, why? Exceptions should be able to be turned off in the compiler, but destructors, move semantics, simple template type substitution, and lambdas should be zero overhead in modern C++11/14. I think a lot of people think about C++ and think inheritance and exceptions, but after having done modern C++11 for two years, those are two of the features I've used the least.

lucozade 11y ago
It's not that constructors and destructors can't be used. What he said IIRC is that you can't manage errors in them without either using exceptions or using trivial constructors/destructors plus a state machine for the remainder of the lifecycle (initialisation etc). As he's mostly into writing libraries not applications, both approaches were, in his opinion, more hassle than they were worth.
pjc50 11y ago
Many embedded style guides argue against dynamic memory allocation altogether. So you statically allocate all the variables you will ever need. And in an embedded environment there may not be a loader to run the constructors, or you don't want to run them at bootup until you've configured the DRAM or suchlike. Edit: the ZeroMQ point is that, if you have a constructor or a destructor, then it must not do anything that can fail because the mechanism for recovery is an exception and clean recovery from exceptions bubbling up through code is quite hard to achieve. This is basically the Go/Rust argument against exceptions and in favour of explicit error return.