Just another C vs C+ vs C++ debate

This is a discussion on Just another C vs C+ vs C++ debate within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Mod's note: split from here: http://cboard.cprogramming.com/showt...872#post824872
Then you need more experience with C++, clearly. C++ isn't a "shallow" C. It ...

Just another C vs C+ vs C++ debate

Then you need more experience with C++, clearly. C++ isn't a "shallow" C. It supports much more high-level and less mind-boggling ways to do things.
And don't talk about overhead in containers. Did you try them? Sometimes, they are even better than your "homebrew" solution.
In fact, C++ will get a number of more features in the coming standard that can make it faster than C in some circumstances.

Furthermore, your insistence of "C" makes you a bad modern programmer, since the point of C++ is to use pre-defined, existing solutions to quickly achieve your goal with less time spent debugging and thinking. And it's also safer.
Furthermore, since the book is supposed to teach C++, it's a bad book, because it does not teach C++, it teaches "C+".

Eh, let's leave the defences to people who can substantiate their claims.

Originally Posted by Elysia

Then you need more experience with C++, clearly. C++ isn't a "shallow" C. It supports much more high-level and less mind-boggling ways to do things.

C is only mind boggling if you do not understand simple things like functional decomposition, which is key to procedural programming. Unless your claim is that procedural programming itself is mind boggling. In which case I agree, since it is natural and we humans take this method for granted it takes time to understand in the same way it took time to learn that solving algebra equations in a series of steps. But that doesn't make C++'s learning curve any flatter.

Originally Posted by Elysia

And don't talk about overhead in containers. Did you try them?

But you must talk about overhead in the containers at least some of the time. I have you on record saying that functors means overhead, and functors are important in regular use of the STL. Unless you think that using containers make the stuff in <algorithm> faster....

Originally Posted by Elysia

In fact, C++ will get a number of more features in the coming standard that can make it faster than C in some circumstances.

I'd like to see you support this claim.

Originally Posted by Elysia

Furthermore, your insistence of "C" makes you a bad modern programmer, since the point of C++ is to use pre-defined, existing solutions to quickly achieve your goal with less time spent debugging and thinking. And it's also safer.
Furthermore, since the book is supposed to teach C++, it's a bad book, because it does not teach C++, it teaches "C+".

But there are pre-defined, existing C libraries that can help one quickly achieve their goals with minimal debugging. If C++ makes programming easier because you can spend less time thinking, than that's probably a benefit by detraction. C++ in no way mitigates the time you must spend to get familiar with it, and the time you must spend to design programs in whole or in part. C++ only can make the implementation faster and only marginally so, depending on the specific problem and the bugs you have to fix.

C++ is lucky that it has a standard library, but that was not always the case and many authors focus on teaching core concepts rather than the nooks and crannies of the STL. Many author's view this as a separate topic, and a companion text on the STL is often the best resource. A common gripe is when a C++ book does an outright faulty job of teaching OOP (or ignores the subject completely) when they talk about classes. It makes it impossible to use the STL, because pupils will not understand how data can be componentized with operations.

I don't mean to defend the author's work, but I don't see how these claims are any argument against the book. The author doing a poor job does not mean that you need to argue C v. C++ at all.

Like I said, leave the defenses to those who can substantiate their claims.

C is only mind boggling if you do not understand simple things like functional decomposition, which is key to procedural programming. Unless your claim is that procedural programming itself is mind boggling. In which case I agree, since it is natural and we humans take this method for granted it takes time to understand in the same way it took time to learn that solving algebra equations in a series of steps. But that doesn't make C++'s learning curve any flatter.

As much as may hate to admit it, but remembering formatting options, flags, etc is harder than remembering functions, or nothing at all.
To print an integer in C:

Code:

printf("%i", myint);

In C++:

Code:

std::cout << myint;

The passings of many levels of pointers in many cases is another example that C++ somewhat avoids through containers and references.

But you must talk about overhead in the containers at least some of the time. I have you on record saying that functors means overhead, and functors are important in regular use of the STL. Unless you think that using containers make the stuff in <algorithm> faster....

Absolutely, but as you say, don't dismiss the containers before you've actually tried them! Usually speed is faster or negligible even with the overhead, so sometimes the overhead is justified, as well.
As well as debating the easiness of using a container vs doing it manually.

I'd like to see you support this claim.

Oh, I see I also slightly misworded the reply there. I meant

In fact, C++ will get a number of more features in the coming standard that might make it faster than C in some circumstances.

And I am, of course, referring to move constructors and enhancements in template programming, as well as more usage of compile-time code.

But there are pre-defined, existing C libraries that can help one quickly achieve their goals with minimal debugging. If C++ makes programming easier because you can spend less time thinking, than that's probably a benefit by detraction. C++ in no way mitigates the time you must spend to get familiar with it, and the time you must spend to design programs in whole or in part. C++ only can make the implementation faster and only marginally so, depending on the specific problem and the bugs you have to fix.

I was thinking of vector, smart pointers, certain algorithms, etc.
Instead of doing it manually which is more dangerous and more time consuming, it saves time.

I don't mean to defend the author's work, but I don't see how these claims are any argument against the book. The author doing a poor job does not mean that you need to argue C v. C++ at all.

Like I said, leave the defenses to those who can substantiate their claims.

Oh no, you misunderstand. This is not a C vs C++ debate, this is a "C+" vs C++ debate.
The poster I replied to is typically stuck in C thinking when using C++, which is not a good thing™.
If you are going to learn and/or use C++, then you should by all means do it properly.
No using strcpy, malloc, fopen, fread, etc, but using C++ facilities.
This was my message, and that C++ is like the sun is to the moon compared to C.
Different languages, and one must adapt. And once one does, that one will find it much easier to do trivial tasks, simply because C++ is a more modern language.

As much as may hate to admit it, but remembering formatting options, flags, etc.

I don't think your foibles have any pertinence to the subject.

Absolutely, but as you say, don't dismiss the containers before you've actually tried them! Usually speed is faster or negligible even with the overhead, so sometimes the overhead is justified, as well.As well as debating the easiness of using a container vs doing it manually.

I'm not debating this but you seem to have a mental block where I discussed C libraries. I don't think performance concerns are one reason why a pupil studies one language over another.

Originally Posted by Elysia

Oh, I see I also slightly misworded the reply there. I meant

Whatever you meant does not deter my interest in your defense of the claim, but I'm seeking empirical evidence regarding which new features improve the performance of C++ over C. PM me about it when you come up with something substantial.

I was thinking of vector, smart pointers, certain algorithms, etc.
Instead of doing it manually which is more dangerous and more time consuming, it saves time.

Using a C library is in no way "doing it manually" and you seem to not understand how this falls under my earlier comment about implementation details. You mentioned that with C++ "the programmer spends less time debugging and thinking". About what is left unstated. In the same way that a C++ library helps the programmer spend less time thinking and debugging so can a C library. The design phase of a program, which also applies to the context of your argument, is no way hurried by either language.

Originally Posted by Elysia

Oh no, you misunderstand. This is not a C vs C++ debate, this is a "C+" vs C++ debate.

I did not understand how some of your arguments were applicable, is that ok with you?

And I don't think what works for you works just as well for any other. There is a reason why some languages are more popular than others.
But w/e.

I'm not debating this but you seem to have a mental block where I discussed C libraries. I don't think performance concerns are one reason why a pupil studies one language over another.

I quote the original poster:

Originally Posted by coletek

Ok, well I see you points. But as a C coder, I only use C++ when I really need a O-O arch. When I use C++ I still use C style coding methods. I personally don't see the point in the overhead of using some C++ stuff (eg. string wstring) when it can be done in C (eg. char). Another example is iostream (what is wrong with printf, scanf).

From my point of view, C++ is only good for its ability to handle O-O for your large task at hand. In any other case it should be just C.

So based on my above comments I see the book as good. I just read the ACCU comments and while I agree with he's comments I still see it as a good book. Probably more so, because of the great layout and method to ref things so easy - something I've found hard to find in any books.

This poster seems to like doing things manually, which I originally objected against. C, by default, does not have facilities for these kinds of things. And many C coders do things manually, from what I have witnessed from comments on the board.

Whatever you meant does not deter my interest in your defense of the claim, but I'm seeking empirical evidence regarding which new features improve the performance of C++ over C. PM me about it when you come up with something substantial.

I am not "in" these kinds of things, but if you would just not be so stubborn and look at the features presented before you, maybe you would understand that YES, maybe if done right, it might provide improvements over equivalent C code. And I say MIGHT and MAYBE, not that it WILL.
Believe me or not, I seriously do not care. Take it as you will.
I am, however, mentioning it to the original poster that C++ has some powerful facilities that rivals C or can even be more efficient, negating the "always use C within C++" claim or approach the OP has.

Using a C library is in no way "doing it manually" and you seem to not understand how this falls under my earlier comment about implementation details. You mentioned that with C++ "the programmer spends less time debugging and thinking". About what is left unstated. In the same way that a C++ library helps the programmer spend less time thinking and debugging so can a C library. The design phase of a program, which also applies to the context of your argument, is no way hurried by either language.

The design time for the library is irrelevant. I do not know if there facilities for these things in C (as external libraries, not associated with the standard), but from what I would see, most C programmers do these things manually.
The OP is probably included. And I wanted to also express why this is usually a bad idea.

I did not understand how some of your arguments were applicable, is that ok with you?

If these comments still make you fail to understand, then leave it at that. I will not be trying to explain further to such a negative member who has a grudge towards me.

And btw, would it not make sense for the original post to be included? Otherwise the context for the reply disappears.
I was trying to explain to a coder who uses C++ with C-style approach why it is not good or bad, and I get slammed for it. Very fair.
And lastly, I have a request. If these posts are not to be associated with the post it was originally meant to reply to, to reach out its purpose, then there is no point at all in keeping them. I do not NOT want this to be seen as another debate "C vs C+ vs C++". If that is it viewed as, and / or will be viewed as, then I request that the topic be deleted along with its contents. It would have failed to serve its purpose.

Furthermore, your insistence of "C" makes you a bad modern programmer, since the point of C++ is to use pre-defined, existing solutions to quickly achieve your goal with less time spent debugging and thinking. And it's also safer.
Furthermore, since the book is supposed to teach C++, it's a bad book, because it does not teach C++, it teaches "C+".

You're being subjective... again. You just have to cope with that - different people approach programming differently - object-oriented programming and all those extra features are not better than normal procedural C style, they're just different. It's a matter of taste.

And the safety you mention, it's more like fool-proof than safe, and I'm not a fool, so I don't see an advantage there.

But is it good to use C++ programming using C-style techniques?
And is it good to read or recommend a book that uses C-style techniques, but teaches C++ programming?
I know I'm being subjective. I can't help it. I try not to be, but it's like it's buried in my DNA or something.

But is it good to use C++ programming using C-style techniques?
And is it good to read or recommend a book that uses C-style techniques, but teaches C++ programming?
I know I'm being subjective. I can't help it. I try not to be, but it's like it's buried in my DNA or something.

A good book teaches both. And yes, it doesn't matter which style you use (as long as your employer is fine with it). I find some C++ features handy, but not all of them - so I don't use all of them, but that doesn't make me a "C+" programmer, since a C feature is also a C++ feature and should not be treated as it is not. It's not like the objective of C++ programming is to use as much C++-only features as possible.

Ah, so it IS a subjective matter, then.
I know some have been called a "C+" programmer for mostly sticking to C, mixing them with C++.
And no, I don't believe a book that teaches this is a good book, and neither did those in the Book thread.

Ah, so it IS a subjective matter, then.
I know some have been called a "C+" programmer for mostly sticking to C, mixing them with C++.
And no, I don't believe a book that teaches this is a good book, and neither did those in the Book thread.

Like I said, if a book teaches only this, it is not a good C++ book, because a book should introduce all major features. Also I don't consider a book that teaches only the so-called C++ style to be good. Like I already said, a C++ book should teach both styles.

Like I said, if a book teaches only this, it is not a good C++ book, because a book should introduce all major features.

As Dewhurst quoted Mark Twain in the preface of C++ Common Knowledge, "a successful book is not made of what is in it, but what is left out of it". Remember, just as you rightly pointed out that "it's not like the objective of C++ programming is to use as much C++-only features as possible", an introductory book's author might not have "be the be all and end all tome of C++ programming" as the goal. (It would be tough to fight with Stroustrup's TC++PL anyway )

My objection to Overland's book on this point is that Overland chooses to leave out the wrong features by ignoring many of the commonly used components of the C++ standard library.

Originally Posted by maxorator

Also I don't consider a book that teaches only the so-called C++ style to be good.

The modern "C++ style", if we could call it one, is multiparadigm programming. Consequently, it is a superset of the "C style" of procedural programming.

Whenever you use those C++-style programming, cout and cin stuff, your executable file size will be larger.

And in my opinion, that's very inefficient.

That's why I'm still using what you called C+ style programming.

Proof, please.
It is known that templates can cause bloat, but may not necessarily do so, and it's still a very, very poor argument.
People's hard drives today are so big anyway that size hardly matters, mostly.