|
W∴ Balboos, GHB wrote: frog-world
Is that a planet that orbits the Frogstar?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
It can be seen near 15° South of the Tadpole.
| 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 |
|
|
|
|
|
Well, they can't wear thong sandals.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
There's no telling how far the body-piercing trend has spread.
| 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 |
|
|
|
|
|
Only when adults. Until then they're legless.
|
|
|
|
|
This is something I'm really curious about, and maybe it's just because I'm newish to coding small gadgets, though most of it is comfortable to me since I cut my teeth on 6502 CPUs back in the day.
What is the purpose of writing new code in C for targeting, well ... anything?
I've put away my C compiler and simply relied on limited use of C++ features to keep the footprint the same as it is in C:
1. no vtables. slightly complicates inheritance, as you can no longer do virtual ~foo() {}
2. extremely limited use of the STL, if at all. I typically use std::atomic if available, but not std::string, for example
3. judicious use of extern "C" when exporting my main, or importing "C" headers
4. no exceptions/SEH/etc, RTTI or other C++ frills that bloat code or stack
Why do I do it?
Primarily for that sweet sweet RAII, but also general source management. Classes can keep everything together. HPP based libraries are useful for simplifying distribution. public and private members replace the need for hiding in C files in many cases. and many other reasons.
Should I not be doing it? Is there a reason this is bad form?
Is there a reason you wouldn't?
Real programmers use butterflies
|
|
|
|
|
Typical C++ baggage is a lots of behind the scenes function calls (ctor, copy ctor,dtor,=, &adressof. So if your program must execute in a certain amount of CPU clocks then C++ is a bad choice. Such as, you do not want to slow down "fly by wire" flap extender module by unnecessary function jumps for example
|
|
|
|
|
Maybe I just vastly misunderstand C++, but AFAIK you don't have to use ctors, which are basically "operator overloads" in a sense for object "creation/instantiation/initatialization". If they don't do anything the compiler doesn't generate code for them.
And addressof & does the same thing in C as it does in C++, unless you overload it.
The theme here is, if you don't use the feature, it doesn't produce the code to run the feature.
So if anything it seems a matter of education? Knowing what C++ will generate and what it won't.
I write code for real time devices in C++ all the time. There's no more latency than C.
Consider the following:
class A {
public:
int x;
};
This generates the same exact code as
struct A {
int x;
};
There are no constructors there. x will not get initialized on instantiation because I didn't write code for it. They are also both sizeof(int) in size.
If i needed initialization
class A {
public:
int x;
A() : x(0) {}
};
this is no different than if i needed initialization in C except it's cleaner:
struct A {
int x;
};
void initializeA(struct A *a) {
(*a).x=0;
}
The former doesn't pollute the namespace, and also prevents the case of forgetting to call the initialization function.
Real programmers use butterflies
modified 2-Mar-21 10:23am.
|
|
|
|
|
Did you mean strictly C++ ? And the answer is no, -> is good for C and C++.
|
|
|
|
|
That's what I thought, but I honestly haven't done enough "straight C" in years to remember where the lines are drawn anymore. That and modern compilers tend to leak C++ language features back into C, muddying the waters.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: So if anything it seems a matter of education? Knowing what C++ will generate and what it won't.
Perhaps this is the biggest issue. The level of knowledge one has to earn to know how to make the compiler generate what they want and even more importantly, know what the compiler will generate when reading someone else's code.
This knowledge has a cost (potentially a high cost) that needs to be maintained by the organization through the expense of time and paid experience of every developer reading or maintaining the code. That expense must be offset by the reduction in cost of using C++ features that eliminate writing boilerplate code and organizing code.
I suspect with the far simpler rules/capabilities of C code, you have to look at a lot less code you didn't write to understand exactly what it is doing without resorting to using a debugger or looking at assembly.
My current opinion is that the decision of C versus C++ would come down to the project size and the pool and expense of developers you want maintaining the code.
Imagine a "C++ developer" jumping into a project that required diagnosing a set of code that used partial and full template specialization a few levels deep and being asked to refactor it. Could they do it? The statements "I know C++" and "I know C" carry two different levels of trust. I would trust most people who claim to know C and I can easily test their knowledge. With C++, the question for me becomes, what parts of C++ do you know and how well do you know each?
Dave B
|
|
|
|
|
Yeah, I've seen some template stuff in C++ that seemed like voodoo to me. Just take a look at Spirit++[^] to see what I mean.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
It is very easy to delete unwanted aspects of classes like copy constructors and copy operators. If you can reduce the amount of dynamic objects used, performance can really improve and deleting those things can help. I have seen this many times.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
They autogenerated by compiler automatically even if the code does not declare them
|
|
|
|
|
Yes, I know and as I wrote they can be deleted or, in other words, effectively removed from usage. I do this to make a class uncopyable :
#define MakeUncopyable( className ) \
className( const className & ) = delete; \
className & operator=( const className & ) = delete; and any attempts to copy the object will fail to compile. This is useful for singleton objects and others where there can be only one.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I agree with you, especially in the embedded and low level stuff, every clock tick counts. With C++ a person could use abstraction and polymorphism too much and seriously hobble a quick process.
I would also add C is geared towards being closer to the metal and C++ more towards large applications, not that you can't do either in both. just use the right tool for the right job.
personally I prefer the simplicity of the C language, there is a reason why it still is so popular on the TIOBE index
|
|
|
|
|
Well, there was/is this Embedded C++ standard. No RTTI, no exceptions, no templates. But compilers have gotten much better since then, so those things shouldn't affect a footprint the way they used to unless you get careless.
No vtables? That certainly does complicate inheritance, because a non-virtual destructor in a base class can lead to derived classes not releasing resources. I wouldn't impose that restriction, because a vtable should only need pointers to functions that are actually virtual. Even Embedded C++ didn't strip out virtual functions.
I agree with your sentiment but think you're unduly handcuffing yourself with your restrictions.
|
|
|
|
|
Yeah the vtable thing might be overkill, but I don't like extra hidden overhead on my classes.
I'd rather make inheritance not a thing in many cases**
** you can do inheritance, you just have to be careful about who holds things that need to be freed when you don't have a virtual destructor. Most of the time in these cases, I factor my code such that my data is polymorphic, and my classes wrap that. It avoids the issue.
Real programmers use butterflies
|
|
|
|
|
If it's a one-witch show, great. If the whole coven is beavering away on it, you'll be hard-pressed to dispel Pareto. 
|
|
|
|
|
I think it depends on the size and the complexity of the project, ultimately, and given I don't have much room to work with on these little systems, I think it's okay. Maybe not ideal but okay. I've simply taken to being very careful not to let you inherit classes you shouldn't inherit from. I wish C++ had a "sealed" keyword though.
Real programmers use butterflies
|
|
|
|
|
As of C++11, there's final[^].
|
|
|
|
|
How did I forget about "final"? I would have guessed it was newer than C++11 anyway - more like 17 or something. My hero!
I guess I've got some code to refactor. Win!
Real programmers use butterflies
|
|
|
|
|
I think Java has this ( final not this )
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
honey the codewitch wrote: What is the purpose of writing new code in C for targeting, well ... anything?
For products that you want to put on market, you have to comply to a lot of standards (like MISRA) that are much easier to implement in C, which is the state-of-the-art language. Given the amount of legacy code, this will probably not change in the next decade, so C remains the language if choice because, well, it was the language of choice.
Of course, footprint & co also play a role, but not that much with modern compilers.
Honestly, I am working in the automotive industry, and when I see what people are able to do with C, I am glad they are not given more powerful tools to work with ; I have my personal blacklist of vehicles I will never put a foot in, unless their code gets rewritten and their hardware redesigned.
|
|
|
|
|
That is the easily the most compelling argument I've heard from anyone on the subject. 
Real programmers use butterflies
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
