C++ and C

[Hi P]

Excuse my paint skills, which of these two would represent the comparison between the two languages?

 

C++ is basically C with more features.

 

 

C++ is based on C but doesn't have all its features.

 

 

1.- Which one is the correct representation?

2.- If it turns out to be the first one, then is there a reason to ever learn C and not just C++?

 

[reniat]

1 is more correct, though it kinda depends on what you define as "C". If you're talking old school ansi C (C89), then yes. There are newer versions of C (99 and 11) that added more, but I have no idea what those changes were and whether they are compatible with most C++ compilers.

 

The only reasons I can come up with off the top of my head for using C over C++ are:

1. You are working with an existing C codebase
2. you need a REEEAAALLLY tiny executable
3. You're working with a platform that doesn't have a C++ compiler

If you only learn one, I'd recommend C++ as it has objects, and it's easier to transition to another language. If you know C++, I'd imagine you can learn C best practice pretty quick, or you could shift to Java or C# because you are familiar with object oriented programming. Also, if its necessary for any reason, you can write C inside C++ (you can even write raw assembly in C++ if you really need it).

 

That said, I might be a bit biased because C++ is hands down my favorite language.

[Hi P]

7 minutes ago, reniat said:

you need a REEEAAALLLY tiny executable

What does this mean?

 

8 minutes ago, reniat said:

That said, I might be a bit biased because C++ is hands down my favorite language.

Do you have any tips as to where begin learning?

I planned to take the SoloLearn course, it's quick and just covers the basics, then I was going to look for books.

[reniat]

18 minutes ago, Hi P said:

What does this mean?

the size of your program after compilation. This is really only a major consideration in working with systems that have incredibly limited resources. A smaller executable is never a BAD thing, but it also doesn't affect the applications performance once it's been loaded into RAM.

[2FA]

If you end up working with embedded systems, a lot of them will be using straight C since it's much more system call efficient and sometimes they use a really finicky compiler.

[straight_stewie]

I believe the second one is correct. Even in the first version of Bjarne's "The C++ Programming Language" he mentions that not all C programs will compile in [at the time] his C++ compiler. He also mentions that those that do may not produce the results that one might expect.

 

An example of something that's always been perfectly valid C, but never been valid C++:

char* p = malloc(10);

 

 

Here's a good primer on the subject:

https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

[Mira Yurizaki]

https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

 

Basically C++ started off as an offshoot of C the standardization of C. As such, things that were introduced in subsequent C standards may not be compatible with C++.

 

I'm biased since I was an embedded software developer but just my thoughts with C or C++:

• I feel like C++ encourages dynamic memory constructs over static ones. In embedded systems I avoid dynamic memory at all costs in embedded systems because it lowers determinism and requires a heap, which basically eats into what little memory you have. And while I shouldn't be shy about using dynamic memory, it appears C++ still doesn't have a garbage collector, and I really don't want to remember to manage dynamic memory.
  • Yes I'm aware of auto_ptr, but it appears it's still something that must be manually done. This is unlike say C# where I don't have to worry about remembering to run some cleanup routine if an object no longer has references.
• If you know how to abuse C, you can achieve OOP behavior: https://www.state-machine.com/doc/AN_OOP_in_C.pdf
  • The concept of private and public symbols exists in C, but it's not obvious. And maybe I haven't really made a complex enough design, but I never really had a need for protected members and methods.
  • I haven't used inheritance because I haven't really had a need for it in my designs.
  • I've used virtual functions before via pointer implementation lists.

 

That's not to say I don't like C++ or think nobody should use it, but I don't feel that C is simply "obsolete" just because there are other languages out there. If there was a major problem I have with C, it's a bare-bones programming language so if you want any of the more fancy features of other programming languages, you're going to have to work at it. Or hope someone has a library that does it for you.

[Dat Guy]

C is cleaner, faster and usually gives you less overhead. C++ has grown into a "can-do-all" language. It all depends on what you need.

 

Note that C++ is not a proper superset of C.

int class = 0; /* class = reserved in C++, won't build... */

 

[reniat]

11 minutes ago, Dat Guy said:

C is cleaner

C is a much simpler language, but I'd argue "cleaner" is very much in the hands of the developer, and not the language.

 

11 minutes ago, Dat Guy said:

faster and usually gives you less overhead

I'm not 100% sure this is universally true, as C++ compilers can do some amazing things. Plus the overhead of c++ is incredibly minor outside of things like vritual.

 

that's not to say writing C in C++ isn't sometimes done (same with asm in C++) for performance critical sections.

[Dat Guy]

1 minute ago, reniat said:

"cleaner" is very much in the hands of the developer, and not the language.

That would be true if the C++ standardization...ers would finally drop alternative ways to achieve the same goal from the language.

[reniat]

Just now, Dat Guy said:

That would be true if the C++ standardization...ers would finally drop alternative ways to achieve the same goal from the language.

I'm not arguing that C++ isn't more complicated. Just look at all the different types of initialization:

 

