How many people code in C these days, and if so, why?

[kamtar]

I use C++ for all my embedded projects (which are ARM only)

You just need to understand it well and know which abstraction costs what, then there is really no disadvantage in comparison to C.
Because I'm dealing with tons of code that is shared through dozens of different MCUs and boards C++ became an irreplaceable tool for me.

I don't really see the reasoning behind arguments mentioning stl, then don't use it and just stick with C libraries.
Switching to C++ isn't about writing everything in a modern C++ but about not being afraid and using features from it you feel might be useful for you.

[rgarito]

My very well-known employer's bread-and-butter networking gear code is all written in C with a little Assembler sprinkled in.  (I'm one of the engineers)  It's equipment that you are literally using every day if you are on the internet, being about 80% of the largest companies in the world are our customers...  A small portion of our GUI code (backend to a web page GUI) is C++.  The entire system is FreeBSD-based (with a heavily-modified kernel) which explains the C.  Being such a large system, there is also a small amount of various scripting languages (bash, python, awk, perl, etc). 

I also do side work on embedded CPU's primarily as part of an LCD controller project.  STM32 CPUs (mostly H757 nowadays, but also F429 and a few others).  All C-coded.  Primarily because that's what ST based the HAL on. 

[rsjsouza]

Somewhat Arduino-like in that people don't write "C++ programs" - they go out and hunt down libraries and examples that are close to what they want, and work from there.  "Oh, you want Boost, and the Boost extension for lambda expressions, and the XYZZY ray-tracing library, and the ZZZ front end for importing data, and ..."

Interesting; that is how I see Python: get code from somewhere... Pip away until you get all the libraries you need.

There's a cult following who won't like your C++ programs unless they've become completely unintelligible to people expecting to see actual code.  "That's not C++, that's Just C With Classes - you're not even using the STL!

I agree, but to be fair I see that with C as well, especially with embedded. Modern compilers do a much better job reducing a somewhat lenghty (but legible) code but developers fall to the temptation to write cryptic constructs with the same effect. Perhaps to showcase how smart they are? Or job security?

I keep seeing presentation "advantages of C++ in an embedded environment", where they keep listing features that have also been in almost all C compilers as well ("inline"?  TGtbKM!)

(...)

C++ proponents tend to be blind to needs of embedded and speed freaks - "named address spaces" were apparently explicitly rejected, for example.  There's a lot of "C++ doesn't have to bad code for embedded; just avoid certain features", but not a lot of alternatives (STL almost immediately gets you dynamic allocation...)

I've seen lots of these presentations as well, and it feels as trying to push hard a soluion to a problem that already has a reasonable enough solution. C++ loses its major strengths of abstraction and code reuse when it is stripped from the most memory hungry and processor intensive functions.

For me, I couldn't yet find a killer scenario for embedded that would only be possible to implement in C++ (or it would bring an unmatched advantage) apart from a GUI development.

[coppice]

There's a cult following who won't like your C++ programs unless they've become completely unintelligible to people expecting to see actual code.  "That's not C++, that's Just C With Classes - you're not even using the STL!

I agree, but to be fair I see that with C as well, especially with embedded. Modern compilers do a much better job reducing a somewhat lenghty (but legible) code but developers fall to the temptation to write cryptic constructs with the same effect. Perhaps to showcase how smart they are? Or job security?

Don't you realise that every parenthesis is sacred, and only to be used when all alternatives have been exhausted? 

[Wolfgang]

I am not really religious about languages but a key criterion is memory management.
On an ARM, large platform, whatever, C++ is fine. OK, you also should use STL, it will
do a lot of dynamic memory juggling, but so what as long as you have enough space and time.

On small controllers like Arduino, IMHO, C++ is off target. With the very little RAM available,
you have to always know how much space you have, when its allocated and when its freed.
Better forget about any dynamic memory, avoid String classes, and whatever uses it. Little
stack space is OK, keep constants in code space, use global vars when needed, ...
all the dirty tricks. But, most important, there is no "out of memory" message in an Arduino.
When stack and heap (or even static memory) collide thats just a crash in the best case,
in the worst its unrepeatable errors. And you cannot debug that. IIRC there is not even an STL
on an Arduino (would probably need all RAM just for itself).

