General > General Technical Chat
How many people code in C these days, and if so, why?
<< < (96/99) > >>
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:

--- Quote from: westfw on May 22, 2020, 03:35:39 am ---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 ..."
--- End quote ---
Interesting; that is how I see Python: get code from somewhere... Pip away until you get all the libraries you need.


--- Quote from: westfw on May 22, 2020, 03:35:39 am ---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!
--- End quote ---
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?


--- Quote from: westfw on May 22, 2020, 03:35:39 am ---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...)

--- End quote ---
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:

--- Quote from: rsjsouza on May 24, 2020, 01:33:35 pm ---
--- Quote from: westfw on May 22, 2020, 03:35:39 am ---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!
--- End quote ---
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?

--- End quote ---
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).
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod