Why to C over C++?

[jeruzalem 1]

Hi, 

 

I'm new in the MSP430 MCU's I have already written app to drive servos and steppers, now I want to clean up the code to make it a library and I was curious about moving to C++ for code clarity and nice object based code.

 

Because my library will be time critical (I have to use 16MHz to drive 3 steppers and 8 servos at once with customizable stepper speed to reduce servo jitter to zero), my concerns are:

 

- performance hit?

- RAM usage - anything significant?

- any other not so obvious drawbacks?

[chicken 630]

See these two threads:

 

Why, why not? http://forum.43oh.com/topic/2808-coding-for-msp430-in-c/

Example of efficient use of C++ templates: http://forum.43oh.com/topic/2358-software-iic-master-in-c-c-class-and-c-template/

 

I'd say it has its benefits, but might come at a performance and RAM hit too big for the limited resources of an MSP430 if not done carefully.

[roadrunner84 466]

Plain C++ objects take only a few bytes (2) of extra ram. They do however execute all code on member variables which are rrelative to the object. This is no more slow than local variables, but it's z little slower than global variables.

Try to avoid dynamic instantiation of objects (e.g.: the user of the new keyword), as our will invoke a lot of memory allocation functions and requires runtime management of ram. Instead, make objects as you would make primitive types:

Class Object;

Instead of:

Class* Object = new Class();

[yyrkoon 250]

I'd say it has its benefits, but might come at a performance and RAM hit too big for the limited resources of an MSP430 if not done carefully.

 

Just like C . . .

 

You just need to pay attention is all, just like when using any other language.

 

About a month or so ago, one user on these forums was experiencing issues with their MSP430G2553 project. They were not  sure of the problem, but when I examined the code I noticed 2-3 different issues. One drawing my attention more than the rest.

 

char somevariable[50]; <--- as a global ! Not sure of the actual number, but it was using roughly 400 bytes, all the time.

 

Second problem was running a fairly deep function "queue". Needless to say, the program would run briefly before crashing.

 

Anyway, my point being. It really does not matter which language you use. You need to pay attention to what you do no matter what.

 

Also, there are some bonuses to using each language. Such as the template classes used with opossum's template class code. When "something" is known at compile time, this "something" can be taken care of at compile time, versus run time. Thus, making the code *possibly* smaller, and faster. Again, you need to pay attention to whats going on.

 

Personally, coming from an OOP background in the last several years of my programming "career"( quoted because it is a hobby, and not a profession). I am a very strong advocate of using just about any OOP type language. With that said however, there is no reason why not to in this case to mix C with C++. Use each where it makes most sense. No point in being a purist, when being a purist will only work against you.

[jpnorair 340]

My opinion is that C makes you a better programmer, and C++ a worse one.  Sure, there are exceptions to every rule, but I've been doing this a long time, and I haven't ever had a reason to change my opinion.

 

To get another, slightly less philosophical perspective, see linus.  Bascially, I agree 100%.

 

In microcontrollers, the difference isn't so much with the standard libraries... because they don't exist.  The difference is the fact that object oriented design philosophy usually leads to architectures that are less conducive for performance and power optimization.  Contiguous memory is a big deal in systems that have lousy memory movement (like MCUs).  If you ever think you might care about optimization, it's better to avoid object orientation and instead think about data type orientation.  C++ without object orientation might as well be C.

[jeruzalem 1]

Thanks all of You,

 

looks like there is a lot to try and see how well it works. I'll try to examine assembly created by CCS, maybe I will come out with something interesting.

 

Also I'll check this GPIO template stuff for performance improvement.

[yyrkoon 250]

My opinion is that C makes you a better programmer, and C++ a worse one.  Sure, there are exceptions to every rule, but I've been doing this a long time, and I haven't ever had a reason to change my opinion.

 

To get another, slightly less philosophical perspective, see linus.  Bascially, I agree 100%.

 

In microcontrollers, the difference isn't so much with the standard libraries... because they don't exist.  The difference is the fact that object oriented design philosophy usually leads to architectures that are less conducive for performance and power optimization.  Contiguous memory is a big deal in systems that have lousy memory movement (like MCUs).  If you ever think you might care about optimization, it's better to avoid object orientation and instead think about data type orientation.  C++ without object orientation might as well be C.

Again . . . 

 

Being a bad programmer makes you a bad programmer. You and Linus can both agree all you two want, but that does not make either of you right.

 

C can not do function overloading . . . C can not do templates . . . C++ *can* do anything C can do and more.

 

Templates can lend towards faster, more efficient, and smaller code. Sometimes which can be hard to reproduce even with carefully hand crafted assembly language. 

 

Just a few points there, some being more significant than you, or Linus realize, apparently.  But running the risk of sounding like an ass, where I am not trying to be. It seems to me that you, and Linus are both of the mindset that C++ is bad, without actually laying hands on C++. However, I really have no idea how Linus actually thinks, just going by what you're saying. Whatever the case, it matter little to me, as I tend to think for myself.

 

So, if you have a specific case to bring up that does not rely on developer coding style/habits. Which are based on fact, then perhaps you're on to something. However, with that said, I really do not think you can bring anything up that has already been rendered as moot. C++ relies heavily on C. So I feel that if a bit of C code would do a specific job better, that it would be foolish to not use C in that given case. However, the reverse is also true.

 

