Author Topic: c vs cpp for stm32  (Read 26894 times)

0 Members and 1 Guest are viewing this topic.

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3476
  • Country: us
Re: c vs cpp for stm32
« Reply #50 on: January 14, 2019, 04:22:19 pm »
A well written C++ code can be more efficient than C or assembler one
You do realize that claim is completely preposterous, or a straight lie?  That is exactly the kind of argument that has negative value in a serious discussion.

Nothing can be more efficient than assembly code, because is is just an exact representation of the machine code compilers generate. 

If you read some books on modern compilers and computer architectures, e.g. Muchnick and Patterson and Hennessy you'll learn how and why good compilers can generate much better assembly code than humans.

It's rather like a computer chess program.  The computer can look far deeper into the future execution path than a human.  A 1 cycle reduction now may mean a 10 cycle penalty 1000 instructions from now.

But claiming that C++ compilers can generate better code than C compilers is silly.   Dereferencing a method pointer at run time costs cycles.   And those method pointers take up space.  By design C++ takes more space and cycles for the same result.

If you use tight encapsulation in C you can get the same result, but the addresses will be bound at compile time.  No pointer dereferences or method tables required.  You'll get the benefit of the deep look ahead and the actual result at run time will be far more predictable.

@NorthGuy is quite correct about OOP.  OOP trades space and execution time for programmer convenience.  Sometimes this is useful.  But I think the main contribution OOP has made is that it lets people pretend that they know how to program.
 
The following users thanked this post: bogdant

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 708
  • Country: us
Re: c vs cpp for stm32
« Reply #51 on: January 14, 2019, 04:37:10 pm »
With apologies to the graybeards on here, the first several posts in the thread have it right.  If a decent C++ compiler is available for your architecture, you should seriously consider using it.  Used properly, embedded C++ imposes no size nor speed penalty, while providing better code organization and readability.  Anyone telling you otherwise is speaking from ignorance or outdated "experience," incorrectly generalized.  :box:

