Does it make any sense to switch 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
QuoteDoes it make any sense to switch from c to c++?Yes.Quotebut 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++")
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.
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.
If you do a project in c++ you will not want to do C anymore
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.QuoteThe 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.
specifically the ones that could not be done in C
Twenty years ago I wrote ...That was the last time I wrote anything in C++.
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.QuoteThe 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.
Does it make any sense to switch from c to c++?
1) C++. I'm sorry, but the best feature of C++ is its // comment operator so you don't have to terminate comments with */.
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++.
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++.
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 */.
I would not list that as a feature why C++ should be used instead of C.
...the best feature of C++ is its // comment operator...
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}
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
Quotespecifically the ones that could not be done in CThere 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 was also shown (by a CMU professor at a conference) that C++ can overlay objects on memory mapped peripherals. It was the ugliest boiler plate I have ever seen for initializing a UART. He claimed you will never make a mistake using of using signed int pointer for a peripheral registers. Seemed like a lot of work for software purity.
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.
// In a compiler specific header
// #define __weak gnu::weak
[[__weak]] extern void (*__preinit_array_start []) (void);
[[__weak]] extern void (*__preinit_array_end []) (void);
[[__weak]] extern void (*__init_array_start []) (void);
[[__weak]] extern void (*__init_array_end []) (void);
void init_array() {
size_t count, i;
count = __preinit_array_end - __preinit_array_start;
for (i = 0; i < count; i++)
__preinit_array_start[i]();
count = __init_array_end - __init_array_start;
for (i = 0; i < count; i++)
__init_array_start[i]();
}
#include <cstdint>
extern "C" {
extern uint32_t __etext;
extern uint32_t __data_start__;
extern uint32_t __data_end__;
extern uint32_t __bss_start__;
extern uint32_t __bss_end__;
extern int main();
extern void SystemInit();
extern void __libc_init_array();
void Reset_Handler() {
SystemInit();
uint32_t *src = &__etext;
uint32_t *dst = &__data_start__;
uint32_t *lim = &__data_end__;
while (dst < lim) { *dst++ = *src++; }
dst = &__bss_start__;
lim = &__bss_end__;
while (dst < lim) { *dst++ = 0; }
__libc_init_array();
main();
}
} // extern "C"
Does it make any sense to switch from c to c++?
it's just the language that give you more possibilities, so more possibilities to do crap.
it's just the language that give you more possibilities, so more possibilities to do crap.
I am writing, just right now, polymorphism in C
##It
#can
##be
done
(funny, or odd?, that is the problem)
What subset of C++ will be useful for microcontrollers?
Comming back to the problem I am facing: I add the .ctor and .dtor in the linker file, but in map file the sections are empty. I am missing something here.
Here is the options compiller called
.....
Building file: ../Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_i2c.c
Invoking: MCU GCC Compiler
C:\myfiles\radio103\firmware\radio\Debug
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -std=c11 '-D__weak=__attribute__((weak))' '-D__packed=__attribute__((__packed__))' -DUSE_HAL_DRIVER -DSTM32F103xE -I"C:/myfiles/radio103/firmware/radio/Inc" -I"C:/myfiles/radio103/firmware/radio/Drivers/STM32F1xx_HAL_Driver/Inc" -I"C:/myfiles/radio103/firmware/radio/Drivers/STM32F1xx_HAL_Driver/Inc" -I"C:/myfiles/radio103/firmware/radio/Drivers/STM32F1xx_HAL_Driver/Inc/Legacy" -I"C:/myfiles/radio103/firmware/radio/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM3" -I"C:/myfiles/radio103/firmware/radio/Middlewares/ST/STM32_USB_Device_Library/Core/Inc" -I"C:/myfiles/radio103/firmware/radio/Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc" -I"C:/myfiles/radio103/firmware/radio/Drivers/CMSIS/Device/ST/STM32F1xx/Include" -I"C:/myfiles/radio103/firmware/radio/Middlewares/Third_Party/FreeRTOS/Source/include" -I"C:/myfiles/radio103/firmware/radio/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS" -I"C:/myfiles/radio103/firmware/radio/Drivers/CMSIS/Include" -I"C:/myfiles/radio103/firmware/radio/Middlewares/Third_Party/FatFs/src" -I"C:/myfiles/radio103/firmware/radio/Drivers/lcd" -Og -g3 -Wall -fmessage-length=0 -fno-verbose-asm -ffunction-sections -c -fmessage-length=0 -MMD -MP -MF"Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_i2c.d" -MT"Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_i2c.o" -o "Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_i2c.o" "../Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_i2c.c"
Finished building: ../Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_i2c.c
.....
arm-none-eabi-g++ -std=c++1y '-D__weak=__attribute__((weak))' -DSTM32F103xE -DUSE_HAL_DRIVER '-D__packed=__attribute__((__packed__))' -I"C:/myfiles/radio103/firmware/radio/Middlewares/ST/STM32_USB_Device_Library/Core/Inc" -I"C:/myfiles/radio103/firmware/radio/Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc" -I"C:/myfiles/radio103/firmware/radio/Drivers/CMSIS/Device/ST/STM32F1xx/Include" -I"C:/myfiles/radio103/firmware/radio/Middlewares/Third_Party/FreeRTOS/Source/include" -I"C:/myfiles/radio103/firmware/radio/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS" -I"C:/myfiles/radio103/firmware/radio/Drivers/CMSIS/Include" -I"C:/myfiles/radio103/firmware/radio/Middlewares/Third_Party/FatFs/src" -I"C:/myfiles/radio103/firmware/radio/Drivers/lcd" -I"C:/myfiles/radio103/firmware/radio/Inc" -I"C:/myfiles/radio103/firmware/radio/Drivers/STM32F1xx_HAL_Driver/Inc" -I"C:/myfiles/radio103/firmware/radio/Drivers/STM32F1xx_HAL_Driver/Inc" -I"C:/myfiles/radio103/firmware/radio/Drivers/STM32F1xx_HAL_Driver/Inc/Legacy" -I"C:/myfiles/radio103/firmware/radio/Drivers/CMSIS/Device/ST/STM32F1xx/Include" -Os -g3 -Wall -c -fmessage-length=0 -fno-verbose-asm -MMD -MP -MF"Src/Radio.d" -MT"Src/Radio.d" -o "Src/Radio.o" "../Src/Radio.cpp"
Finished building: ../Src/Radio.cpp
Invoking: MCU G++ Linker
arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -specs=nosys.specs -specs=nano.specs -T"../STM32F103RETx_FLASH.ld" -Wl,-Map=output.map -Wl,--gc-sections -fno-exceptions -fno-rtti -o "radio.elf" @"objects.list" -lm
The build is finished with success.
I use gcc in System Workbench STM32 / WinIdea Open/J-link/Custom board with stm32f103.
A well written C++ code can be more efficient than C or assembler one
A well written C++ code can be more efficient than C or assembler oneYou 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.
Is there a way to evaluate an micro based project needs OOP?
A well written C++ code can be more efficient than C or assembler oneYou 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.
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.
C++ tries to be too many things to too many people.
And with every new release of C++ the problem becomes worse.
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.
Ada... C++... DSP56000 assembly... TiniJava... OCam....
GCC's linker generates a function to do all the static initialization: __libc_init_array().
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...
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
2016-12-20--01-48-14---2016-12-20--06-22-46 - dev-lang/ocaml - success - user-990-12-412
There are cases where OOP can produce tremendous bloat.
There are cases where OOP can produce tremendous bloat.
Got an example?
Real world example? I was doing some Windows development a long time ago. Microsoft, using C++, had extremely bloated, but yet useless, MFC framework.
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!
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.
Microsoft produces some crappy tool (or tools), so I should stay away from C++?
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
Hence why I stick with C and don't care about C++. cv007 has also posted a nice example of unreadable code. Who can tell what it's doing? I can't. But I very likely would, if it would be written in anything else, but a C++.
I work now for almost 5 years in a place, where we review many and many customer application HW and application code. Very very rarely there is something written in a C++.
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?
try this one
Beauty is in the eyes of the beholder. It's the result that matters... 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?
It's fun watching comparisons of programming dick lengths, but what matters, is what the safety standards tell you to use and how to write fail safe code.
One thing is to sour sketchy sketches to arduino in C++, while writing code for a product, that will actually be sold and certified is a completely another.
In the hands of a good programmer C++ is definitely the better tool. It can be just as fast and efficient while structuring code much better. But when you hand C++ to a bad programmer it just makes these code even more of a horror show.
Assembler is obviously horrible here since it has basically no real structure to it. :
but then C++ and C# [let you] structure your code almost anyway you want.
"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.
std::array<uint8_t, 30> buffer;
buffer.fill(0x55);
That actually looks pretty nice. And I read up on "array" and it doesn't seem bad at all.But if someone were to come along and not pay attention, and use instead ("because it's shorter, and a vector and an array are the same, right?"):std::vector<uint8_t> buffer(30, 55);
It might suddenly be very painful, on an embedded system.Code structured "any way you want" is almost as bad as code with no real structure at all, what with 50% of programmers having below-median skill.
At least with assembler, the chances are pretty slim that a program will be stealthily bloated and slow.
But if someone were to come along and not pay attention
I believe that meant "structured way the project needs".
Good luck with supporting a big assembler project. It's fast in runtime, but very slow in development (and, I guess, expensive).
Our AFDX switches were initially developed in C++, but avionics certifications and related stuff have recently pushed guys back to C so our new products are developed with C.
The C++ experience failed for us
For example, this was recently posted:Code: [Select]std::array<uint8_t, 30> buffer;
That actually looks pretty nice. And I read up on "array" and it doesn't seem bad at all.But if someone were to come along and not pay attention, and use instead ("because it's shorter, and a vector and an array are the same, right?"):
buffer.fill(0x55);Code: [Select]std::vector<uint8_t> buffer(30, 55);
It might suddenly be very painful, on an embedded system.
weird for somebody who didn't know about std::array, to compare it with the more advanced std::vector
void
fill(const value_type& __u)
{ std::fill_n(begin(), size(), __u); }
// Element access.
_GLIBCXX17_CONSTEXPR reference
operator[](size_type __n) noexcept
{ return _AT_Type::_S_ref(_M_elems, __n); }
constexpr const_reference
operator[](size_type __n) const noexcept
{ return _AT_Type::_S_ref(_M_elems, __n); }
Afaik space-x uses cpp.
is_approved=False;
while(is_approved isNotEqualTo True)
{
is_ok=False;
while(is_ok isNotEqualTo True)
{
development(project);
is_ok=testing(project);
}
is_approved=QA(project);
}
commit(project);
reading the source: if they don't find it comfortable and understandable the project is not approved.
you also have to prove by specific test-cases that your compiler does not generate untraceable code in your specific context. C++ generates a lot of untraceable code
Boy, that's got to be fun with dynamic polymorphism.
I was relatively impressed to find something relatively simple like "array." Although perhaps it's a good thing I didn't look at its source code before saying good things about it :-)
const UUID my_bluetooth_service = "268cf9ec-1269-41fb-b6ca-1fd6552468d3";
const uint8_t my_bluetooth_service[16] = {
0xd3, 0x68, 0x24, 0x55,
0xd6, 0x1f, 0xca, 0xb6,
0xfb, 0x41, 0x69, 0x12,
0xec, 0xf9, 0x8c, 0x26,
};
That's cool!
That's cool!You have to move your ass to the laboratory, take a goddamn ICE, connect it to the target, load the hex, fill breakpoints here and there, and everything and logging in a file what the compiler has done.
Turns out it's actually possible to do compile-time parsing of string literals and have a class definition convert the human readable syntax into the same 16 bytes at compile time. That's cool!
arm-none-eabi-objdump -d Blink.elf | sed '/morse_table>:/,/^$/!d'
00000d0c <_ZL11morse_table>:
d0c: 04080201 0304040a 04020100 04000306 ................
d1c: 04070200 04040305 02020203 04060307 ................
d2c: 0302040d 01010300 04010301 04090303 ................
d3c: 040c040b 050f051f 05030507 05000501 ................
d4c: 05180510 051e051c 00000000 ............
Huh what? Don't have access to tools that can disassemble ELF files and read symbols from there?
That's crap. Now, try to imagine that you have to verify this shit with a formal tool (you are not authorized to hack it, neither you have the source) that doesn't understand it. You know how it ends?
You have to move your ass to the laboratory, take a goddamn ICE, connect it to the target, load the hex, fill breakpoints here and there, and everything and logging in a file what the compiler has done.
C++ in DO-178B-compliant applications, see CAST paper number #8
[..]
Many C++ features, if not properly controlled and verified, can result in software code that is non-deterministic, unused, or difficult to verify, and whose configuration can change depending on the runtime state of the system
[..]
uint32_t subrelease;
uint32_t minrelease;
minrelease = 0;
subrelease = 0;
is_approved=False;
while(is_approved isNotEqualTo True)
{
is_ok=False;
while(is_ok isNotEqualTo True)
{
development(project);
/*
* draf version
* tools are employed
* to assist in satisfying
* DO-178B objectives
*/
is_ok=testing(project);
subrelease++;
}
is_approved=QA(project);
minrelease++;
}
commit(project);
What I want to make it absolutely clear is that *hipster* features such as inheritance, overloading, and polymorphism will complicate traceability and structural coverage, and potentially lead to code that contains latent defects of unexplored behavior!
Note that a premium value for this is that Ada comes with better standard guidance and tools rules so it's usually approved by QA at the third attempt. This also thanks to Stood, a tool that is used to model the Ada core, so it's more consistent with the initial design. This makes good points for preferring it, even if ... the designing, planning, development, and testing usually takes a longer time than C, but not the time required by C++.
the following piece of pseudo-C-code
is_approved
False
isNotEqualTo
True
is_ok
Project myproject;
while( not myproject.committed() ){ myproject.start_over() }
Quotehuh. I also see that std::array apparently wasn't added until C++11. ("Really? Are they kidding?!")weird for somebody who didn't know about std::array, to compare it with the more advanced std::vectoryes, well... I'm very much an ASM or C programmer trying to learn new things.
Then you have unit tests for single-stepping through code, static_assert to prevent cross-compilation regressions, and inline assertions for run-time debugging (in unit-tests and potentially on the device) plus providing hints for static checkers (although most formal checking tools need loads more info to work by any stretch of the imagination - and you'd be damned if you use any kind of loop).
I am still wandering if I should start my home project stm32 based, in C++
I am still wandering if I should start my home project stm32 based, in C++.