As I have previously alluded to, I did do some general C++ way back in high school and that has been it for most part.
When I got started in microcontrollers, I picked up bits of C and it (along with some rudimentary Python I manage to write) has been my weapon of choice since.

I have given re-learning C++ a fair amount of thought but the language has grown by leaps and bounds and I fear its vastness might be a discouraging factor.
Besides, I do want to learn as much C (memory model, linker scripts and other stuff) as I can manage, before I consider moving to C++.
However, I have seen C++ code written for some ARM Cortex CPUs and I figured it would be a useful tool to have in the future.

I am entirely happy with both C and Python at the moment and I don't see C++ as an alternative to either; just an addition. I was interested in knowing what other members felt about this topic.

Is it worthwhile to learn C++ (virtual functions, templates and whatnot) if you want to use it for embedded programming in the future? Or should I just focus on writing the best C I can?

NB: I am not trying to start a C vs. C++ flame war here, just interested in knowing how (or if) the transition from one to the other could be done.

 

C++ was designed an add-on to C. It brings object-oriented programming to C.

I feel that everyone should learn object-oriented programming, and the more you know, the better you'll be able to leverage that information when an opportunity presents itself.

I think that embedded hardware will move primarily toward C++ as the main language eventually. Might as well start now...

 

...I think that embedded hardware will move primarily toward C++ as the main language eventually...

They same way operating systems have?

 

They same way operating systems have?

Do you know of another language poised to handle the nuances of embedded processors and allow most of those that currently use embedded processors to continue to have a job?

 

Do you know of another language poised to handle the nuances of embedded processors and allow most of those that currently use embedded processors to continue to have a job?

I am failing miserably at my attempt to parse this question. Please restate/clarify/elaborate.

 

I am failing miserably at my attempt to parse this question. Please restate/clarify/elaborate.

There aren't any other languages that will readily handle the requirements and special circumstances that comes with an embedded processor that would not make current designers obsolete.

 

There aren't any other languages that will readily handle the requirements and special circumstances that comes with an embedded processor that would not make current designers obsolete.

I'm obviously being a bit dense today. I still don't follow what you are saying, or what the point is, or how it relates to C++ as a future primary language for embedded processing.

 

I'm obviously being a bit dense today. I still don't follow what you are saying, or what the point is, or how it relates to C++ as a future primary language for embedded processing.

Most current designers use C. Being that C++ extends the functionality of C, using C++ means most designers could still be employed after a switch.

Additionally, there isn't a large supply of compiled languages that would integrate well with some of the oddities that is the embedded world. Creating a new language seems prohibitively expensive, but it's been done before, just ask Parallax about the Propeller.

 

Most current designers use C. Being that C++ extends the functionality of C, using C++ means most designers could still be employed after a switch.

Additionally, there isn't a large supply of compiled languages that would integrate well with some of the oddities that is the embedded world. Creating a new language seems prohibitively expensive, but it's been done before, just ask Parallax about the Propeller.

So, one who knows C well would not be able to retrain to some other more exotic language other than C++? I think that is where my confusion lies. Any good programmer should be fluent in more than one language (either by education or experience), and should be able to pick up a new language easily.

Your original assertion was that C++ will, at some point, supersede C as the primary language for embedded processing. I disagree.

It's no secret that I think the trend to C for *small* embedded processors is a mistake. The code implementations are far too specific for any given compiler and/or set of provided libraries. In addition, IMHO, embedded programmers who start with C, without learning .asm first, tend to become bad programmers. There simply is not enough fundamental understanding of how the underlying hardware works.

C++ just takes the abstraction, and hardware obfuscation, to a yet higher level -- not to mention the "invisible" overhead of creating and destroying objects and memory management.

Please don't misunderstand: there is a place for C++. I've actually written C++ code for embedded systems, and it made sense for those particular applications because of the nature of the applications. In most cases, though, C++ is significant overkill.

 

@joeyd999 and @tshuck: Thanks for your views on the matter. As I said, my intentions were far from making this a C vs. C++ debate.

I prefer the transparency C brings to the table - it is much closer to real hardware and as Joey suggests it is the next best thing after assembly itself.
Having had some C++ experience earlier myself, I tend to perceive it as a separate language than as an extension of C. Trouble is, some employers seem to treat it a little differently.

A recent account from a friend suggested some employers prefer "C/C++" as a core competency for embedded programmers rather than good grounding in C or Assembly alone which prompted this (admittedly rather hasty and not well thought-out) question

 

I'm not saying that they would be unable to learn, I'm saying that the overhead in learning a new one is prohibitive and sets C++ to supersede C for use in embedded systems in the future.

While there is an overhead in using C, we are nearing a point where our processors are powerful enough to make this overhead negligible.

Using a compiled language allows a compiler to determine when to destroy most objects, so a large portion of that overhead could be significantly reduced when using an intelligent compiler.

I agree with the assembly statement - without learning how the hardware works, it become nigh impossible to write any sort of optimized code. However, this is true of any level of abstraction, as you noted, which is why I'm unsure of its contribution.

 

@joeyd999 and @tshuck: Thanks for your views on the matter. As I said, my intentions were far from making this a C vs. C++ debate.

I prefer the transparency C brings to the table - it is much closer to real hardware and as Joey suggests it is the next best thing after assembly itself.
Having had some C++ experience earlier myself, I tend to perceive it as a separate language than as an extension of C. Trouble is, some employers seem to treat it a little differently.

A recent account from a friend suggested some employers prefer "C/C++" as a core competency for embedded programmers rather than good grounding in C or Assembly alone which prompted this (admittedly rather hasty and not well thought-out) question

Your question begets reasonings as to whether there is utility in learning C++ - I think you were asking for a debate.

Most people writing job requisitions don't really know what they are writing, so don't let that influence your views.

C++ originated as an extension to C, but grew into a language on its own.

 

To be honest, I don't even know how to differentiate an "embedded" system from a "non-embedded" system anymore. The lines have significantly blurred in the last few years.

 

Carrying my previous post just a tad further, I could argue that a smartphone or tablet is an embedded device.

In that case, Java and the Android API would be worthwhile studying. Mastering these would make the OP more valuable to future employers, I think, much more so than C++.

Oh, and the tools and library are free.