1. dynamic initialization
2. early dynamic initialization
3. deferred dynamic initialization
4. static initialization
5. std::initializer_list
6. copy initialization
7. default initialization
8. direct initialization
9. aggregate initialization
10. I got bored of finding other types of initialization

but that doesn't mean code written in C is automatically cleaner than C++, that's entirely up to the developer. You can write incredibly elegant simple C++ code, and you can write disgusting bloated C code.

[Dat Guy]

It is much easier to write bloated C++ code than to write bloated C code. In fact, it is even easier to write bloated Assembly code (unless you have really understood the underlying CPU).

[reniat]

Just now, Dat Guy said:

It is much easier to write bloated C++ code than to write bloated C code.

Do you have any evidence for this? a SIGNIFICANT amount of the complexity of C++ can be ignored 90% of the time, and I don't think it's far to say that just because the language has more depth, it's going to be more bloated when comparing code written with the same skill level.

[Dat Guy]

Just now, reniat said:

Do you have any evidence for this?

Original research. (My own mistakes.)

[reniat]

Just now, Dat Guy said:

Original research. (My own mistakes.)

That's pretty anecdotal don't you think?

 

I really don't want to start a C vs C++ war. I 100% think both languages are entirely valid. I just want blanket statements like "C is cleaner" to be backed with something substantial.

[straight_stewie]

29 minutes ago, Dat Guy said:

That would be true if the C++ standardization...ers would finally drop alternative ways to achieve the same goal from the language. 

That seems like more of a gripe with "open" standardization schemes than it does with the language itself.

I've noticed that pattern of "feature bloat", for lack of a better term, with many computer related things that have ISO numbers, even those unrelated to the "computing for computings sake" side of things like language and OS standards. But that is a conversation for another thread, or perhaps a blog post.

[Unimportant]

14 hours ago, Hi P said:

Excuse my paint skills, which of these two would represent the comparison between the two languages?

The second one imho. Valid C code is not necessarily valid C++. Implicit void pointer conversion has already been mentioned as an example.

13 hours ago, reniat said:

you need a REEEAAALLLY tiny executable

Both C and C++ are based on the "you don't pay for what you don't use" principle. If you don't use any "fancy" language features then your C++ executable should be just as small and fast as the C executable. If you do use extra language features then it's probably because you need them and you should make a fair comparison with a C program that somehow implements the same functionality.

10 hours ago, Mira Yurizaki said:

I feel like C++ encourages dynamic memory constructs over static ones. In embedded systems I avoid dynamic memory at all costs in embedded systems because it lowers determinism and requires a heap, which basically eats into what little memory you have. And while I shouldn't be shy about using dynamic memory, it appears C++ still doesn't have a garbage collector, and I really don't want to remember to manage dynamic memory.

• Yes I'm aware of auto_ptr, but it appears it's still something that must be manually done. This is unlike say C# where I don't have to worry about remembering to run some cleanup routine if an object no longer has references.

 

First of all. Since C++11/14 it's std::unique_ptr and std::make_unique. Don't use auto_ptr. It's a kludge from before move semantics existed that'll get you into trouble.

 

Pre C++11 I don't see how C++ encourages dynamic constructs more then any other language at the time, any concrete examples?

Post C++11, with move semantics, you can pretty much do anything statically. (remember we have std::vector for dynamic arrays).

 

Proper RAII techniques make memory management nearly automatic and elegant, once you get used to proper RAII paradigms you don't even want a garbage collector anymore. On top of that RAII allows for cleanup of *all* resources, not just memory.

11 hours ago, Mira Yurizaki said:

If you know how to abuse C, you can achieve OOP behavior: https://www.state-machine.com/doc/AN_OOP_in_C.pdf

True, but that's a lot of manual work (for someone who just claimed manually cleaning up his memory is a hassle), and as such very error prone.

 

Note that I'm not arguing against C, C is not obsolete. However one should pick the right language for the task at hand. The canonical example is having to write a drawing application that can draw different shapes. The advantage of polymorphism should be clear in this case. You define a "shape" interface for the main drawing code to use and then implement all the shapes you need, even add shapes later, without the drawing code ever needing to change (not even requiring recompilation!) or know about any of this.

[Mira Yurizaki]

7 hours ago, Unimportant said:

Pre C++11 I don't see how C++ encourages dynamic constructs more then any other language at the time, any concrete examples?

Perhaps not the language itself but how I was taught it or used it outside of an academic setting, if that makes any sense.

 

Quote

Post C++11, with move semantics, you can pretty much do anything statically. (remember we have std::vector for dynamic arrays).

I wasn't claiming you couldn't do that.

 

Quote

Proper RAII techniques make memory management nearly automatic and elegant, once you get used to proper RAII paradigms you don't even want a garbage collector anymore. On top of that RAII allows for cleanup of *all* resources, not just memory.

Which I recall being taught also.

 

Quote

True, but that's a lot of manual work (for someone who just claimed manually cleaning up his memory is a hassle), and as such very error prone.

