STMCubeIDE project start  C or C++ - Page 1
Forum section: electronics / beginners

author: Veketti
author_rank: Regular Contributor
timestamp: December 31, 2023, 08:31:46 am
content: Dear All,Not going to start argue, which is better or which should be used C or C++, but just a simple guestion of the selection in starting project in CubeIDE. So by far I have checked the C option, but I'm unaware what this selection actually does.Basic guestions are, is it ok to select always C++, even though I might not use any object oriented programming? Or it will make the code size bigger or some other hindrance?If using the C -selection am I restricted to use features like string which was introduced in C++ or limited with character arrays only?Thank you

author: pcprogrammer
author_rank: Super Contributor
timestamp: December 31, 2023, 08:56:58 am
content: Using things like string on a memory limited processor is not a good idea.But setting up a new project for C++ and not using any of the ++ functionality should be fine for as far as I know.When using the C selection it does limit you to only using what C and it's libraries provide. It depends on the included libraries what you can use, but keep in mind that when using standard lib it requires you to provide some in and output functions. Here also the size of the available memory can be an issue. Functions like printf need a heap to work.I myself just use C without any libraries.

author: brucehoult
author_rank: Super Contributor
timestamp: December 31, 2023, 09:03:03 am
content: Quote from: pcprogrammer on December 31, 2023, 08:56:58 amThere's no reason for printf to need a heap. Any temporary space needed can be allocated on the stack.Maybe some printf uses the heap but that's just bad programming, or at least a libc unsuitable for small machines.

author: brucehoult
author_rank: Super Contributor
timestamp: December 31, 2023, 09:05:45 am
content: Merely using a C++ compiler instead of C will not in itself cause any significant increase in memory use.After all, I program my ATTiny85 MCUs (512 *bytes* of RAM) using the Arduino environment and libraries, which are C++.

author: magic
author_rank: Super Contributor
timestamp: December 31, 2023, 09:08:40 am
content: I presume it's selection whether your code will be compiled by a C or C++ compiler. STM CubeIDE supposedly uses GCC compilers, where C and C++ are clearly separated.If you select C, you should be unable to use C++ unique features like classes or templates and C++ libraries such as <string> or STL. Try it yourself.If you select C++, you can still write C code in it because C++ is mostly compatible. But there are small differences here and there, so always remember to look up information specific to the language you use. Another gotcha is C++ name mangling - your compiled functions will have stuff appended to their names which indicates types of arguments and return values and code compiled by C won't be able to call them by their original name; this is solved by 'extern "C"' declarations if necessary.IMO there is no point compiling with C++ if you only use C. Compilation time may be longer because C++ is a more complex language and hypothetically you could get weird error messages if you manage to make a typo which accidentally looks like a C++ feature, although I'm not sure if I have ever seen it actually happen.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: December 31, 2023, 03:02:48 pm
content: There are a lot of C++ features that do not cause any increase of code size, while making code more portable and better readable at the same time. Using classes, constexpr instead of macro's, named enums with type checking and the C++ compiler generally also has much stricter type checks in general. When I switched from C to C++ for some of my AVR programs, the compiled size actually shrunk. And some global variables for which I never had a good place to declare them, found a nice new home inside a class. C++ is also an actively developing language.Other features of C++ can cause a lot of code bloat, from (mis/ab) use of templates to exception handling and those new standard libraries (string, vector, arrays and such) and those are generally a bad fit for a microcontroller.I am a bit "stuck" in the "Getting started with STM32" mode for a bunch of years, and most of the reasons are not computer / software related and "off topic". I am using C++ for STM32 too. In the Cube IDE V1.9.0 Build: 12015_20220302_0855 I used last the C++ project creation did not work. I had to manually rename the C file to CPP for the compiler to use the C++ version of GCC.I also find all the /* User thing here */ and /* User thing end. */ quite annoying. It adds lots of useless lines to your sourcecode, and it tends to damage your code if you touch it. My solution is to to put a single jump from main() to my_main() in another file, and just leave the auto generated pile of spaghetti alone.C code will generally compile with a C++ compiler without much issues, although there may be some subtle changes in how the compiled code works. Linking files together that are compiled with a C and a C++ compiler is apparently also possible, but I try very hard to steer away from that. I use GCC nearly exclusively, and with GCC you usually get both compilers installed at the same time, so why bother with a C compiler?------------------------------------------------------------------------During writing of this post I attempted to let cube IDE is update itself, but as anything in eclipse, it's as slow as frozen molasses.... Ten minutes laterCube IDE failed to update itself (to 1.14.0). I first had to accept some incomprehensible multi page EULA (Does anyone read those things? And after that it got itself stuck on "un-trusted" software. something with a java castle and pgp keys that it won't accept.

author: radiolistener
author_rank: Super Contributor
timestamp: December 31, 2023, 03:44:01 pm
content: С++ for microcontrollers is overhead. There is no so much resources on MCU, so there is a sense to use C only, it allows to produce more compact and faster code which is very important for MCU due to limited resources...C++ libraries is very heavy and sometimes may not fit into MCU memory even for hello world code

author: langwadt
author_rank: Super Contributor
timestamp: December 31, 2023, 03:50:58 pm
content: Quote from: radiolistener on December 31, 2023, 03:44:01 pmwhat ever you can do in c you can do it in c++ so that very much depends ...

author: magic
author_rank: Super Contributor
timestamp: December 31, 2023, 03:54:24 pm
content: Maybe there is some difference. This is one of my ATmega32U4 programs compiled with different compilers and optimizations, all other flags the same.Code:size filename6236 avr-g++02.o3804 avr-g++0s.o6184 avr-gcc02.o3772 avr-gcc0s.oA different program which only sets a few peripheral registers and jumps into assembly...Code:1624 avr-g++02.o1620 avr-g++0s.o1620 avr-gcc02.o1616 avr-gcc0s.oThe pattern is unbroken...And a Linux program built on ARM.Code:17360 g++O217336 gccO2Of course the difference between 1620 and 1624 is only 4 bytes, but the difference between 2048 and 2052 can be 2048 bytes

author: radiolistener
author_rank: Super Contributor
timestamp: December 31, 2023, 03:59:30 pm
content: Quote from: langwadt on December 31, 2023, 03:50:58 pmYes, you can use C code with C++ compiler, but not vice versa and that is the issue.You can't compile C++ code on C compiler to get smaller and faster code...This is why C is better for MCU.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: December 31, 2023, 04:14:11 pm
content: OP opened his thread with:Quote from: Veketti on December 31, 2023, 08:31:46 amAnd there are plenty of reasons for wanting to use C++ on a uC. Code size difference is often negligible, uC's with MB of flash are common too, so please keep those C versus C++ fights somewhere else if you have nothing specific to CubeIDE to add.

author: brucehoult
author_rank: Super Contributor
timestamp: December 31, 2023, 07:58:43 pm
content: Quote from: radiolistener on December 31, 2023, 03:44:01 pmRubbish. C code compiled with a C++ compiler doesn't get any bigger or slower, and many C++ features also don't increase size or decrease speed. Some do, so you simply have to understand what you are doing.QuoteWhich C++ libraries? The C++ libraries supplied in the Arduino environment, for example, are very well suited to use on MCUs.Many C libraries are heavy and bloated, for example printf(). A C++ solution using overloaded "print" or "<<" functions can be much lighter weight because it pulls in only the formatting code for the data types you actually print.

author: tooki
author_rank: Super Contributor
timestamp: December 31, 2023, 09:03:00 pm
content: Quote from: radiolistener on December 31, 2023, 03:59:30 pmYour unfounded confidence is a continued source of amusement…

author: JustMeHere
author_rank: Frequent Contributor
timestamp: December 31, 2023, 09:19:09 pm
content: C if your program is small and you can fit it into a few files.C++ when it gets bigger. The encapsulation of OO will make things less buggy and you won't need to worry about variable name collision so much.

author: magic
author_rank: Super Contributor
timestamp: December 31, 2023, 09:32:44 pm
content: Quote from: brucehoult on December 31, 2023, 07:58:43 pmYes, printf is heavy, but you pay the price only once per firmware image and some MCU implementations offer simplified printf without the rarely used float conversions, for example, so you don't pay a lot extra.On the other hand, C format strings usually take less storage than sequences of call instructions and register shuffling generated by C++. (It is a general rule than whenever C++ talks about "performance", you should mentally substitute "bloat" and stop to think if the tradeoff works for your application. At least when migrating from C, maybe it's different for Python users...)I learned it the hard when trying to reduce AVR binary size by replacing printf with sequences of print_some_type() functions. My code printed enough that the function which printed grew larger than printf implementation.

author: DavidAlfa
author_rank: Super Contributor
timestamp: December 31, 2023, 10:24:15 pm
content: I definitely remember some heap used after calling (s)printf, check it out:Code:#include <malloc.h>struct mallinfo mi;uint32_t used;used = mi.uordblks;printf ("Hello!");used = mi.uordblks;You'll see how "used" increased after the initial call.Can't remember which internal function used the heap.

author: radiolistener
author_rank: Super Contributor
timestamp: January 01, 2024, 12:16:37 am
content: Quote from: brucehoult on December 31, 2023, 07:58:43 pmAs I remember, when I tested it, C code with standard libraries include printf well fits into STM32 memory and have free space. But C++ code cannot fit into memory due to large libraries. You can play with tweaks and lightweight versions o libraries with limited functionality and it can fit, but this is headache and it still eats a lot of memory and produce code which is noticeable slower than code compiled with C compiler.

author: brucehoult
author_rank: Super Contributor
timestamp: January 01, 2024, 12:20:16 am
content: Quote from: radiolistener on January 01, 2024, 12:16:37 amYou are still failing to distinguish between the programming language and the libraries you choose to use. It's a very important distinction.

author: radiolistener
author_rank: Super Contributor
timestamp: January 02, 2024, 06:15:13 pm
content: Quote from: brucehoult on January 01, 2024, 12:20:16 amNo, I well understand the difference between libraries and language. But when you choose C++ language, you're stuck with C++ libraries which is always larger than C libraries. Even if you're don't use C++ features at all, some C++ libraries are still linked when you compile it with C++ compiler.And using C++ language expects using OOP, which add some code overhead and slows down the code.The difference is not significant for x86 platform, but when you're dealing with MCU, which code memory is just 64-128 kB and RAM is just 2-16 kB, it going to be important thing.

author: langwadt
author_rank: Super Contributor
timestamp: January 02, 2024, 07:48:01 pm
content: Quote from: radiolistener on January 02, 2024, 06:15:13 pmpossibly, maybe, sometimes, depending

author: brucehoult
author_rank: Super Contributor
timestamp: January 02, 2024, 10:22:10 pm
content: Quote from: radiolistener on January 02, 2024, 06:15:13 pmFalse. You can use C++ with C libraries, no problems. Or with no libraries at all.QuoteFalse. Any difference is just a few bytes.Code:#include <stdio.h>int main(){printf("Hello RISC-V!\n");return 0;}Compiled with C on my RISC-V VisionFive 2 board...Code:user@starfive:~$ gcc -O hello.c -o hellouser@starfive:~$ size hellotextdatabssdechexfilename1116584817086achello.. and with C++ ...Code:user@starfive:~$ g++ -O hello.c -o hellouser@starfive:~$ size hellotextdatabssdechexfilename1152584817446d0helloThe difference is 36 bytes. That's insignificant on any platform and certainly not any extra library linked in.QuoteThere is absolutely no requirement to use OOP just because you're using C++. If it's functionality you need then it won't be any smaller coding it in C.QuoteNot true, even on a much smaller MCU than that. I can, and do, use C++ on MCUs with 8 KB flash and 512 bytes RAM.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: January 03, 2024, 12:53:17 am
content: QuoteIndeed. I have written a bunch of programs for the ATmega 8 (with 8kB of Flash) in C++ without issues. C++ code does not have to be any bigger then C code. That is a long standing misconception. But you do have to be a bit careful. It is easy to pull in big libraries, but that is true for both C and C++.The biggest difference is that some memory hogs can be easy to overlook. Things like RTTI, exceptions, abuse of templates can make code bigger really quick. For some uC's these are not available at all, and for other they may be enabled by default and you have to disable it.

author: boB
author_rank: Frequent Contributor
timestamp: January 03, 2024, 01:24:35 am
content: But, are there any speed differences ?I doubt it but...