|
I ran into this problem with the small footprint Arduinos, folks where asking mw why I wanted to use C++ when C was so efficient, faster and used less memory. But I found there really wasn't much difference in size or speed...no response from the peanut gallery.
Now with devices with more memory I think that people still use C because that is what they are comfortable with.
In the late 80s early 90s I worked for the railroad in the cyber division and I tried to get people to cross over to C++ but not one person could I get to change. I taught classes in using the development tools, debuggers and worked with them one on one...nope!
|
|
|
|
|
Mike Hankey wrote: C was so efficient, faster and used less memory.
The last time someone told me that I challenged them to write code in C I couldn't write in C++.
I never got a response.
Real programmers use butterflies
|
|
|
|
|
Exactly, it's like going from B&W to Color. Yeah I'm old enough to remember. 
|
|
|
|
|
i like this - "The less you need, the more you have"
|
|
|
|
|
Using a limited set of C++ means almost the same as C but more convenience and a simpler code syntax.
You could say you are writing in "C+"!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I like that C/C++ is "multi-paradigm" and I wish C# were too.
|
|
|
|
|
C++ is anyway. I wouldn't say C is. It's got one mode - "the hard way" 
Real programmers use butterflies
|
|
|
|
|
Part of it is historical reasons, part the perceived overhead of C++ vs C, and part requirements of various Standards (as others have mentioned).
For example, neither Linux nor Windows use C in the kernel, because C++ RTL support for the kernel code does not exist. I did see an article about using C++ in Windows kernel drivers. It worked, assuming that (a) you didn't use things like exceptions, virtual function, etc., and (b) you don't use any RTL function that is not defined in the driver library.
One place I would probably use C in preference to C++ is hard real-time code. Because of the polymorphism support in C++, it is easier to write code with ill-defined latency in C++ than it is in C, but programmers with sufficient talent can do it in both languages.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I for one have written C code in C++ compilers from Day One of proper programming just saved them as C files, I have never seen or felt the need to do C++, from the day I wrote a program in Assembler, same in C and again in C++, C & Assembler can't really remember around the same size, C++ three times the size. Okay today better optimisation but still I always get the feeling with C++ theres more going on than I know about. (I do mostly embedded programming)
|
|
|
|
|
A recurring misconception I see about C++ appears to be the notion that it will write code that you didn't tell it to write, or use memory you didn't tell it to use.
It's simply not the case.
More the issue is, knowing what you're telling the C++ compiler to generate in terms of code.
To wit, there is no code that can be written in C that I cannot write in C++ and generate the equivalent machine instructions - even if doing so means giving up certain niceties like virtual inheritance, exceptions or run time type information.
RAII is reason alone to consider minimalistic C++ as an alternative to straight C. It generates no extra code, and it reduces lots of bugs.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: RAII is reason alone to consider minimalistic C++ as an alternative to straight C. It generates no extra code, and it reduces lots of bugs.
Exactly
|
|
|
|
|
If you work in a team with young and eager programmers that completed their degree less than five years ago, there is one good reason:
These young geniuses usually love to play around with every single feature of the tools they are given. They like to experiment, and they love to prove that they truly master even the most obscure little detail of the language, the library, the VCS or whatever. So they strive to use all of it, in the most intricate ways that "impresses" even the old coding gurus.
C++ is not the language you would want to put in the hands of a young genius for proving that he can do something that no one else can do. You certainly can do dirty tricks in C as well, yet it is far more transparent than the "advanced" C++ features. (Besides, dirty C tricks often require that the programmer is very familiar with hardware and compiler operations, which is not as common with young programmers today, compared to thirty years ago).
So C is a better way to discipline young geniuses, by depriving them of tools to create incomprehensive code.
(Similar arguments can be used for staying away from git, or Docker orchestration, or CMake, or...)
|
|
|
|
|
Yeah. Though I might argue that an appropriate LINTing adjusted for dev-house practices upon check-in solves this and numerous other issues. Some developer education is necessary, but unless you can convincingly argue to me that a C developer is cheaper than a C++ developer, I'd just as soon hire the C++ developer, give them the set of practices, and LINT their code.
YMMV
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: What is the purpose of writing new code in C for targeting, well ... anything?
You should use C because you are a witch, and love casting. 
|
|
|
|
|
I use Cisms like casting in C++ because I am a witch and use C++ in places that weren't really meant for full fidelity C++.
Real programmers use butterflies
|
|
|
|
|
I was being facetious, because in C I believe you are often forced to cast where you don't in C++. IE, from one of my articles...
SwcTabCtrl* tabControl = (SwcTabCtrl*) tabsC[selectedTabC]; in C, whereas C++ is:
SwcTabCtrl * tabControl = tabsC[selectedTabC]; I don't remember the reason for the forcing of the cast, but I believe it is some C-ism. Anyway, I detest the first code with great detestation. You shouldn't, though, because you are a witch!
|
|
|
|
|
This has been more-or-less a peeve of mine between C++ and C#, but when it comes to casting, or for that matter, having to use (and know the difference between!) '->' '::' and '.', if find the effective dumbing down of C# unfortunate. So - if forced to cast, perhaps it's a way to keep all the ducks in order and also letting you know there are ducks.
Behind the scenes "promotions" make life easier (and in certain SQL I depend upon them) but understanding being built into the code is (in my opinion) a plus.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Yes. I agree. To not mention that with the "placement new" operator is possible to create objects on existing memory blocks. Turning off the exception mechanism C++ is very good for the development of real-time embedded applications. Recreating the polymorfism in C, at best, has the same speed as in C++. But most of the time, C++ beats C in many areas, as the latter does not have templates. It's only possible to emulate them with macros, but macros, most of the time, are ugly and dangerous. Templates help with performances: for example, qsort has to do a callback to compare items; so, it spends CPU cycles, fools the CPU branch predictor, and possibly invalidates the level-1 instruction cache. With std::sort (or std::stable_sort) it's possible "to inject" the comparison into the algorithm. Yes, templates could make code bloating, but judicious use of non-template base classes could mitigate it.
|
|
|
|
|
i would use C as a personal preference. it's subjective.
also i rather be in company of C programmers than C++, that is also one reason you would use a particular language.
but, i assume you posted a question to get some objective info as why C is a better choice than C++ in your use case scenario.
maybe it is not. C++ was designed by Bjarne with zero cost abstractions in mind - "What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better."
lots of people in the game making business use C style code with the C++ compiler or as little as possible classes, shallow hierarchies and such. the C++ compiler is a powerful beast and we (the programmers) are in the business of automation. so in that sense it's a better choice.
C++ does not force you to use it in any way, that's good. i think Bjarne was hot on the OOP subject, if you read early editions of the book, but not so any more. he merely says C++ gives you complete support for OOP if you want it, among other things.
here is a statement from Bjarne's book that you may consider when programming embedded - "Except for the new, delete, typeid, dynamic_cast, throw operators and the try block, individual C++ expressions and statements need no run-time support."
for myself, i don't dislike OOP as a technical solution and capability. i dislike object orientation in people. that philosophy, look everything is an "object" and everything is related in hierarchies, took a wrong turn.
instead of a solution for a problem it became a problem of it's own and a philosophy of life. solving the problem of say input data > processing > output data with classes and objects (if you like) became looking at classes as something that has a life of it's own. carried away by work on the class rather then on the whole...
you know what i mean, that thing: this is a car and a car is a vehicle. then in the boom of OOP it became, either you do it our way or the highway.
|
|
|
|
|
I don't look at C++ as C with objects. If anything I look at it as C with templates.
Classes are just fancy structs anyway, and overuse of OO is for the birds, although admittedly I use more OOP than Generic Programming in C++ when I'm coding embedded, mostly because of code bloat issues with GP.
Martin ISDN wrote: everything is an "object" and everything is related in hierarchies, took a wrong turn.
I have a problem with those people too - particularly if they're calling themselves C++ developers. If you want an object oriented language, learn C#. That's not what C++ is about. You *can* use it that way, but I can also use my C compiler as an assembler by wrapping everything with asm {}.. it doesn't mean it's a great idea.
Real programmers use butterflies
|
|
|
|
|
Who needs inheritance in embedded world?
Behzad
|
|
|
|
|
Why wouldn't you use inheritance? Do design patterns really change that significantly in embedded code?
Real programmers use butterflies
|
|
|
|
|
This is absolutely what I do. And I agree with you that so long as you understand and are happy with the 'hidden' code that C++ abstractions introduce, there's nothing wrong with using them.
The only time I'll use C rather than C++ is if I'm targeting a platform that doesn't have a C++ compiler. And yes, I have one of those - it's a proprietary processor, has a port of GCC, Gnat (the GCC Ada compiler) but not G++. Yes, it's for a safety critical application. No, I can't talk any more about it.
C++17 and 20 have introduced some nice new little abstractions, like std::string_view and std::span that would be useful in a C-ish world - basically, they're just pointer and length in a struct...
Also - things like lambdas, once you realise they're just a function pointer (if you have no captures) or a function object, are equally usable in a resource constrained environment.
The main thing I'd be wary of would be over many templates, in case they introduce too much code with multiple instantiations of functions for different template parameters.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
modified 3-Mar-21 6:08am.
|
|
|
|
|
I didn't know lambdas reduce to a function pointer without captures. I thought they were always functors. Cool.
On that subject, how would you go about accepting a lambda as a parameter to a function without accepting std::function? (i'm pretty sure you'd need to make the accepting function a template but it would be cool if you didn't)
For the most part, in embedded code I limit my templates to things that basically replace preprocessor macros, like
#define BAR_STATIC_ALLOCATION_SIZE 256
struct bar {
char foo[BAR_STATIC_ALLOCATION_SIZE];
};
instead i might make a declaration that allows for the following
bar<256> b;
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: On that subject, how would you go about accepting a lambda as a parameter to a function without accepting std::function? (i'm pretty sure you'd need to make the accepting function a template but it would be cool if you didn't)
The way I generally do it on a non-constrained platform is with a template:
template<class F>
int do_something(F&& f, int value)
{
return f(value);
}
However - there is a C++ standard proposal paper for something called a function_view, which is intended as a lightweight alternative to std::function purely for passing functions as parameters. This blog article explains it more. I've seen other std:function alternatives as well - this one, here on CodeProject was one of the first I saw, IIRC.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
