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

0 Members and 1 Guest are viewing this topic.

Offline bogdantTopic starter

  • Regular Contributor
  • *
  • Posts: 80
  • Country: ro
c vs cpp for stm32
« on: January 11, 2019, 07:09:15 am »
Does it make any sense to switch from c to c++? I tried to configure system workbench stm32 to convert a project from C to C++ but this is not trivial. Even it does compile on the target when it try to call contructor gives a hard fault.

Sent from my VTR-L29 using Tapatalk

 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: c vs cpp for stm32
« Reply #1 on: January 11, 2019, 09:06:48 am »
Quote
Does it make any sense to switch from c to c++?
Yes.

Quote
but this is not trivial.
It SHOULD be trivial.   See the Arduino Environment, for example.  Vanilla C should compile fine with C++, and immediately give you useful features like function overloading and better type checking.
Just because you've switched to C++ doesn't mean you can go wild with STL and dynamic memory allocation, though (some would argue that therefore, "it isnt' really C++")

 
The following users thanked this post: Fungus

Offline shangaoren

  • Regular Contributor
  • *
  • Posts: 53
  • Country: fr
Re: c vs cpp for stm32
« Reply #2 on: January 11, 2019, 02:45:08 pm »
Try atollic instead of system Workbench, this is the new tool of ST Microelectronics and this is better than system workbench.

It's not easy to convert a project, i suggest you to start an another and copy/paste your files instead.

If you do a project in c++ you will not want to do C anymore
 
The following users thanked this post: thm_w, bogdant

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: c vs cpp for stm32
« Reply #3 on: January 11, 2019, 05:12:33 pm »
Yes it makes sense. You end up with code that is easier to read (for you and everyone else) and write, easier to use, and probably less prone to errors as a result. It doesn't even require the use of many c++ features to see the benefits. The size of the compiled code will tell you when its not a good idea to use a particular c++ feature, so its not difficult to stay away from the 'heavy' parts.

If your micro of choice has an available c++ compiler, take advantage of it.
 
The following users thanked this post: bogdant

Offline twiddle

  • Contributor
  • Posts: 19
  • Country: au
Re: c vs cpp for stm32
« Reply #4 on: January 11, 2019, 10:45:34 pm »
Double check your linker script and startup code integrate properly with the C++ runtime.
I'm not on my dev machine at the moment but I'm quite certain my linker script had to add additional sections to store constructors for static objects and so on, and startup code to call those constructors during runtime initialization - at a guess I'd say your hard fault is possibly related.
I've been using C++ on STM32 chips for a few years without issues now - I'm actually working on a 'pure' C++ framework that provides a type-safe and zero-cost alternative to the CMSIS headers etc, so it definitely is possible to do and can provide benefits, if you avoid most of the STL and dynamic allocation.
 
The following users thanked this post: bogdant

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: c vs cpp for stm32
« Reply #5 on: January 12, 2019, 02:27:56 am »
Quote
Even it does compile on the target when it try to call contructor gives a hard fault
In addition, it could also be you are not getting the compiler options set for g++, like a missing -mthumb for example would end up producing 32bit code I think, and get you an exception. If you can get your build environment to show the command output when compiling you could at least see what options are making it to the compiler.

this folder has a simple c++ app, and is pretty bare-
https://github.com/cv007/Samd10XplainedMini
but maybe the linker script and startup file has some info that could help
it looks like __libc_init_array() called from the startup file does the c++ init work, and about a quarter of the linker script deals with c++ it seems
 
The following users thanked this post: bogdant

Offline Nerull

  • Frequent Contributor
  • **
  • Posts: 694
Re: c vs cpp for stm32
« Reply #6 on: January 12, 2019, 03:23:01 am »
Quote
Does it make any sense to switch from c to c++?
Yes.

Quote
but this is not trivial.
It SHOULD be trivial.   See the Arduino Environment, for example.  Vanilla C should compile fine with C++, and immediately give you useful features like function overloading and better type checking.
Just because you've switched to C++ doesn't mean you can go wild with STL and dynamic memory allocation, though (some would argue that therefore, "it isnt' really C++")

Not all valid C code is valid C++ code, for example unions are commonly used in C microcontroller APIs for type punning of registers, but this is undefined behavior in C++ - only the last assigned member of a union should be accessed, and compilers are free to pack variables in ways that make the behavior unpredictable.

How strictly any given compiler enforces the difference between the standards is another question. GCC does support using unions this way via a compiler extension.
« Last Edit: January 12, 2019, 03:29:41 am by Nerull »
 
The following users thanked this post: bogdant

