4 ms·

You don't need C++ for that. Let's say we are talking about a serial port and a motor driver, all in the same MCU. A programmer would have to be pretty sloppy

You don't need C++ for that. Let's say we are talking about a serial port and a motor driver, all in the same MCU. A programmer would have to be pretty sloppy to use motor controller functions to try and talk to the serial port. If I write a function called "set_serial_baud_rate()" and another called "set_motor_rpm()" it would be alarming if someone tried to use it to set the set_motor_rpm() to change the serial port's baud rate. I understand encapsulation very well but it simply isn't necessary in a lot of embedded cases. I can't remember a single instance in thirty years of product development when we had an issue in development because code was NOT object oriented. Product development never slowed down due to not using OO. More bugs were not introduced due to not using OO. Code was just as maintainable and extensible using C or C++. It truly does not matter at all as far as I am concerned. What I look for is "done for you" code. Libraries that can produce power-of-two or order-of-magnitude gains in developing a product. Show me gains of that magnitude and I'll code in COBOL if necessary. I truly don't care about languages any more. Just like I don't care about code editors (counting milliseconds in vim). Give me a decent IDE like JetBrains products and life is good. I know this puts me at odds with most of what they teach today. Kids come out of school and automatically reach for objects for even the simplest of problems. OO has it's place, of course, but it should not be the first tool one reaches for unless it is well justified. A CPU couldn't care less if you wrote the code in machine language or Python. The facilities provided by these languages are for the programmer, not for the CPU. One of my favorite interview techniques: Ask someone to solve a problem. If they are on the younger side they'll immediately define a class, members, properties, maybe multiple classes. When they are done, ask them to do the same in procedural form. I've seen people get completely tangled-up by this simple request. EDIT: To be clear, I am NOT saying OO doesn't have it's place. Of course it does. I've written a bunch of iOS apps in Objective-C with a good mix between OO and procedural when justified. For example, a genetic solver done in procedural form on iOS is miles faster than the same solver implemented in OO. A lot of it has to do with using layers of data objects rather than the raw data types typically used in C. In other words, there's a cost associated with using an object to store and manipulate what would otherwise be a simple array. You might be surprised to see just how dramatic the performance improvement can be.

AnimalMuppet 9y ago
Well, let's say that set_motor_rpm() didn't try to slam the RPM to the requested value, but instead tried to smoothly accelerate or decelerate to the requested value at a rate that would not damage the motor. It might use a function called set_immediate_rpm() to set the value for the next instant, but that value needs to be not very different from the current value, or damage can result. You can use an object to make sure that nobody from outside calls set_immediate_rpm() by mistake. Now, you're still right, because in C, you just make set_immediate_rpm() static, so that nobody can call it from outside the file, and then the non-static functions become the public API.
- rebootthesystem 9y ago
  To go further than that, embedded projects more frequently than not have one and only one software developer. It's not like building a website with a team of several developers. In this context the "nobody" in your scenario is the only person on the project. Which, once again, brings us to the idea that it isn't the language or procedural vs. OO at the root of the problem at all if things are done wrong or misused. I must also point out that hypothetical examples are rarely meant to cover all possible scenarios, much less corner cases. They are simplified examples to facilitate an explanation. As such it is always possible to find holes in the hypothetical. A colleague taught me a very important lesson about twenty-five years ago. He was about ten years older than me and had far more experience. I had just finished coding an electronics component management system for our manufacturing department where we worked. It was really slick and fast at a time when text-only apps and menus reigned. I was proud that my six month effort had produced such a product. I was showing it off. When it was his turn to be dazzled he let me do my "look at this" tour of the software and said virtually nothing. When I was done he said "looks good" and proceeded to plant his palm on the keyboard and run it back and forth about four times, pressing as many keys as he could at random. The program crashed and he walked away. It took me about a month to make it robust enough to have it react gracefully to such an attack. Learned a lot in the process about dealing with the real world. This gave me the mindset to write code defensively. A function such as "set_immediate_rpm()" should be bulletproof, and this has nothing to do with OO vs. procedural. A good implementation of "set_immediate_rpm()" would have a rate-of-change evaluation such that you could call it a million times and yet not violate the maximum desired rate of change (presumably set through a different function or defined as a constant somewhere).

AnimalMuppet 9y ago

Well, let's say that set_motor_rpm() didn't try to slam the RPM to the requested value, but instead tried to smoothly accelerate or decelerate to the requested value at a rate that would not damage the motor. It might use a function called set_immediate_rpm() to set the value for the next instant, but that value needs to be not very different from the current value, or damage can result. You can use an object to make sure that nobody from outside calls set_immediate_rpm() by mistake. Now, you're still right, because in C, you just make set_immediate_rpm() static, so that nobody can call it from outside the file, and then the non-static functions become the public API.

rebootthesystem 9y ago
To go further than that, embedded projects more frequently than not have one and only one software developer. It's not like building a website with a team of several developers. In this context the "nobody" in your scenario is the only person on the project. Which, once again, brings us to the idea that it isn't the language or procedural vs. OO at the root of the problem at all if things are done wrong or misused. I must also point out that hypothetical examples are rarely meant to cover all possible scenarios, much less corner cases. They are simplified examples to facilitate an explanation. As such it is always possible to find holes in the hypothetical. A colleague taught me a very important lesson about twenty-five years ago. He was about ten years older than me and had far more experience. I had just finished coding an electronics component management system for our manufacturing department where we worked. It was really slick and fast at a time when text-only apps and menus reigned. I was proud that my six month effort had produced such a product. I was showing it off. When it was his turn to be dazzled he let me do my "look at this" tour of the software and said virtually nothing. When I was done he said "looks good" and proceeded to plant his palm on the keyboard and run it back and forth about four times, pressing as many keys as he could at random. The program crashed and he walked away. It took me about a month to make it robust enough to have it react gracefully to such an attack. Learned a lot in the process about dealing with the real world. This gave me the mindset to write code defensively. A function such as "set_immediate_rpm()" should be bulletproof, and this has nothing to do with OO vs. procedural. A good implementation of "set_immediate_rpm()" would have a rate-of-change evaluation such that you could call it a million times and yet not violate the maximum desired rate of change (presumably set through a different function or defined as a constant somewhere).