[rsjsouza]

There's a cult following who won't like your C++ programs unless they've become completely unintelligible to people expecting to see actual code.  "That's not C++, that's Just C With Classes - you're not even using the STL!

I agree, but to be fair I see that with C as well, especially with embedded. Modern compilers do a much better job reducing a somewhat lenghty (but legible) code but developers fall to the temptation to write cryptic constructs with the same effect. Perhaps to showcase how smart they are? Or job security?

Don't you realise that every parenthesis is sacred, and only to be used when all alternatives have been exhausted? 

And what makes me frustrated is to see that any IDE or editor worth its salt highlights the matching parenthesis, brackets, curly braces, etc., making these "savings" even less worth.

[nuclearcat]

On small controllers like Arduino, IMHO, C++ is off target. With the very little RAM available,
you have to always know how much space you have, when its allocated and when its freed.
Better forget about any dynamic memory, avoid String classes, and whatever uses it. Little
stack space is OK, keep constants in code space, use global vars when needed, ...
all the dirty tricks. But, most important, there is no "out of memory" message in an Arduino.
When stack and heap (or even static memory) collide thats just a crash in the best case,
in the worst its unrepeatable errors. And you cannot debug that. IIRC there is not even an STL
on an Arduino (would probably need all RAM just for itself).

If you use C++ in a way that uses C++ features minimally (for example just C++ classes), you can actually use equal amount memory with same efforts.
This article is in russian: https://habr.com/ru/post/347980/ , but google translate might do job.
At the end author come to almost same stack/flash numbers, but C++ code is much more concise and readable.
I think there is no need to say that the probability of an error in such code is much less.

But there is a simple reason to use C-only - MISRA and alike. C++ is just no-go in such applications.

[madires]

My very well-known employer's bread-and-butter networking gear code is all written in C with a little Assembler sprinkled in.  (I'm one of the engineers)  It's equipment that you are literally using every day if you are on the internet, being about 80% of the largest companies in the world are our customers...  A small portion of our GUI code (backend to a web page GUI) is C++.  The entire system is FreeBSD-based (with a heavily-modified kernel) which explains the C.  Being such a large system, there is also a small amount of various scripting languages (bash, python, awk, perl, etc). 

That's an area where you have to deliver fast and efficient software, otherwise you would lose customers, And from experience I know that the differences in performance between competitors can be huge. At the same time something contrary is happening at the OSS side. Lots of slow Python to manage the network elements. Professional bodge-ware.

[Wolfgang]

I you exclude all C++ goodies (inheritance, STL, constructors and destructors, ...) the question is why you should use it then on a small platform (e.g., Arduino) at all. Just to write classes and methods instead of structs and functions is then more like syntactic sugar.
The code there is size limited anyway, and it *is* possible to write decent code in whatever. Its more a "Torvalds" platform
where he always want so foresee what code the compiler will create of his sources in order to keep contol.

[SiliconWizard]

I you exclude all C++ goodies (inheritance, STL, constructors and destructors, ...) the question is why you should use it then on a small platform (e.g., Arduino) at all. Just to write classes and methods instead of structs and functions is then more like syntactic sugar.

I agree with this.
Some people seem to like the syntactic sugar though.

I usually use a naming convention with a prefix, so it's really a matter of sugar indeed.

For instance:

Code: [Select]

void GPIO_Set(void)
{...}

GPIO A;

GPIO_Set(A);
(or: GPIO_Set(&A), depending on how GPIO is defined exactly.)

in C++ you'd have something like:

Code: [Select]

GPIO::Set()
{...}

GPIO A;

A.Set();

Cute, but that's sugar. Not even *that* much more compact. Thing is, C++ will tend to make you structure your code "better", whereas in C, you'll need more discipline for a similar result. To some it's not a problem at all, but I must admit I have witnessed a LOT of developers truly lacking discipline.