Offline bogdantTopic starter

  • Regular Contributor
  • *
  • Posts: 80
  • Country: ro
Re: c vs cpp for stm32
« Reply #7 on: January 12, 2019, 07:45:26 am »
thank you all for help. I will try.

Sent from my VTR-L29 using Tapatalk

 

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3476
  • Country: us
Re: c vs cpp for stm32
« Reply #8 on: January 12, 2019, 10:11:13 pm »
Each object in C++ consists of a structure containing all the public and private variables *and* pointers to all the methods applicable to the class.  That consumes quite a lot of memory.

As for readability, that is *entirely* a function of whether the author attempted to write readable code.  If you encounter something such as:

{ new A a;
   new B b;
   new C c;

    d = a + b + c;
}

you may need to read a *lot* of code to find out what that assignment does.  And if *any* of the classes use multiple inheritance you'll also need to read the compiler implementation notes and the C++ standard.  If you're using g++ you may not be able to find out what happens except by single stepping at assembly level.  For extra entertainment, it may be different with the next release of the compiler.

The  difference between C and C++ is purely syntactic.  There is nothing that can be done in C++ that can't be done in C.

Twenty years ago I wrote a string substitution module which given a character string returned another character string in C and in C++.   It had functions to insert and remove string pairs and to convert them. The C version was a 1/2 page.  The C++ version was 3 pages.  All done in the best style as advocated by Meyers, Lakos, Cargill and other authors.  That was the last time I wrote anything in C++.

The 3-4 ft of books on OOP and C++ are the least used books in my library by far.  I don't ever use C++ unless I'm modifying an existing C++ code.  And that is something I try to avoid.

A major virtue of C is that it is easy to understand what the hardware does when it executes a statement.  That is not true of C++.   In 20+ years I've not encountered a C++ enthusiast who actually understood at the HW level what their code actually did.

On the job where I wrote the string substitution, I had posted a page from Lakos on linking large C++ projects on my door.  It was generally ignored until 6 months later when compiles started taking massive amounts of time.  It took a team of 4-5 C++ programmers 6 weeks to fix the mess they had made.  But one of them had paid attention to the post on my door and pulled a copy out of his desk drawer when they hard to rearchitect the mess.

One of my side functions throughout my career was explaining the nuances of various languages (mostly C & FORTRAN) and the compiling, linking and execution phase processes to a host of coworkers. And I started most of my jobs making 500,000+ lines of someone else's code compilable just to be able to actually do what I'd been hired to do.

 
The following users thanked this post: Siwastaja, bogdant, sundance

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: c vs cpp for stm32
« Reply #9 on: January 12, 2019, 10:31:39 pm »
Each object in C++ consists of a structure containing all the public and private variables *and* pointers to all the methods applicable to the class.  That consumes quite a lot of memory.
All C++ compilers I know use some form of virtual method table. Vtables are also only used if the class has virtual functions, since they're not needed for static dispatch.

Quote
The  difference between C and C++ is purely syntactic.  There is nothing that can be done in C++ that can't be done in C.
That hasn't been true since at least C++11.
 
The following users thanked this post: hans, bogdant

Offline 17_29bis

  • Regular Contributor
  • *
  • Posts: 81
  • Country: ca
Re: c vs cpp for stm32
« Reply #10 on: January 12, 2019, 11:18:14 pm »
If you do a project in c++ you will not want to do C anymore

It would be really great to hear why is that. Could you please share with us what projects you have done in C++ (for MCU, specifically the ones that could not be done in C) and how C++ helped you in those cases? No, seriously  :)




 
The following users thanked this post: bogdant

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3476
  • Country: us
Re: c vs cpp for stm32
« Reply #11 on: January 13, 2019, 01:09:38 am »
Each object in C++ consists of a structure containing all the public and private variables *and* pointers to all the methods applicable to the class.  That consumes quite a lot of memory.
All C++ compilers I know use some form of virtual method table. Vtables are also only used if the class has virtual functions, since they're not needed for static dispatch.

Quote
The  difference between C and C++ is purely syntactic.  There is nothing that can be done in C++ that can't be done in C.
That hasn't been true since at least C++11.

As the proof you are wrong is almost 80 years old I think I'll let you argue with Alan Turing.
 
The following users thanked this post: bogdant

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: c vs cpp for stm32
« Reply #12 on: January 13, 2019, 03:06:48 am »
Quote
specifically the ones that could not be done in C
There is nothing that can be done in C than cannot also be done in assembly. I assume you don't program in assembly. The same applies to C++. You pick a language because its easier/more reliable/better in some way than any previous language you were using.