So yeah I am of the opinion that purist ideals hold no real "value" in this context. But feel free to do as you please

[yyrkoon 250]

Thanks all of You,

 

looks like there is a lot to try and see how well it works. I'll try to examine assembly created by CCS, maybe I will come out with something interesting.

 

Also I'll check this GPIO template stuff for performance improvement.

 

Sounds as though you're on the right path for you. On a personal level, I really do not care which language you do use. Basically whatever makes *you* happy, but I think if you do for yourself as oPossum has demonstrated a few times on these forums. That you'll be pleasantly surprised, with what you can do / come up with using C++. It wont be like using standard C++ for x86, but it can make your life a whole lot easier / better. And there will be some trade off's between C/C++.

 

For example. . .

 

With my own Serial implementation that I currently use( which is largely based on other peoples code, "twisted" for my own use). I made such a trade off by overloading the "<<" operator to use cout like syntax. At the cost of 15-20 bytes of FLASH, for every use. Depending on the project I use this for, I find this more than acceptable. However, if code size is getting close to max, I can always remove this Feature, and use Object.Print("Sometext"); with no additional overhead.

 

Anyhow, the two people to talk to really would be Rickta59, and oPossum. Both seem to know ASM, C, and C++ very well , and have done extensive testing. Me, I am just following in their footsteps, and finding  some really interesting results.

[Rickta59 589]

by overloading the "<<" operator to use cout like syntax. At the cost of 15-20 bytes of FLASH, for every use

If setup properly, the insertion operator shouldn't cost any more than the print

[yyrkoon 250]

// Generic char, and string template

template<class T> inline Debug_t &operator << (Debug_t &obj, T param){obj.Write(param); return obj;}

// int32_t type specialization.

template<> inline Debug_t &operator << <int32_t>(Debug_t &obj, int32_t param) {obj.Write(param, BASE); return obj;}

...

// uint8_t type specialization.

template<> inline Debug_t &operator << <uint8_t>(Debug_t &obj, uint8_t param){obj.Write(param, BASE); return obj;}

 

You tell me Either way, I am perfectly happy with this code.

[Rickta59 589]

you might change your param values to be const

[yyrkoon 250]

Ok, good spot, I actually did have plans on looking into that lol because I believe you had mentioned that to me before. Seems I got sidetracked, then forgot about it.

[mpymike 18]

This is an interesting topic....

For a 4k/16k code space microcontroller I'm in the "I prefer C camp"

The C compiler basically maps your C program directly into machine code.
This means you have more direct control over what machine code is generated.
This is most important when trying squeeze the last ounce of function out of each rom byte.

When you use the OO features of C++ then the implementation in machine code level is not
so obvious and intuitive. (not unless you are a C++ compiler expert).

Secondly when trying to explain to somebody the basics of how a piece of code turns into
the ones and zeros that are flashed into the rom, it is much easier to demonstrate this using
simple C constructs like simple 'for' loops. In fact virtually every C statement can be easily
explained.  High level OO constructs would introduce too much abstraction. 

 

[jpnorair 340]

Being a bad programmer makes you a bad programmer. You and Linus can both agree all you two want, but that does not make either of you right.

That's a central point for both me and Linus, though.  If you have an open source project, it is easier to manage if it is being worked-on by a smaller number of good programmers than a larger number of less-than-good programmers.  If I can use C to prevent less-than-good programmers from contributing code, that's a great attribute of C.  Generally, I find this works, too.

 

It is important to understand that I am not interested in the language features of C++ or, really, any programming language in particular.  Programmers who argue about one language feature against another aren't really people I want on my projects.  Coders who obsess about language features tend not to obsess about the performance of the product.  The hallmark of modern language features -- maintainability of source trees in group programming -- is not really important for embedded products due to the way hardware is released.  Performance, however, is very important.  (I'd also argue that Git and things like it make source-tree maintainability a different issue than it was when C++ and Java were being developed).

 

Lastly, "being right" in this matter is purely a function of doing.  Most great software and firmware is still done in C (especially true with open source software).  If you make a great piece of C++ software, then it is right.

[yyrkoon 250]

That's a central point for both me and Linus, though.  If you have an open source project, it is easier to manage if it is being worked-on by a smaller number of good programmers than a larger number of less-than-good programmers.  If I can use C to prevent less-than-good programmers from contributing code, that's a great attribute of C.  Generally, I find this works, too.

 

It is important to understand that I am not interested in the language features of C++ or, really, any programming language in particular.  Programmers who argue about one language feature against another aren't really people I want on my projects.  Coders who obsess about language features tend not to obsess about the performance of the product.  The hallmark of modern language features -- maintainability of source trees in group programming -- is not really important for embedded products due to the way hardware is released.  Performance, however, is very important.  (I'd also argue that Git and things like it make source-tree maintainability a different issue than it was when C++ and Java were being developed).

 

Lastly, "being right" in this matter is purely a function of doing.  Most great software and firmware is still done in C (especially true with open source software).  If you make a great piece of C++ software, then it is right.

 

Point is, you're the only one arguing about what is best, and what is not.  My whole stance has been ( going back what now ? 2-3 months ). Be flexible, and use what makes sense.  Of course, if your experience is limited, your options for what makes sense  is also by default going to be limited.

 

I bet you would make little fuss about someone talking about using inline ASM right ? Same difference here, think about it.