One aspect of C++ some developers seem to like in embedded settings are templates. Whereas they are arguably "better" and a lot more featureful than macros, they can also be a nice opportunity for shooting yourself in the foot, so I'm not sure I'm completely sold. Never had that much trouble using macros, as long as they follow some rules, are clear and don't have unwanted side-effects.

As some of us have already said, the crux of the matter is to define a subset of C++, with every developer using a slightly different one, and no real standard or hard guideline for choosing one.

[Picuino]

For me, the discipline of programmer matters, and is more important than language itself.

In C you can do things like this flight simulator:

Code: (c) [Select]

#include                                     <math.h>
#include                                   <sys/time.h>
#include                                   <X11/Xlib.h>
#include                                  <X11/keysym.h>
                                          double L ,o ,P
                                         ,_=dt,T,Z,D=1,d,
                                         s[999],E,h= 8,I,
                                         J,K,w[999],M,m,O
                                        ,n[999],j=33e-3,i=
                                        1E3,r,t, u,v ,W,S=
                                        74.5,l=221,X=7.26,
                                        a,B,A=32.2,c, F,H;
                                        int N,q, C, y,p,U;
                                       Window z; char f[52]
                                    ; GC k; main(){ Display*e=
 XOpenDisplay( 0); z=RootWindow(e,0); for (XSetForeground(e,k=XCreateGC (e,z,0,0),BlackPixel(e,0))
; scanf("%lf%lf%lf",y +n,w+y, y+s)+1; y ++); XSelectInput(e,z= XCreateSimpleWindow(e,z,0,0,400,400,
0,0,WhitePixel(e,0) ),KeyPressMask); for(XMapWindow(e,z); ; T=sin(O)){ struct timeval G={ 0,dt*1e6}
; K= cos(j); N=1e4; M+= H*_; Z=D*K; F+=_*P; r=E*K; W=cos( O); m=K*W; H=K*T; O+=D*_*F/ K+d/K*E*_; B=
sin(j); a=B*T*D-E*W; XClearWindow(e,z); t=T*E+ D*B*W; j+=d*_*D-_*F*E; P=W*E*B-T*D; for (o+=(I=D*W+E
*T*B,E*d/K *B+v+B/K*F*D)*_; p<y; ){ T=p[s]+i; E=c-p[w]; D=n[p]-L; K=D*m-B*T-H*E; if(p [n]+w[ p]+p[s
]== 0|K <fabs(W=T*r-I*E +D*P) |fabs(D=t *D+Z *T-a *E)> K)N=1e4; else{ q=W/K *4E2+2e2; C= 2E2+4e2/ K
 *D; N-1E4&& XDrawLine(e ,z,k,N ,U,q,C); N=q; U=C; } ++p; } L+=_* (X*t +P*M+m*l); T=X*X+ l*l+M *M;
  XDrawString(e,z,k ,20,380,f,17); D=v/l*15; i+=(B *l-M*r -X*Z)*_; for(; XPending(e); u *=CS!=N){
                                   XEvent z; XNextEvent(e ,&z);
                                       ++*((N=XLookupKeysym
                                         (&z.xkey,0))-IT?
                                         N-LT? UP-N?& E:&
                                         J:& u: &h); --*(
                                         DN -N? N-DT ?N==
                                         RT?&u: & W:&h:&J
                                          ); } m=15*F/l;
                                          c+=(I=M/ l,l*H
                                          +I*M+a*X)*_; H
                                          =A*r+v*X-F*l+(
                                          E=.1+X*4.9/l,t
                                          =T*m/32-I*T/24
                                           )/S; K=F*M+(
                                           h* 1e4/l-(T+
                                           E*5*T*E)/3e2
                                           )/S-X*d-B*A;
                                           a=2.63 /l*d;
                                           X+=( d*l-T/S
                                            *(.19*E +a
                                            *.64+J/1e3
                                            )-M* v +A*
                                            Z)*_; l +=
                                            K *_; W=d;
                                            sprintf(f,
                                            "%5d  %3d"
                                            "%7d",p =l
                                           /1.7,(C=9E3+
                              O*57.3)%0550,(int)i); d+=T*(.45-14/l*
                             X-a*130-J* .14)*_/125e2+F*_*v; P=(T*(47
                             *I-m* 52+E*94 *D-t*.38+u*.21*E) /1e2+W*
                             179*v)/2312; select(p=0,0,0,0,&G); v-=(
                              W*F-T*(.63*m-I*.086+m*E*19-D*25-.11*u
                               )/107e2)*_; D=cos(o); E=sin(o); } }https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest#Flight_simulator