Some wacky features of modern C++ like constexpr metaprogramming have the potential to make embedded C++ *more* efficient than C:  see for example the Kvasir project (https://github.com/kvasir-io/Kvasir).  Setting that aside, let's settle for being merely as efficient as C.  Write your code exactly as you did before in C, but take advantage of classes and namespaces to better encapsulate your modules.  Don't use the STL.  Don't use inheritance at all, or if you must, only simple inheritance.  Presto: better code.  Are the method calls longer in this case than the same function calls would be in C?  Well, everything is known at compile time so in theory the compiler should be able to do an equivalent job.  If there is a difference it would be on the order of a handful of instructions, so if that matters then we should be advocating for stuffing as much code into a single C function as possible, to avoid the overhead of function calls to begin with...

The only valid argument I ever heard against C++ in embedded design came from one of our clients who said, "you may know how to use C++ wisely, but after the code is turned over to my team, they will do stupid things which they couldn't do in C, so I insist that you write the code in C."  He had a point.
« Last Edit: January 14, 2019, 04:47:27 pm by mark03 »
 
The following users thanked this post: bogdant

Offline Omicron

  • Regular Contributor
  • *
  • Posts: 142
  • Country: be
Re: c vs cpp for stm32
« Reply #52 on: January 14, 2019, 05:29:15 pm »
The only valid argument I ever heard against C++ in embedded design came from one of our clients who said, "you may know how to use C++ wisely, but after the code is turned over to my team, they will do stupid things which they couldn't do in C, so I insist that you write the code in C."  He had a point.

And that is exactly the reason I don't use C++ anymore. I started as a software engineer in 1992. I've used C++ for a very long time and I used to be a strong advocate for it. The arguments pro are correct. C++ offers a lot of nice features and you can write very clean code in it. The problem with C++ is that C++ is complex. Very complex! In fact it is so complex that every C++ programmer I've ever met, including myself, only uses a subset of the language. Unfortunately this subset is different for everyone. And that is the problem! It's not at all uncommon for someone to have years and years of C++ experience to not even be able to read C++ constructs written by another programmer. Why? Not because the code was bad or intentionally obscure. No, simply because of cultural and style differences that cause both programmers to be proficient in different subsets of the language. Some programmers revel in the advanced meta/template programming features while others never go beyond the particular features used by whatever framework or company guidelines they are working with. If you think you master C++ you are most certainly wrong! And with every new release of C++ the problem becomes worse. This is where C shines. It is simple! And for me that simplicity trumps all the advantages C++ has to offer. It is (if memory serves me) also the reason Linus religiously sticks to C for Linux. He was absolutely right to do so. C++ tries to be too many things to too many people.
 
The following users thanked this post: Siwastaja, bogdant, Jacon, sundance

Online IDEngineer

  • Super Contributor
  • ***
  • Posts: 1924
  • Country: us
Re: c vs cpp for stm32
« Reply #53 on: January 14, 2019, 05:42:02 pm »
C++ tries to be too many things to too many people.
Bingo.

As I said earlier: C was intended to be a portable Assembly language. If you want a "high level" language, there are plenty to choose from that were written that way from Day One and their underlying architecture reflects this. They're not doomed to seek backwards compatibility with a language written for a completely different purpose.

The ideas behind C++ (and Java, and...) have their place. But that place is NOT by adding layers of complexity while weaving in backwards compatibility to an existing language that had totally different goals. The results of such forced marriages are nearly always exactly what Omicron just stated.

And with every new release of C++ the problem becomes worse.

How ironic that all of this effort has been expended to make code easier to write and (especially) easier to support, yet the actual result is the exact opposite. Ironic, but not unpredictable!
 
The following users thanked this post: bogdant

Online IDEngineer

  • Super Contributor
  • ***
  • Posts: 1924
  • Country: us
Re: c vs cpp for stm32
« Reply #54 on: January 14, 2019, 06:16:34 pm »
I work for one of the largest defense contractors in the world and I can tell you that after my department is done (the modeling and simulations part) the deployment is done in C++ and java.
Isn't DOD code supposed to be in Ada?  >:D
 
The following users thanked this post: bogdant

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: c vs cpp for stm32
« Reply #55 on: January 14, 2019, 06:55:19 pm »
LOL, here I am: I do Ada for avionics! but upstairs, there are guys of space and defense, and they use C++
One of them told me that he still uses DSP56000 assembly for a weird radar engine
And I am 99% sure that the weather station in the CEO office is programmed in TiniJava

and in Automotive, F1, a guy in the MM team told me that they sometimes use OCam for their internal stuff.


So ...  :-//
 
The following users thanked this post: bogdant

Online IDEngineer

  • Super Contributor
  • ***
  • Posts: 1924
  • Country: us
Re: c vs cpp for stm32
« Reply #56 on: January 14, 2019, 07:12:27 pm »
Ada... C++... DSP56000 assembly... TiniJava... OCam....

The nice thing about standards is that there are so many to choose from.

Want to give HR fits? Tell them to find a software guy equipped to support all of those projects. Some Modula experience would be helpful too, just in case!
 
The following users thanked this post: bogdant

Offline bson

  • Supporter
  • ****
  • Posts: 2265
  • Country: us
Re: c vs cpp for stm32
« Reply #57 on: January 15, 2019, 12:53:44 am »
GCC's linker generates a function to do all the static initialization: __libc_init_array().
It doesn't.  The linker doesn't generate code, but the default startup may contain a call to libc.  If you replace libc however you will need to provide your own, and you also need to add a call to it when you replace the startup code with your own - or your data segment will be uninitialized.  Trust me.  I learned this the hard way when suddenly everything broke when I upgraded the toolchain...
« Last Edit: January 15, 2019, 12:56:46 am by bson »
 
The following users thanked this post: bogdant

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4922
  • Country: si
Re: c vs cpp for stm32
« Reply #58 on: January 15, 2019, 06:30:16 am »
Yeah things like startup scripts is something you don't have to worry about when compiling C for a OS, because the linker just plops in the standard one by default.

But when you get to compiling C to run on bare metal in embedded devices these scripts are pretty much always provided by the user. They need certain tweaks for specific CPUs and might do things that a OS otherwise does like setting up execution privileges or initializing external RAM so that initialized data can be put there. There are also typically blocks of assembler code somewhere that handle the interrupt and exception vectors. These things can be a major pain to debug if they break for some reason.
 
The following users thanked this post: bogdant

Offline shangaoren

  • Regular Contributor
  • *
  • Posts: 53
  • Country: fr
Re: c vs cpp for stm32
« Reply #59 on: January 15, 2019, 09:14:12 am »
GCC's linker generates a function to do all the static initialization: __libc_init_array().
It doesn't.  The linker doesn't generate code, but the default startup may contain a call to libc.  If you replace libc however you will need to provide your own, and you also need to add a call to it when you replace the startup code with your own - or your data segment will be uninitialized.  Trust me.  I learned this the hard way when suddenly everything broke when I upgraded the toolchain...


Sorry, wrong word, you're right.


Yeah things like startup scripts is something you don't have to worry about when compiling C for a OS, because the linker just plops in the standard one by default.

But when you get to compiling C to run on bare metal in embedded devices these scripts are pretty much always provided by the user. They need certain tweaks for specific CPUs and might do things that a OS otherwise does like setting up execution privileges or initializing external RAM so that initialized data can be put there. There are also typically blocks of assembler code somewhere that handle the interrupt and exception vectors. These things can be a major pain to debug if they break for some reason.

i'm using visual GDB for personal embedded project, the startup file is written in C, it's nicer when a bug shows up  :-+
 
The following users thanked this post: bogdant

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4922
  • Country: si
Re: c vs cpp for stm32
« Reply #60 on: January 15, 2019, 10:17:10 am »
i'm using visual GDB for personal embedded project, the startup file is written in C, it's nicer when a bug shows up  :-+

Yeah i wish more vendors would do that.

Most give it to you in the form of assembler and i sure as heck can't be bothered to translate it to C.
 
The following users thanked this post: bogdant

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1713
  • Country: se
Re: c vs cpp for stm32
« Reply #61 on: January 15, 2019, 12:29:58 pm »
they sometimes use OCam for their internal stuff.
Out of curiosity: would that be occam or OCaml?
While I know nothing about the latter, an MS-DOS compiler with some support for NETBIOS networking for the former was my master thesis in 1990... :blah:
Nandemo wa shiranai wa yo, shitteru koto dake.
 
The following users thanked this post: bogdant

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: c vs cpp for stm32
« Reply #62 on: January 15, 2019, 01:11:10 pm »
Code: [Select]
2016-12-20--01-48-14---2016-12-20--06-22-46 -  dev-lang/ocaml - success - user-990-12-412

I do sometimes updates to their Linux and UNIX systems. This is what they asked.
 
The following users thanked this post: bogdant

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: c vs cpp for stm32
« Reply #63 on: January 15, 2019, 07:48:21 pm »
There are cases where OOP can produce tremendous bloat.

Got an example?
 
The following users thanked this post: bogdant

Online exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: c vs cpp for stm32
« Reply #64 on: January 15, 2019, 08:15:45 pm »
I tried  C++ for an event-driven project (UI) and I'm never going back to C again. With a lot of efforts same things can be done in C, but that would just an attempt to do what C++ can do out of the box.

As usual, a good C code is better than bad C++ code.

PS I allocate memory statically whenever possible.
 
The following users thanked this post: bogdant

Offline mfro

  • Regular Contributor
  • *
  • Posts: 207
  • Country: de
Re: c vs cpp for stm32
« Reply #65 on: January 15, 2019, 08:30:25 pm »
There's a lot more ways to do something in C++ than in C (a very good thing in a team where everybody knows and likes what he's doing).