I don't see how it's a lot more work than setting up your classes in any other language. If anything, C feels more explicit since the other languages hide some details (e.g., the self pointer). In any case, I see this as building the foundations for whatever your software will do. After you get that squared away, building up on top of that is relatively easier and you don't have to think about it as much. Memory management is something you have to think about constantly if you use it. I'd rather have a program that either won't compile or will go down in blazing glory than one that happily runs but leaks memory.

Edited March 11, 2019 by Mira Yurizaki

[Sebivor]

On 3/11/2019 at 4:51 AM, reniat said:

1 is more correct, though it kinda depends on what you define as "C". If you're talking old school ansi C (C89), then yes. There are newer versions of C (99 and 11) that added more, but I have no idea what those changes were and whether they are compatible with most C++ compilers.

 

The only reasons I can come up with off the top of my head for using C over C++ are:

1. You are working with an existing C codebase
2. you need a REEEAAALLLY tiny executable
3. You're working with a platform that doesn't have a C++ compiler

If you only learn one, I'd recommend C++ as it has objects, and it's easier to transition to another language. If you know C++, I'd imagine you can learn C best practice pretty quick, or you could shift to Java or C# because you are familiar with object oriented programming. Also, if its necessary for any reason, you can write C inside C++ (you can even write raw assembly in C++ if you really need it).

 

That said, I might be a bit biased because C++ is hands down my favorite language.

I acknowledged a warning from two years ago to write this post up... You have been "warned"... whatever that means to the kind of person who finds flaws that can break the internet, ha! I'm not salty, though, guys... if you want to look like idiots, feel free.

Even in C89, these are features that C++ doesn't have:

• implicit `void *` conversions... not only do people tell you not to cast `malloc` in C++, they tell you to flat-out avoid `malloc` in C++. I wonder why?
• namespace-related discrepancies... unless you can get this code compiling as C++.
• "C allows hexadecimal floating point literals (eg. 1.1p-3), which are not valid preprocessing-tokens in C++... There are minor differences in the handling of universal character names (eg. \u0234)"
• C89 permits a recursive `main` function; C++ does not.

I would honestly continue; I'm sure I could, but would you read these words if you wouldn't read a book? Or how about reading this F.A.Q. written by Bjarne Stroustrup, founding forefather of C++, instead? Cue the next "warning"...

This discussion becomes completely unfair if you restrict C to C89, unless you also restrict C++ to C++98, as the world has moved on since these two language dialects and you won't find an employer taking you seriously if you don't also know C99, C11 and pretty soon C18 too. After all, would you hire someone who's so out of touch?

Then if we accept all of those more recent standards (as we should, since the rest of the world considers them standards) as defining C, then you should have `_Generic` (among a whole heap of other silly features that C++ already accommodates for) in C++ by now... good luck trying to convince the C++ standards committee to endorse that!

Oh, let's add one more thing to the list of reasons to give me a warning, huh? Where is your tokenizer?

[Sebivor]

On 3/11/2019 at 5:02 AM, Hi P said:

What does this mean?

 

Do you have any tips as to where begin learning?

I planned to take the SoloLearn course, it's quick and just covers the basics, then I was going to look for books.

Founding forefather of C++, Bjarne Stroustrup, has written a book for introductory programming students (i.e. those with no prior experience) and a book for intermediate students who already have some prior experience or maybe know another procedural language. I've not read them personally, as I've had my sights on other languages (such as Kotlin, Javascript and so forth)... but these are probably the ones I would pick if I were to focus on C++.

[reniat]

14 minutes ago, Sebivor said:

This discussion becomes completely unfair if you restrict C to C89, unless you also restrict C++ to C++98,

that's fair

[Sebivor]

1 minute ago, reniat said:

that's fair

I'm trying to figure out what that means... are you trying to say you would hire someone who admits to knowing C89 but not C99? Would you also hire someone who admits to knowing C++98 but not C++05 or C++11? Because as time progresses, languages change... right?

[reniat]

4 minutes ago, Sebivor said:

I'm trying to figure out what that means...

It means throughout the discussion since I posted that, I learned a bit more about C since ANSI C, specifically that it had grown as a language a lot further than I had initially thought.

 

yes I would agree that someone who doesn't know at least SOME of the features of C++11 (I would argue you don't need to know EVERYTHING new to the language) would probably not be a choice candidate for a senior C++ position, so the same is probably true for C.

[bloodthirster]

I'm pretty sure there are no nested functions in C++.

 

My thoughts generally mirror Linus Torvalds'.  There's never been a situation where I've seen some C and thought "wow, this would be so much better in C++" and I've seen a lot of C++ where they make a complete mess of things trying to write "C++" code.  In short, there are some code bases which C++ makes sense but in the vast majority of them C would have been the better choice. 

[reniat]

3 minutes ago, bloodthirster said:

In short, there are some code bases which C++ makes sense but in the vast majority of them C would have been the better choice. 

Can you go into more detail as to why they would have been better off in C? I feel this is less C vs C++ and more about whether you like OOP.