Very beautiful and compact but unintelligible. An example of flexibility of C language and its ability to adapt to all kinds of rules, even ones that should never be followed.

[SiliconWizard]

For me, the discipline of programmer matters, and is more important than language itself.

In C you can do things like this flight simulator:

Code: (c) [Select]

#include                                     <math.h>
#include                                   <sys/time.h>
#include                                   <X11/Xlib.h>
#include                                  <X11/keysym.h>
                                          double L ,o ,P
                                         ,_=dt,T,Z,D=1,d,
                                         s[999],E,h= 8,I,
                                         J,K,w[999],M,m,O
                                        ,n[999],j=33e-3,i=
                                        1E3,r,t, u,v ,W,S=
                                        74.5,l=221,X=7.26,
                                        a,B,A=32.2,c, F,H;
                                        int N,q, C, y,p,U;
                                       Window z; char f[52]
                                    ; GC k; main(){ Display*e=
 XOpenDisplay( 0); z=RootWindow(e,0); for (XSetForeground(e,k=XCreateGC (e,z,0,0),BlackPixel(e,0))
; scanf("%lf%lf%lf",y +n,w+y, y+s)+1; y ++); XSelectInput(e,z= XCreateSimpleWindow(e,z,0,0,400,400,
0,0,WhitePixel(e,0) ),KeyPressMask); for(XMapWindow(e,z); ; T=sin(O)){ struct timeval G={ 0,dt*1e6}
; K= cos(j); N=1e4; M+= H*_; Z=D*K; F+=_*P; r=E*K; W=cos( O); m=K*W; H=K*T; O+=D*_*F/ K+d/K*E*_; B=
sin(j); a=B*T*D-E*W; XClearWindow(e,z); t=T*E+ D*B*W; j+=d*_*D-_*F*E; P=W*E*B-T*D; for (o+=(I=D*W+E
*T*B,E*d/K *B+v+B/K*F*D)*_; p<y; ){ T=p[s]+i; E=c-p[w]; D=n[p]-L; K=D*m-B*T-H*E; if(p [n]+w[ p]+p[s
]== 0|K <fabs(W=T*r-I*E +D*P) |fabs(D=t *D+Z *T-a *E)> K)N=1e4; else{ q=W/K *4E2+2e2; C= 2E2+4e2/ K
 *D; N-1E4&& XDrawLine(e ,z,k,N ,U,q,C); N=q; U=C; } ++p; } L+=_* (X*t +P*M+m*l); T=X*X+ l*l+M *M;
  XDrawString(e,z,k ,20,380,f,17); D=v/l*15; i+=(B *l-M*r -X*Z)*_; for(; XPending(e); u *=CS!=N){
                                   XEvent z; XNextEvent(e ,&z);
                                       ++*((N=XLookupKeysym
                                         (&z.xkey,0))-IT?
                                         N-LT? UP-N?& E:&
                                         J:& u: &h); --*(
                                         DN -N? N-DT ?N==
                                         RT?&u: & W:&h:&J
                                          ); } m=15*F/l;
                                          c+=(I=M/ l,l*H
                                          +I*M+a*X)*_; H
                                          =A*r+v*X-F*l+(
                                          E=.1+X*4.9/l,t
                                          =T*m/32-I*T/24
                                           )/S; K=F*M+(
                                           h* 1e4/l-(T+
                                           E*5*T*E)/3e2
                                           )/S-X*d-B*A;
                                           a=2.63 /l*d;
                                           X+=( d*l-T/S
                                            *(.19*E +a
                                            *.64+J/1e3
                                            )-M* v +A*
                                            Z)*_; l +=
                                            K *_; W=d;
                                            sprintf(f,
                                            "%5d  %3d"
                                            "%7d",p =l
                                           /1.7,(C=9E3+
                              O*57.3)%0550,(int)i); d+=T*(.45-14/l*
                             X-a*130-J* .14)*_/125e2+F*_*v; P=(T*(47
                             *I-m* 52+E*94 *D-t*.38+u*.21*E) /1e2+W*
                             179*v)/2312; select(p=0,0,0,0,&G); v-=(
                              W*F-T*(.63*m-I*.086+m*E*19-D*25-.11*u
                               )/107e2)*_; D=cos(o); E=sin(o); } }[url]https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest#Flight_simulator[/url]