Just because of this, there is also a lot more you can do the nonsense way.

Unfortunately, at least as it appears to me, a lot more people/teams do the latter...
Beethoven wrote his first symphony in C.
 
The following users thanked this post: bogdant

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: c vs cpp for stm32
« Reply #66 on: January 15, 2019, 09:00:36 pm »
There are cases where OOP can produce tremendous bloat.

Got an example?

I can explain the mechanism. Say, vendor A builds an object framework consisting of enormous number of different objects. He then does something which links the objects together. For example, he provides save/restore capability, where you can save an arbitrary object to a stream and then restore it from there. Since the compiler doesn't know what objects may be contained in the stream being restored, it just has to include the code which can instantiate any of the objects, including VMTs with all the member functions linked in. Vendor B builds an equally magnificent framework. Then the unsuspecting programmer uses couple objects from the framework produced by vendor A, few objects from the framework designed by vendor B, etc. and creates his own framework. And so on until it gets to the end user which does something extremely simple, but gets lots of unused objects from all these frameworks. Sort of junk DNA if you wish - you have to carry it through generations even though it is never used.

Real world example? I was doing some Windows development a long time ago. Microsoft, using C++, had extremely bloated, but yet useless, MFC framework. At the same time Borland, using Pascal, had equally bloated and equally useless VCL object library. I try to avoid such things since then and I think my strategy served me well. I do use OOP for my own things when I see fit.

 
The following users thanked this post: bogdant, Jacon

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3476
  • Country: us
