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

[coppice]

That, and legacy COBOL code running government agencies....

A real beauty of COBOL projects is it takes years to put together a replacement. So, even if the end approaches, it approaches so slowly you have plenty of time to react.

[Berni]

Just because its OO and C++ does not necessarily mean its more reusable and modular. Its still perfectly possible to create a tangled mess that ties all of it into a monolithic blob that won't compile anymore as soon as you attempt to separate something from it.

Yes sure you can get some nice clean code when care is taken to follow this OO thing and implement things trough these interfaces, hide all of its state inside privates etc. If done properly it can make for quite little overhead. Every object is its own self contained module that you can plonk down in to any project and have it run etc... Why wouldn't you want to program like this? Its perfect. But then theory meets practice and half way trough a project you find that actually this object needs to do something to this other object somewhere completely else and make a link to it, binding it to be dependent on that object, this happens a few more times along the way, gradually bonding things together. Then a wild manager appears and not only bumps the goal post over but also turns it 180 degrees, so suddenly a lot of core functionality must change a bit so things are moved around and more of a mess is made. Then the deadline starts coming up and the thing MUST go out the door this friday or they miss some sort of important marketing window. Suddenly nobody has time to think about anything modular, people taking a sledgehammer to that OO wall and exposing some variables public so they can quickly tweak it and fix a bug so they can move on to the other 100 bugs that need to be fixed by the end of the week.

So just because you got OO in C++ doesn't mean its automatically more modular, clean and reusable. Its the guy behind the keyboard that determines how reusable code is, even if he is only using oldschool C with a few structs here and there to pretend being little OO when needed (not as pretty but it works)

[SiliconWizard]

So just because you got OO in C++ doesn't mean its automatically more modular, clean and reusable. Its the guy behind the keyboard that determines how reusable code is, even if he is only using oldschool C with a few structs here and there to pretend being little OO when needed (not as pretty but it works)

Yes of course.

Badly used inheritance can lead to code that is basically impossible to reuse outside of its intended initial use (or would require convoluted ugly interfaces...)

IMO modularity per se is best expressed with modules. You can still take a similar module approach with languages that don't inherently support modules. It just takes a lot of discipline.

[engrguy42]

Just because its OO and C++ does not necessarily mean its more reusable and modular. Its still perfectly possible to create a tangled mess that ties all of it into a monolithic blob that won't compile anymore as soon as you attempt to separate something from it.

Of course, but the exception does not define the rule. You can screw up anything. People love to raise specific issues (like inheritance) and say that since inheritance sucks the entire OO design idea is useless. Of course that's nonsense. If you don't like inheritance (I personally hate it and therefore never use it), then don't use it.

But as an engineer/user, as I said, I LOVE the incredibly intuitive concepts and designs associated with it.

So is it that most folks here don't deal with those higher level languages and design concepts because they're more about the lower level hardware systems?

[madires]

Arduino is C++, just saying.

[chriva]

Arduino is still junk no matter which language you use tho

[Nominal Animal]

So is it that most folks here don't deal with those higher level languages and design concepts because they're more about the lower level hardware systems?

I think so.

When I did custom stuff for a living, I specialized in server-side stuff, where hw is cheap, but security easy to fuck up (and that's what I'm good at).  Most of my code was either custom glue and security filtering between/in front of systems, or new to me too.

One 'library' that I failed with – in the sense of ending up rewriting it about half a dozen times in as many years – was form and file upload handling around the turn of the century.  Part of it was my inexperience (I didn't know what kind of API would work for most use cases and be maintainable in the long term), and part was that then, browsers were really, really shitty about following the standards (they didn't).  So you had user agent checks and workarounds galore.  I cursed the people who decided to use MIME instead of a chunked or escaped transfer encoding many a time to the deepest hells..  And a part was that I was also battling with other browser inanities, getting non-ASCII characters from various Windows and Mac systems to transfer correctly.  Not many people then cared, but I did.

Arduino is C++, just saying.

Ever tried to use an exception in Arduino?  No?  That's what I thought.

Arduino is not C++, but an unspecified subset of it.  You could call it freestanding C++, I guess, as opposed to normal hosted C++, because C++ leaves just about everything 'implementation defined' in freestanding environments.

That was one of my questions earlier, BTW.  Can you call it C++ if you are only allowed to use a small subset of the features of C++?  Especially when that subset is not described exactly anywhere?  I feel like saying it is C++ is misleading to newcomers/programmers, and will lead to frustration.

[coppice]

That was one of my questions earlier, BTW.  Can you call it C++ if you are only allowed to use a small subset of the features of C++?  Especially when that subset is not described exactly anywhere?  I feel like saying it is C++ is misleading to newcomers/programmers, and will lead to frustration.

Names are chosen to obscure, not illuminate. Hence they chose the name C++, that appears to be an incremental change from C, for a language that is a radical departure. If you strip C++ back to the point where it genuinely is an incremental change the name C++ would become meaningful, and that wouldn't do at all. 

[Wolfgang]

Arduino is C++, just saying.

Some thoughts to C++ on microcontrollers with limited memory:
IMHO, a really silly idea. Dynamic memory needs a memory manager, an this needs to take care of
fragmentation, free space recovery, garbage collection... Causing nondeterministic execution times, out of memory errors
when enough memory *should* be there, but not in 1 chunk as you need it and so on.
My strong advice: dynamic memory (malloc), OO string classes, ... forget it if you want a reliable app.
Arduino only works well if you never try something risky. Realtime/Interrupt stuff combined ith OO ? A nightmare.
Keep stack small, always know where your vars are, use C as an interface to machine language (L.Torvalds idea).
That should work on small platforms.

[nctnico]

Some thoughts to C++ on microcontrollers with limited memory:
IMHO, a really silly idea. Dynamic memory needs a memory manager, an this needs to take care of
fragmentation, free space recovery, garbage collection... Causing nondeterministic execution times, out of memory errors

That is a myth and thus completely wrong. For starters: C++ doesn't even has a garbage collector 

Arduino is C++, just saying.

Ever tried to use an exception in Arduino?  No?  That's what I thought.

Arduino is not C++, but an unspecified subset of it.  You could call it freestanding C++, I guess, as opposed to normal hosted C++, because C++ leaves just about everything 'implementation defined' in freestanding environments.

That was one of my questions earlier, BTW.  Can you call it C++ if you are only allowed to use a small subset of the features of C++?  Especially when that subset is not described exactly anywhere?  I feel like saying it is C++ is misleading to newcomers/programmers, and will lead to frustration.

But the same is true for C. There is a lot from the standard library you can't use. File I/O for example. Malloc & free are also troublesome to say the least.

[Wolfgang]

Some thoughts to C++ on microcontrollers with limited memory:
IMHO, a really silly idea. Dynamic memory needs a memory manager, an this needs to take care of
fragmentation, free space recovery, garbage collection... Causing nondeterministic execution times, out of memory errors

That is a myth and thus completely wrong. For starters: C++ doesn't even has a garbage collector 

Arduino is C++, just saying.

Ever tried to use an exception in Arduino?  No?  That's what I thought.

Arduino is not C++, but an unspecified subset of it.  You could call it freestanding C++, I guess, as opposed to normal hosted C++, because C++ leaves just about everything 'implementation defined' in freestanding environments.

That was one of my questions earlier, BTW.  Can you call it C++ if you are only allowed to use a small subset of the features of C++?  Especially when that subset is not described exactly anywhere?  I feel like saying it is C++ is misleading to newcomers/programmers, and will lead to frustration.

But the same is true for C. There is a lot from the standard library you can't use. File I/O for example. Malloc & free are also troublesome to say the least.

No language standard specifies how memory that is no longer needed is handled. Thats specific to a runtime component. 
And believe me, a lot of intelligent algorithms have been written to handle this. Problem. Efficient / Fast / Deterministic. Choose any two.

[coppice]

No language standard specifies how memory that is no longer needed is handled. Thats specific to a runtime component. 
And believe me, a lot of intelligent algorithms have been written to handle this. Problem. Efficient / Fast / Deterministic. Choose any two.

Many languages are specified with their run time environment, and are not really separable from it. Java assumes a garbage collecting environment, for example.

[SiliconWizard]

Some thoughts to C++ on microcontrollers with limited memory:
IMHO, a really silly idea. Dynamic memory needs a memory manager, an this needs to take care of
fragmentation, free space recovery, garbage collection... Causing nondeterministic execution times, out of memory errors

That is a myth and thus completely wrong. For starters: C++ doesn't even has a garbage collector 

Some of you are quick to shoot, aren't you?
The "garbage collection" argument he made was wrong indeed - C++ doesn't inherently have a garbage collector indeed. SO yes, remove that silly point.
The rest still applies - dynamic memory allocation, even without garbage collectors, CAN cause nondeterministic execution times - unless you use very specific allocators that are certainly not the ones that ship with the compiler. And of course that requires properly checking for successful allocation one way or another, which can be messy (or untractable - sometimes developers just don't know how to gracefully handle an out of memory condition.)
That's why dynamic allocation is frowned upon, or even forbidden if you follow rules from some safety-critical guidelines. If you have to follow this rule, properly using C++ is not impossible, but much harder than it looks.

Arduino is C++, just saying.

Ever tried to use an exception in Arduino?  No?  That's what I thought.

Arduino is not C++, but an unspecified subset of it.  You could call it freestanding C++, I guess, as opposed to normal hosted C++, because C++ leaves just about everything 'implementation defined' in freestanding environments.

That was one of my questions earlier, BTW.  Can you call it C++ if you are only allowed to use a small subset of the features of C++?  Especially when that subset is not described exactly anywhere?  I feel like saying it is C++ is misleading to newcomers/programmers, and will lead to frustration.

But the same is true for C. There is a lot from the standard library you can't use. File I/O for example. Malloc & free are also troublesome to say the least.

Yes, but that's not exactly at the same level. What he mentioned for C++ is at the language level itself, which is a lot more problematic - basically there are settings where you can't use some language features, which is confusing for programmers. OTOH, libraries are a slightly different matter: I don't think any of what you mentioned is a mandatory part of the C standard. File I/O and memory allocation are all optional, if I'm not mistaken. OTOH, a lot of advanced C++ features that could be problematic on small embedded targets are NOT optional as per the standard.

The point is: the right subset to use is hard to define, is usually NOT defined clearly and largely depends on each developer. Not an ideal situation.

[Picuino]

Arduino has 2k of ram. It is near impossible to do a good memory management with such a minimal amount of resources.
Normally, libraries work only with static memory, with the variables defined by default with each class.
Printf isn't even used because of the large amount of memory it consumes.

[madires]

Arduino is C++, just saying.

Ever tried to use an exception in Arduino?  No?  That's what I thought.

Arduino is not C++, but an unspecified subset of it.  You could call it freestanding C++, I guess, as opposed to normal hosted C++, because C++ leaves just about everything 'implementation defined' in freestanding environments.

Is there only one true machine language or one real BASIC? No! There are many flavours of each language. But there are also standards defining some specific variant of a language, like C++17 (ISO/IEC 14882:2017) or C18 (ISO/IEC 9899:2018).

[Picuino]

There have also been attempts to define subsets of C++ for embedded systems, but without much success.
https://en.wikipedia.org/wiki/Embedded_C%2B%2B

[maginnovision]

Arduino has 2k of ram. It is near impossible to do a good memory management with such a minimal amount of resources.
Normally, libraries work only with static memory, with the variables defined by default with each class.
Printf isn't even used because of the large amount of memory it consumes.

They teensy 4.1 can have over 8Mb of ram, arduino is not an mcu it's just a lousy ide and a set of libraries to use.

[Wolfgang]

No language standard specifies how memory that is no longer needed is handled. Thats specific to a runtime component. 
And believe me, a lot of intelligent algorithms have been written to handle this. Problem. Efficient / Fast / Deterministic. Choose any two.

Many languages are specified with their run time environment, and are not really separable from it. Java assumes a garbage collecting environment, for example.

Not true, IMHO. Some specify (Java) that GC is done, but not *when* its done and *how* its done. A ton of problems emerged from the fact that on a large machine Java never ran out of memory so no GC was done. The obliterated objects did contain some OS resources, however (e.g. handles) and some ugly day the app crashed because handles were out of stock. In Java, you may call GC(), *but there is no guarantee that something will happen*. On small hardware - this is deadly.

[IanB]

No language standard specifies how memory that is no longer needed is handled. Thats specific to a runtime component. 
And believe me, a lot of intelligent algorithms have been written to handle this. Problem. Efficient / Fast / Deterministic. Choose any two.

In C++ you have complete control over when each resource will allocated and when it will be freed. If you don't want to rely on heap allocation for memory you can make 100% use of stack allocation. You don't have to use dynamic allocation in C++ any more than you have to use malloc() in C.

C++ is actually very good at compiling for embedded systems because the compiler can allow for more expressive code (reducing bugs and improving maintainability) while producing binaries as small and fast as a C compiler.

Why do you say pick any two from efficient, fast or deterministic? Why can an efficient and fast program not be deterministic at the same time? I would suggest that most code written for small embedded systems is all of these.

[IanB]

There have also been attempts to define subsets of C++ for embedded systems, but without much success.
https://en.wikipedia.org/wiki/Embedded_C%2B%2B

This is a human problem, not a technical problem. Just because there is a supermarket full of food, does that mean you have to buy and eat everything that is on the shelves? Most people are selective, they buy what they need, leave what they don't.

[Picuino]

Arduino has 2k of ram. It is near impossible to do a good memory management with such a minimal amount of resources.
Normally, libraries work only with static memory, with the variables defined by default with each class.
Printf isn't even used because of the large amount of memory it consumes.

They teensy 4.1 can have over 8Mb of ram, arduino is not an mcu it's just a lousy ide and a set of libraries to use.

Arduino is not an IDE nor a development board. Arduino is a commercial trademark of Arduino LLC (the company). Many of its hardware and software products carry the Arduino brand in their name.
Teensy is not an Arduino LLC project. It just has a compatibility pack with the Arduino IDE, like other external projects.

When I spoke of Arduino I was referring to the development boards based on the Atmega328P, the most widespread.

[Picuino]

We are debating about the tools C or C++. But in programming there are two elements involved, the programming language and the programmers. Since the first time I had to program in a company (in my case with ladder language of the PLC) the simplest task was to learn the language.
The most difficult task was learning the method of representing the algorithms (Grafcet) and all the company standards that had to be followed in order for the software to be homogeneous and easily maintainable from the projects office to the workshop technicians.

In other languages ​​the same thing happens, the development environment (the company and the team you work with and its rules) are more important than the language itself.

[Picuino]

I think you can make good C++ software for microcontrollers, but that is very much related to being able to follow strict development rules and that programmers follow them efficiently.

[engrguy42]

Okay, I'm not gonna rub it in anymore. I promise.

Well, maybe just this one last time 

You guys need to get out more. Deep, never ending discussions of booleans and unrelated C stuff. Memory worries, garbage collection...

And me, I whipped together a wonderful app in C# in no time, and son of a gun it's already being used for important stuff. 

In the other forum I posted on a USB battery I have that needed a circuit to apply brief pulses of load to keep it on, otherwise the internal circuit would shut it off. So I kludged together a 555 circuit with some yummy PWM output, and now my battery stays on with 5 second pulses of load current every 15 seconds.

And to log its behavior I used my C# data acquisition app (see below). Took me, on and off, a couple days to build that app and put the finishing touches.

Now honestly, I know you guys just LOVE your C and all that embedded stuff, but come on. You can't do that in C. No way. Not possible. GUI stuff? Logging to CSV file? Making realtime charts/graphs that auto-update scaling factors as data comes in? Hell, that would take weeks to do that in C. Maybe months. Or years.

Anyway, I apologize. Just messin' with ya. C RULES!!!   

[Nominal Animal]

But the same is true for C. There is a lot from the standard library you can't use. File I/O for example. Malloc & free are also troublesome to say the least.

No, "freestanding C" is very well defined compared to "freestanding C++".  If you compare the standards, you'll find that C++ leaves it basically up to the implementation, which means that "freestanding C++" is implementation defined – it doesn't mean anything unless you specify the implementation.

For freestanding C, none of the standard library is available.  Facilities provided by <float.h>, <limits.h>, <stdarg.h>, <stddef.h>, <stdbool.h>, and <stdint.h> should be available.  Complex number support is optional, and using any floating-point variables or operations can require special consideration (for example, on hardware that does not support FP), but otherwise the core language features are available.  This is well defined, with few surprises.

For freestanding C++, some of the core language features, like exceptions, may or may not be available; you don't know, unless you know the implementation.  And Arduino folks don't say; they don't really even call the code C++, just "Arduino sketches".

It is true that the distinction between "freestanding" and "hosted" is crucial for C, but is often ignored because people think it is "obvious" from the context.  I think that is equally misleading to new programmers.

But there are also standards defining some specific variant of a language, like C++17 (ISO/IEC 14882:2017) or C18 (ISO/IEC 9899:2018).

Exactly.  And my point was that while "Freestanding C" is well defined in the standards with fuzzy edges around complex and floating-point support only, "Freestanding C++" is almost completely implementation-defined, including core language features like exceptions.

There must be a limit to how many core language features you can remove, and still call it the same language.  With C, you get mostly right if you say "the standard C library is not available", but with C++, all bets are off; and therefore a more descriptive label that much more important.

In the other direction, I've mentioned "POSIX C99", which means a hosted C99 (ISO/IEC 9899:1999) environment that provides IEEE Std 1003.1™-2017 System Interfaces.

(FWIW, I personally do point out to learners that "Arduino uses a subset of C++ features, not the full C++ language" with additional descriptions of those features depending on their knowledge level.  I do that because it is thus far it seems to foster the most reasonable expectations and helps with the intuitive grasp the environment.  Those expecting their hosted C++ to be directly applicable are usually sorely disappointed by the limitations.)