Very beautiful and compact but unintelligible. An example of flexibility of C language and its ability to adapt to all kinds of rules, even ones that should never be followed.

Beautiful if you like ASCII art, but otherwise, meh.
The above is typical of IOCCC, but not per se typical of C. You could write something similar in C++, and in a handful of other languages, as (from what I've quickly read) it's mostly an exercise in formatting code, using non-helpful identifiers and "optimized" expressions. Some IOCCC code sources make heavy use of weird macros, which is even more unreadable, but even that is mostly doable in any language supporting macros. Even with clever templates I guess you could write pretty weird-looking stuff.

Any language not enforcing any specific formatting of code or naming conventions could pretty much lead to this kind of code.

You could say that Python (even if I for one don't like the concept of meaningful whitespaces) makes weird formatting of code almost impossible. So, it's probably harder to obfuscate Python code, at least this way.

[Wolfgang]

For me, the discipline of programmer matters, and is more important than language itself.

In C you can do things like this flight simulator:

Code: (c) [Select]

#include                                     <math.h>
#include                                   <sys/time.h>
#include                                   <X11/Xlib.h>
#include                                  <X11/keysym.h>
                                          double L ,o ,P
                                         ,_=dt,T,Z,D=1,d,
                                         s[999],E,h= 8,I,
                                         J,K,w[999],M,m,O
                                        ,n[999],j=33e-3,i=
                                        1E3,r,t, u,v ,W,S=
                                        74.5,l=221,X=7.26,
                                        a,B,A=32.2,c, F,H;
                                        int N,q, C, y,p,U;
                                       Window z; char f[52]
                                    ; GC k; main(){ Display*e=
 XOpenDisplay( 0); z=RootWindow(e,0); for (XSetForeground(e,k=XCreateGC (e,z,0,0),BlackPixel(e,0))
; scanf("%lf%lf%lf",y +n,w+y, y+s)+1; y ++); XSelectInput(e,z= XCreateSimpleWindow(e,z,0,0,400,400,
0,0,WhitePixel(e,0) ),KeyPressMask); for(XMapWindow(e,z); ; T=sin(O)){ struct timeval G={ 0,dt*1e6}
; K= cos(j); N=1e4; M+= H*_; Z=D*K; F+=_*P; r=E*K; W=cos( O); m=K*W; H=K*T; O+=D*_*F/ K+d/K*E*_; B=
sin(j); a=B*T*D-E*W; XClearWindow(e,z); t=T*E+ D*B*W; j+=d*_*D-_*F*E; P=W*E*B-T*D; for (o+=(I=D*W+E
*T*B,E*d/K *B+v+B/K*F*D)*_; p<y; ){ T=p[s]+i; E=c-p[w]; D=n[p]-L; K=D*m-B*T-H*E; if(p [n]+w[ p]+p[s
]== 0|K <fabs(W=T*r-I*E +D*P) |fabs(D=t *D+Z *T-a *E)> K)N=1e4; else{ q=W/K *4E2+2e2; C= 2E2+4e2/ K
 *D; N-1E4&& XDrawLine(e ,z,k,N ,U,q,C); N=q; U=C; } ++p; } L+=_* (X*t +P*M+m*l); T=X*X+ l*l+M *M;
  XDrawString(e,z,k ,20,380,f,17); D=v/l*15; i+=(B *l-M*r -X*Z)*_; for(; XPending(e); u *=CS!=N){
                                   XEvent z; XNextEvent(e ,&z);
                                       ++*((N=XLookupKeysym
                                         (&z.xkey,0))-IT?
                                         N-LT? UP-N?& E:&
                                         J:& u: &h); --*(
                                         DN -N? N-DT ?N==
                                         RT?&u: & W:&h:&J
                                          ); } m=15*F/l;
                                          c+=(I=M/ l,l*H
                                          +I*M+a*X)*_; H
                                          =A*r+v*X-F*l+(
                                          E=.1+X*4.9/l,t
                                          =T*m/32-I*T/24
                                           )/S; K=F*M+(
                                           h* 1e4/l-(T+
                                           E*5*T*E)/3e2
                                           )/S-X*d-B*A;
                                           a=2.63 /l*d;
                                           X+=( d*l-T/S
                                            *(.19*E +a
                                            *.64+J/1e3
                                            )-M* v +A*
                                            Z)*_; l +=
                                            K *_; W=d;
                                            sprintf(f,
                                            "%5d  %3d"
                                            "%7d",p =l
                                           /1.7,(C=9E3+
                              O*57.3)%0550,(int)i); d+=T*(.45-14/l*
                             X-a*130-J* .14)*_/125e2+F*_*v; P=(T*(47
                             *I-m* 52+E*94 *D-t*.38+u*.21*E) /1e2+W*
                             179*v)/2312; select(p=0,0,0,0,&G); v-=(
                              W*F-T*(.63*m-I*.086+m*E*19-D*25-.11*u
                               )/107e2)*_; D=cos(o); E=sin(o); } }
[url]https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest#Flight_simulator[/url]

Very beautiful and compact but unintelligible. An example of flexibility of C language and its ability to adapt to all kinds of rules, even ones that should never be followed.

Beautiful if you like ASCII art, but otherwise, meh.
The above is typical of IOCCC, but not per se typical of C. You could write something similar in C++, and in a handful of other languages, as (from what I've quickly read) it's mostly an exercise in formatting code, using non-helpful identifiers and "optimized" expressions. Some IOCCC code sources make heavy use of weird macros, which is even more unreadable, but even that is mostly doable in any language supporting macros. Even with clever templates I guess you could write pretty weird-looking stuff.

Any language not enforcing any specific formatting of code or naming conventions could pretty much lead to this kind of code.

You could say that Python (even if I for one don't like the concept of meaningful whitespaces) makes weird formatting of code almost impossible. So, it's probably harder to obfuscate Python code, at least this way.

I call this style of programming a Koan ( japanese lyrics). Nice to watch but ultimately futile and an elegant waste of time.
BTW, the unsurpassed master language of all Koans is good old IBM APL.

[Picuino]

You can also obfuscate Python if you want:

https://wiki.c2.com/?ObfuscatedPython

Code: [Select]

  print ''.join('%(pre)s%(num)s %(bot)s on the wall, %(nul)s %(bot)s,\n%(tak)s\n' % (lambda c,b:
  {'pre':['','%s %s on the wall.\n\n' % (c,b)][abs(cmp(c,'Ninety-nine'))],
 'num':c, 'nul':c.lower(), 'bot':b,
 'tak':['Go to the store and buy some more... Ninety-nine %s.' % b,'Take one down, pass it around,'][abs(cmp(x,0))]
  })((lambda x,o: [(['Twenty','Thirty','Forty','Fifty',
  'Sixty','Seventy','Eighty','Ninety'][x/10-2]+'-'+o.lower()).replace('-no more',''), o][int(x<20)])(x, ['No more','One','Two',
  'Three','Four','Five','Six','Seven','Eight',
  'Nine','Ten','Eleven','Twelve','Thirteen','Fourteen',
  'Fifteen','Sixteen','Seventeen','Eighteen','Nineteen'][[x,x%10][int(x>=20)]]),'bottle%s of beer' % ['','s'][abs(cmp(x,1))])
  for x in xrange(99,-1,-1))
This means that language by itself cannot prevent the programmer from doing outrageous actions, nor can it avoid the programmer from being very clean and systematic.

Programmers make clean, standards-based programs, not languages.

You can make good C or C ++ programs, it depends on the rules you follow. And you can make bad and poorly maintainable programs in both languages. It depends on the team of programmers and the rules.

[Berni]

I you exclude all C++ goodies (inheritance, STL, constructors and destructors, ...) the question is why you should use it then on a small platform (e.g., Arduino) at all. Just to write classes and methods instead of structs and functions is then more like syntactic sugar.

I agree with this.
Some people seem to like the syntactic sugar though.

I usually use a naming convention with a prefix, so it's really a matter of sugar indeed.

For instance:

Code: [Select]

void GPIO_Set(void)
{...}

GPIO A;

GPIO_Set(A);
(or: GPIO_Set(&A), depending on how GPIO is defined exactly.)

in C++ you'd have something like:

Code: [Select]

GPIO::Set()
{...}

GPIO A;

A.Set();

Cute, but that's sugar. Not even *that* much more compact. Thing is, C++ will tend to make you structure your code "better", whereas in C, you'll need more discipline for a similar result. To some it's not a problem at all, but I must admit I have witnessed a LOT of developers truly lacking discipline.

One aspect of C++ some developers seem to like in embedded settings are templates. Whereas they are arguably "better" and a lot more featureful than macros, they can also be a nice opportunity for shooting yourself in the foot, so I'm not sure I'm completely sold. Never had that much trouble using macros, as long as they follow some rules, are clear and don't have unwanted side-effects.

As some of us have already said, the crux of the matter is to define a subset of C++, with every developer using a slightly different one, and no real standard or hard guideline for choosing one.

Where C++ syntax sugar is more effective for sweetening the code is when something has to maintain its own state and perhaps exist in multiple instances.

Code: [Select]

MasterSPI spi1(REGS_SPI1, 1000000);
spi1.write(0xAA);

Where as back in C one would have to do:

Code: [Select]

SPI spi1;
spiInitMaster(&spi1, REGS_SPI1, 1000000);
spiWrite(&spi1, 0xAA);

This is the usual "C with classes" use of C++ to hide a struct under a fancy looking table cloth. Any decent C++ compiler should generate similar machine code for both of these, but the C++ version looks nicer and is less error prone. Fancier stuff like inheritance can be done by sticking structs in structs, virtual/override functions can be done with function pointers...etc it all just looks uglier in C but works much the same.

Still its the programmers job to keep the code organized, the language just potentially gives him more tools to do so. The only issue with C++ is that it gives him a whole mechanics shop worth of tools but they never learn what all the tools are for, instead they figure out how to use some of them and then use those tools to do everything. As a result the tools get abused for doing things they ware never meant for, then the next guy come along and knows a different set of tools so the ones he used make no sense to him. But when all you get is a single tool belt with just the essential tools hanging of it then everyone will know what each tool is for and how to use it (like in C).

[shangaoren]

Both languages are compiled languages, comparing two well written programs will result in a equality in terms of size and performance.

I use c++ for embedded application, i really like constexpr, template and OO programming, i feel it more flexible but there is nothing that can't be done in C, it's just i prefer C++.

The debate of STL is not meaningful as there is no such thing in C, IMO it's an "additionnal framework" you can do c++ without using STL.
STL needs to be avoided for memory allocation in embedded application just like string and printf in C ...

Any language can tend to crap if written by a bad programmer ....

[JPortici]

I agree, but to be fair I see that with C as well, especially with embedded. Modern compilers do a much better job reducing a somewhat lenghty (but legible) code but developers fall to the temptation to write cryptic constructs with the same effect. Perhaps to showcase how smart they are? Or job security?

I'd be tempted to say the first. It's not easy to admit that the compiler can be smarter than you, especially if you used to program with -O0 (ages old XC8 in Free mode cough cough..) and/or write cryptic code so you keep thinking you can write better assembly.

[paulca]

On C++.  I had to create a static class variable.  The initialiser syntax is absurd.  It's like they thought, "Which parenthesis have we used least?  Give it some exercise."

String MyESPDeviceClass::firmware{ String("") };

Wha?!?  It works, but it makes no sense.

... and don't even get me started on class/object initialises versus constructors.  My head melts.