Re: c vs cpp for stm32
« Reply #67 on: January 16, 2019, 12:28:58 am »
I'll give an example, xclock(1).  In the format I've always used it gives the day of the week, month, day, hour and minute.  In X11R4 under SunOS 4.1.x it consumed something on the order of 80 KB.  The identical function under OpenIndiana Hipster with Mate consumes 80 MB!

I had to replace an Atom based machine with 2 GB of memory that I used exclusively for internet access with a Z400 with 8 GB of DRAM just to run Firefox when I updated to Hipster.  Firefox consumes so much memory and has so many memory leaks it's ridiculous.  Before I replaced the Atom based system I had to kill and restart Firefox every day because of the memory leaks.  Interestingly certain web sites caused most of it.

As NorthGuy pointed out, lots of frameworks are not well organized.  So including a single facility will bring with it a huge amount of code.  Use a few frameworks and you're talking a lot of memory.

John Lakos wrote a very good book on the issues.  But sadly no one seems to have bothered to read and apply what he wrote.

I'm one of those greybeards that people don't confront more than once.  I could quote chapter and verse from the transistor and the wire all the way up to the OS and UI layer until everyone's eyes glazed over.  After 10 years of retirement, much of that has been displaced by other things.  So I get very frustrated doing  tasks I used to know forward and backwards.  But put me back in a working environment and in 6-9 months I'll be as good as ever.  I've still got 80 ft of computer books and can read *way* faster than most people.

As far as I'm concerned, if you don't know the standard for the language you're using and *check* it when you do something unusual, know the linker and library behavior in intimate detail, you're not a programmer.  You're an imposter.  Interestingly a recent survey found that over 50% of software developers felt they were frauds.  I was quite astonished that so many had that level of self perception.  At least for them there is hope.  There is none for the other 40%.

If someone puts 100 functions in a file, compiles it and puts it in a library, if you call 1 function out of the 100, the system will allocate memory for all 100.  Because resolving the dependencies  is NP-hard, the problem can only be solved by tight encapsulation and limiting files to only those functions which *must* be in the same file.
 
The following users thanked this post: bogdant, rhodges

Online IDEngineer

  • Super Contributor
  • ***
  • Posts: 1924
  • Country: us
Re: c vs cpp for stm32
« Reply #68 on: January 16, 2019, 03:19:30 am »
Real world example? I was doing some Windows development a long time ago. Microsoft, using C++, had extremely bloated, but yet useless, MFC framework.
OMG, I had finally erased MFC from my memory and then I read this. It'll take a month of therapy to scrape out those experiences again.

Speaking of Windows: When I was doing OS-level and driver development for Windows, I noticed that Microsoft did NOT use C++ in those areas. C++ within MFC? Sure, why not, that's for mere customers to use! But in the actual operating system and the driver framework for it? No C++ to be found. Remember the old "eat your own dogfood" mantra? Well, Microsoft wasn't eating C++ in their critical products. Maybe the Office suite was written in MFC, I wouldn't know about their applications business.

As always, YMMV.
 
The following users thanked this post: bogdant

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4922
  • Country: si
Re: c vs cpp for stm32
« Reply #69 on: January 16, 2019, 06:13:04 am »
Oh Microsoft Office, that sure is a good example of legacy crap dragging on.

As a result on a modern 64bit machine with modern office i had a problem piloting a chart of voltage versus time if the time span was too long. I think something weird happened when time reached 32 768 (surprise surprise signed 16bit int). I think i eventually gave up on the built in time formats and just used hours as a normal float number on the X axis on my graph.

This is just one example of what some old legacy piece of code being dragged on for all these years did.
 