I'm sure there were (or still are a few) assembly language programmers who said they would never use c for any number of reasons (too bloated, too slow, not necessary, I lose control, I can create better code, etc.)., but in most cases you would now say they are silly to not make use of a c compiler. To some degree c++ vs c is somewhat the same- if you have a c++ compiler available why not at least check it out, it may make your job/hobby easier or more enjoyable.

Quote
Twenty years ago I wrote ...That was the last time I wrote anything in C++.
I think a lot has changed in 20 years.

I probably should not be showing my code because maybe I'm doing it all wrong-
https://github.com/cv007/PIC32MM_Curiosity_CPP/blob/master/cable_test.cpp

but I like how easy things become in c++, and this was a simple cable tester I needed quickly and was quickly made
(I previously wrote all the 'drivers' for the pic32mm in c++, so had everything in place- you are only one header or source file away from seeing the source, which I think is readable and as close to the hardware as c, I also wrote the usb 'driver' in c++)
you could argue that everything could be done in c, and you would be right, just as it could also be done in assembly, but I find I can organize code much better, don't have to struggle with coming up with function names, and generally end up with much better/more reliable code that I find much easier to read and write.

I also am able to apply any c++ skills I have accumulated to other things- arduino-esp32, various pc code, and simply being able to read code from projects I'm interested in that happen to use c++.

It sure looks like I wrote too much :)
 
The following users thanked this post: bogdant

Online hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: c vs cpp for stm32
« Reply #13 on: January 13, 2019, 09:02:03 am »
Each object in C++ consists of a structure containing all the public and private variables *and* pointers to all the methods applicable to the class.  That consumes quite a lot of memory.
All C++ compilers I know use some form of virtual method table. Vtables are also only used if the class has virtual functions, since they're not needed for static dispatch.

Quote
The  difference between C and C++ is purely syntactic.  There is nothing that can be done in C++ that can't be done in C.
That hasn't been true since at least C++11.

As the proof you are wrong is almost 80 years old I think I'll let you argue with Alan Turing.
Stuff you can do with C/C++ sure.
Stuff you can do in C++ is so much powerful. Templates is very flexible. There is better support for compile-time expressions for your project using constexpr.
 
The following users thanked this post: bogdant

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3476
  • Country: us
Re: c vs cpp for stm32
« Reply #14 on: January 13, 2019, 02:03:28 pm »
In SunOS 4.1.1 an xclock display consumed a few KB of memory.  On OpenIndiana Hipster running Mate, the same display consumes 80 MB.  The reason for the fantastic bloat is OOP frameworks.  I did a *lot* of DSP on *time shared* VAXen with 4 or 5 MB of DRAM over the course 4 years.  And probably worked another 10 years before I had a system with more than 64 MB of core.  I worked in the oil industry and usually had the latest workstation.  Though I did demand my old system back when I found a new workstation on my desk after I returned from a few days off. 

You can't run Firefox on a machine with less than 4 GB of DRAM today.  We used to know exactly what the machine did, but now no one knows.

C is not C++.  C/C++ is head hunter speak.

Try debugging 500,000 lines of C++ code you've never seen before and which has no documentation or internal comments other than the author's name.  Try setting a few breakpoints at the entry to some functions.  If you don't a priori know the names of the methods called in the constructors of the parent classes you are going to spend a lot of time researching the parent classes.  That gets really tedious if all you have are header files and libraries.

Can it be done?  Yes.  But is is *very* time consuming and absolutely necessary if the problem is a failure of a constructor to properly initialize an object.  If the bug is 4-5 layers deep in the inheritance tree it will take a lot of work to fix.
 
The following users thanked this post: bogdant

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: c vs cpp for stm32
« Reply #15 on: January 13, 2019, 02:48:13 pm »
Does it make any sense to switch from c to c++?

If you feel it is better to implement your design in C, do it in C. If you feel it is better to implement your design in C++, do it in C++. Either choice will not improve your design. It is merely a matter of convenience to you. Of course, other people cannot tell you what is more convenient to you.

If you don't see the difference (and if you're asking you probably don't), then there's no reason to waste time and efforts on switching.
 
The following users thanked this post: bogdant

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: c vs cpp for stm32
« Reply #16 on: January 13, 2019, 03:48:51 pm »
Convenience to you, but inconvenience for anybody else, who will try to fix your C++ gibberish, hi hi!  >:D
 
The following users thanked this post: rhb, bogdant

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: c vs cpp for stm32
« Reply #17 on: January 13, 2019, 04:41:14 pm »
C is not C++.  C/C++ is head hunter speak.

Could not agree more.
 
The following users thanked this post: Ribster, bogdant, JPortici

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1924
  • Country: us
Re: c vs cpp for stm32
« Reply #18 on: January 13, 2019, 06:29:36 pm »
Oh boy, this argument again! Apparently I can get my annual rant on this topic out of the way nice and early in 2019.

Folks need to remember that C is, essentially, a portable Assembly language. It was designed and intended to be a "mid-level" language, trading a bit of Assembly's efficiency for portability across platforms. There's a lot of value in that tradeoff, because it allows the investment in debugged code to be migrated to different/new hardware/OS environments. And the industry has responded, resulting in some processors having their instruction sets specifically optimized for C language constructs - making it easier for compilers to generate efficient code from C source.

But, as with virtually every discipline (hardware, software, mechanical, even the design of governments [I'm thinking of you, US Constitution]), when you insist on glomming a bunch of later features that go way beyond the scope of the original intent, you get "spaghetti code". The glommed-on features are usually poorly implemented and awkward to use. Meanwhile, they often conflict with the original architecture and interfere with some/all of the original features. A nice lose-lose arrangement.

Consider two examples:

1) C++. I'm sorry, but the best feature of C++ is its // comment operator so you don't have to terminate comments with */. If you don't hate C++, you haven't debugged something like overloaded functions written by strangers you've never met. In what universe is it a good idea to have multiple entities share the exact same name? A call to an overloaded function name means you don't really know where your code is going. Good luck if those overloaded functions are in some library for which you don't have the source. And I can't imagine a sufficiently painful punishment for whomever added dynamic polymorphism, where you literally don't know and may not even be able to predict what functions will be called when, now or in the future! I realize this sort of thing replaces normal sexual excitement for Computer Science postdocs, but in the real world these sorts of language "features" literally enable bugs and exploits that are hideously difficult to find and fix. I can't prove this, but after lots of conversations I'm convinced that the obtuseness and opacity of environments like C++ cause Engineers to just throw up their hands and declare something "done" because there's simply not the time nor money nor management support to find and test the edge cases. And C++ *creates* such edge cases, as when user input can basically randomize your execution path (choice of called function dependent upon what the user types now/today/next week). It's entirely possible that the first "real user" will invoke function(s) never before called during alpha and beta testing, with unknown and untested results. Insanity! C++ insures perpetual profitability for the antivirus industry.

2) Java. Sort-of-C, sort-of-C++, with yet another layer Rube Goldberged into the mess. Every time you turn around there's another weird special case that is painfully and obviously due to the effort to add something that doesn't quite "fit" with the base language. I'll admit functions like BigDecimal() are handy, but there's nothing Java-specific about that. If Object Orientedness is the goal, use a language designed from the ground up with that in mind. There's no shortage of them out there... why hobble yourself with some hybrid, bastardized FrankenLanguage like Java?

I'm sure I've offended some folks with the above. But after ~40 years of writing software and firmware in all sorts of OS and embedded environments, these are my conclusions. Yours may vary, and that's fine, but I've reached the point in my career where I can turn down projects that are artificially handicapped because someone demands we use their favorite OO-hybrid language to implement an LED flasher. Wrangling projects to successful completion is hard enough without intentionally lashing oneself to such an anchor. Tools are supposed to make jobs EASIER, not more difficult.

Just my $0.02, and worth no more than you paid for it! {grin}
« Last Edit: January 13, 2019, 06:37:40 pm by IDEngineer »
 
The following users thanked this post: rhb, Vasi, Gabri74, Siwastaja, bogdant, Jacon, sundance

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: c vs cpp for stm32
« Reply #19 on: January 13, 2019, 06:45:50 pm »
1) C++. I'm sorry, but the best feature of C++ is its // comment operator so you don't have to terminate comments with */.

You seem you haven't programmed in C much if at all, have you?  Otherwise you would not argue that // comment is the feature of C++. :)

//EDIT: OK, I know it was introduced with the C++, but it does not limit you to use this only in C++ these days. C compilers understand that well, that's what I meant by the comment above. I would not list that as a feature why C++ should be used instead of C. That simply I think is invalid argument. Otherwise I acknowledge your points stated and add myself to the crowd of C++, C# and Java haters.
« Last Edit: January 13, 2019, 06:51:42 pm by Yansi »
 
The following users thanked this post: bogdant

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: c vs cpp for stm32
« Reply #20 on: January 13, 2019, 07:00:48 pm »
Oh boy, this argument again! Apparently I can get my annual rant on this topic out of the way nice and early in 2019.

Folks need to remember that C is, essentially, a portable Assembly language. It was designed and intended to be a "mid-level" language, trading a bit of Assembly's efficiency for portability across platforms. There's a lot of value in that tradeoff, because it allows the investment in debugged code to be migrated to different/new hardware/OS environments. And the industry has responded, resulting in some processors having their instruction sets specifically optimized for C language constructs - making it easier for compilers to generate efficient code from C source.

But, as with virtually every discipline (hardware, software, mechanical, even the design of governments [I'm thinking of you, US Constitution]), when you insist on glomming a bunch of later features that go way beyond the scope of the original intent, you get "spaghetti code". The glommed-on features are usually poorly implemented and awkward to use. Meanwhile, they often conflict with the original architecture and interfere with some/all of the original features. A nice lose-lose arrangement.

Consider two examples:

1) C++. I'm sorry, but the best feature of C++ is its // comment operator so you don't have to terminate comments with */. If you don't hate C++, you haven't debugged something like overloaded functions written by strangers you've never met. In what universe is it a good idea to have multiple entities share the exact same name? A call to an overloaded function name means you don't really know where your code is going. Good luck if those overloaded functions are in some library for which you don't have the source. And I can't imagine a sufficiently painful punishment for whomever added dynamic polymorphism, where you literally don't know and may not even be able to predict what functions will be called when, now or in the future! I realize this sort of thing replaces normal sexual excitement for Computer Science postdocs, but in the real world these sorts of language "features" literally enable bugs and exploits that are hideously difficult to find and fix. I can't prove this, but after lots of conversations I'm convinced that the obtuseness and opacity of environments like C++ cause Engineers to just throw up their hands and declare something "done" because there's simply not the time nor money nor management support to find and test the edge cases. And C++ *creates* such edge cases, as when user input can basically randomize your execution path (choice of called function dependent upon what the user types now/today/next week). It's entirely possible that the first "real user" will invoke function(s) never before called during alpha and beta testing, with unknown and untested results. Insanity! C++ insures perpetual profitability for the antivirus industry.

You seem you haven't programmed in C much if at all, have you?

Otherwise you would not argue that // comment is the feature of C++.

Although a very anecdotical point in IDEngineer's post, the // comment in C has actually been officially introduced in the C99 standard. Before that, it was not standard C (although many C compilers had already added this, but that was an unofficial extension) and thus, only an official "feature" of C++. I guess that was his point and was kind of ironic too. You could argue that C99 is 20 years old already, but actually only a very few C compilers were C99 compliant until only just a few years ago (the fact most of them supported the // was again not the sign of any kind of compliance).

The rest of IDEngineer's arguments were more interesting that this humourous sentence.
 
The following users thanked this post: bogdant

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: c vs cpp for stm32
« Reply #21 on: January 13, 2019, 07:09:15 pm »
Well I do not know if this is anecdotical or not, but I would not argue about the comment style in any way. (After all, I prefer the /**/ style of comments, they look better  >:D )
 
The following users thanked this post: bogdant

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1924
  • Country: us
Re: c vs cpp for stm32
« Reply #22 on: January 13, 2019, 07:22:49 pm »
the // comment in C has actually been officially introduced in the C99 standard. Before that, it was not standard C (although many C compilers had already added this, but that was an unofficial extension) and thus, only an official "feature" of C++.
Thank you! I presumed your comments were common knowledge, but apparently not.

There's a reason /**/ is called "C Style" and // is called "C++ Style". First hit on Google:

Quote
Single-line comments (informally, C++ style), start with // and continue until the end of the line. If the last character in a comment line is a \ the comment will continue in the next line. Multi-line comments (informally, C style), start with /* and end with */.
 
The following users thanked this post: bogdant

Offline bogdantTopic starter

  • Regular Contributor
  • *
  • Posts: 80
  • Country: ro
Re: c vs cpp for stm32
« Reply #23 on: January 13, 2019, 07:24:59 pm »
So there are pro and cons for c++. When starting a new project on a powerfull stm32f7xx series microcontroller do you consider C++? Do you try to reuse code from PC world to micro?

Sent from my VTR-L29 using Tapatalk

 

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1924
  • Country: us
Re: c vs cpp for stm32
« Reply #24 on: January 13, 2019, 07:28:56 pm »
I would not list that as a feature why C++ should be used instead of C.
I agree, which is why I didn't say that. Let's review:
Quote
...the best feature of C++ is its // comment operator...

I didn't say // was "why C++ should be used instead of C". I said // was the best feature of C++ (which doubled as a backhanded insult against all of the other glop that C++ added to C). And, as SiliconWizard pointed out, // was such a good feature that it was formally added to the C99 standard. Which reinforces my point!
 
The following users thanked this post: bogdant


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf