New code in C? Where and why, versus C++?
-
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
-
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
-
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
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.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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) {}
// i'm omitting the big-5 here
};this is no different than if i needed initialization in C except it's cleaner:
struct A {
int x;
};
void initializeA(struct A *a) {
// can't remember if -> is strictly C++ or not
(*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
-
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
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.
-
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) {}
// i'm omitting the big-5 here
};this is no different than if i needed initialization in C except it's cleaner:
struct A {
int x;
};
void initializeA(struct A *a) {
// can't remember if -> is strictly C++ or not
(*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
Did you mean strictly C++ ? And the answer is no, -> is good for C and C++.
-
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. :thumbsup:
Real programmers use butterflies
-
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.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.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
-
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
I've only ever dabbled in C++ and I had little use for it. From the early 90s until 2002 I used ANSI C (on OpenVMS). On my PC I have a few C/C++ compilers, but on three of my OpenVMS systems I've installed C (not C++) to play with on occasion. DEC C V6.0-001 on OpenVMS Alpha V7.2 Compaq C V6.4-005 on OpenVMS VAX V7.3 HP C V7.3-009 on OpenVMS Alpha V8.3 (I don't have C on my Itanium server. I may need to address that) The only thing I currently use C (not C++) for on my PC is an experiment in using ODBC (using a book from 1999). Oh, and of course, I use the "C pre-processor" for various manipulations of my C# code.
-
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
-
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. :)
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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. :)
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.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
-
I've only ever dabbled in C++ and I had little use for it. From the early 90s until 2002 I used ANSI C (on OpenVMS). On my PC I have a few C/C++ compilers, but on three of my OpenVMS systems I've installed C (not C++) to play with on occasion. DEC C V6.0-001 on OpenVMS Alpha V7.2 Compaq C V6.4-005 on OpenVMS VAX V7.3 HP C V7.3-009 on OpenVMS Alpha V8.3 (I don't have C on my Itanium server. I may need to address that) The only thing I currently use C (not C++) for on my PC is an experiment in using ODBC (using a book from 1999). Oh, and of course, I use the "C pre-processor" for various manipulations of my C# code.
PIEBALDconsult wrote:
Oh, and of course, I use the "C pre-processor" for various manipulations of my C# code.
The only reason I don't do that myself is for me intellisense and all that is too big of a productivity win. I respect you that in your case it's not. I can't remember what half the classes and functions are without VS prompting me with them every time I hit ( or . :laugh:
Real programmers use butterflies
-
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[^].Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
As of C++11, there's
final[^].Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
PIEBALDconsult wrote:
Oh, and of course, I use the "C pre-processor" for various manipulations of my C# code.
The only reason I don't do that myself is for me intellisense and all that is too big of a productivity win. I respect you that in your case it's not. I can't remember what half the classes and functions are without VS prompting me with them every time I hit ( or . :laugh:
Real programmers use butterflies
No such tools on OpenVMS :D . I never learned the Language Sensitive Editor (LSE).
-
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
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!
The less you need, the more you have. JaxCoder.com
-
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
-
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
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.
-
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.