Offline bogdantTopic starter

  • Regular Contributor
  • *
  • Posts: 80
  • Country: ro
Re: c vs cpp for stm32
« Reply #70 on: January 16, 2019, 08:57:38 am »
The video is brilliant, me and my colleagues had a good laugh :-DD
 

Online exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: c vs cpp for stm32
« Reply #71 on: January 16, 2019, 10:38:04 am »
I'll give an example, xclock(1).  In the format I've always used it gives the day of the week, month, day, hour and minute.  In X11R4 under SunOS 4.1.x it consumed something on the order of 80 KB.  The identical function under OpenIndiana Hipster with Mate consumes 80 MB!
I'm not sure what the conclusion here as afaik mate is written in C. So, it's not just about language. Bloatware can be written in any language.

If someone puts 100 functions in a file, compiles it and puts it in a library, if you call 1 function out of the 100, the system will allocate memory for all 100.

Afaik clang/gcc can do "link time optimization" and will strip unused functions. It's called "dead code elimination" or something.

I think, guys, there is a lot of bias in the thread. While I don't like many programs/firmwares written in C++, it's not about language itself. It's just people abuse the technology. Many libraries are horribly huge, but they don't need to. I myself found a middle ground -- chibios + async io + own simple classes for abstraction. I believe code size and memory usage is okay as I'm trying to track resource usage.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: c vs cpp for stm32
« Reply #72 on: January 16, 2019, 01:08:18 pm »
It makes little sense to compare the pc world with the microcontroller world. I find it difficult to find my way around the Linux kernel- therefore I should not use C? Micropython seems to be doing C++ in C and I can't read that either, therefore I should not be using C or anything that resembles C++? Firefox is bloated, therefore I should not use C++ on a SAM10D? Microsoft produces some crappy tool (or tools), so I should stay away from C++?  There should be no requirement that I have to be able to read everyone else's code, or be able to produce the same thing, before I can use a particular language.

here is a simple example of c++ in a small micro-
https://github.com/cv007/Samd10XplainedMini/blob/master/main2.cpp

nothing special, its just me, a compiler, a datasheet, a startup file, a linker script, and everything but the startup file in c++
I'm not familiar with a sam10d, just checking it out, I have no debugger either but only ended up with an exception once (alignment error, which I knew was probably coming so didn't have to struggle with it)
this simple example compiles to about 2.5k, so is not a bloated mess
the simple delay class means I can create as many delays as I want, wherever I want, blocking or non-blocking
the morse class means I can push out any number of messages on any pin, all at different rates if wanted
and everything becomes simple, easy to organize, easy to reason about, and ultimately more reliable
I don't know what this simple example would end up looking like in C, but I'm quite sure I would take the C++ version any day of the week
 
The following users thanked this post: bogdant

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: c vs cpp for stm32
« Reply #73 on: January 16, 2019, 02:21:17 pm »
Microsoft produces some crappy tool (or tools), so I should stay away from C++? 

bah. Sony's tools for the Playstation are made by Microsoft. They are not so crappy as one can imagine but rather brilliant. I don't like Microsoft for products like Windows, but I appreciate Microsoft for products like WindowsCE, which comes from the acquisition of the project "Pulsar". Not made by Microsoft, simply bought and rebranded.

Anyway, there is a very big difference between the C++ used in "Pulsar", and the C++ used in the Windows (even in the Neanderthal Technology, aka NT).

What makes me perplex is that the whole computer science is not producing anything as better as what we had in the 90s.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: c vs cpp for stm32
« Reply #74 on: January 16, 2019, 02:35:44 pm »
and everything becomes simple, easy to organize, easy to reason about, and ultimately more reliable
I don't know what this simple example would end up looking like in C, but I'm quite sure I would take the C++ version any day of the week

Beauty is in the eyes of the beholder. It's the result that matters, not the language. You could've done exactly the same with C, or assembler, for that matter. If you want to use C++, it would be silly to tell you that you should use something else. It doesn't really matter what other people use and what they write.

When you look at a painting, do you really care what kind of brush the painter used to paint it? How silly would that be to tell Raphael that if he used different brushes his paintings would be better? Would his paintings be as good as they are if, instead of following his own path, he would worry about what other painters do?
 
The following users thanked this post: bogdant


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf