Just another C vs C+ vs C++ debate

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 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.

Quote:

---

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.

Quote:

---

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....

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally Posted by whiteflags

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.

Quote:

---

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.

Quote:

---

I'd like to see you support this claim.

---

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

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally Posted by Elysia

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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?

Quote:

---

Originally Posted by whiteflags

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

---

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.

Quote:

---

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:

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

We're just not communicating, so I don't see a point in continuing either.

I do have something to talk to you about though, so expect a PM from me shortly.

Quote:

---

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+".

---

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.

Quote:

---

Originally Posted by Elysia

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.

Quote:

---

Originally Posted by Elysia

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.

Just want to remind you guys,...

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.

Quote:

---

Originally Posted by audinue

Just want to remind you guys,...

Whenever you use those C++-style programming, cout and cin stuff, your executeable 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.

---

Ugh. That's not a good argument...

And it doesn't make a difference on larger projects anyway.

Quote:

---

Originally Posted by maxorator

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.

Quote:

---

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.

Quote:

---

Originally Posted by audinue

Just want to remind you guys,...

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.

Quote:

---

Originally Posted by Elysia

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.

---

I agree space is not a big problem but anyway the proof's here:

"C++" style

Code:

---

#include <iostream>

using namespace std;

int main() {
    cout << "Hello world!";
    return 0;
}

---

Result:

Code:

---

Output size is 269.50 KB

---

"C" style

Code:

---

#include <stdio.h>

int main() {
    puts("Hello world!");
    return 0;
}

---

Code:

---

Output size is 5.50 KB

---

Compile settings were exactly the same, I just changed the code.

Quote:

---

Originally Posted by maxorator

Compile settings were exactly the same, I just changed the code.

---

What if you used printf() which is far more equivalent to an ostream in terms of its formatting capabilities? And are you linking dynamically or statically?

Visual Studio:
C version: 7 KB
C++ version: 8.5 KB
Hardly code bloat.

EDIT: Result is the same with both printf and puts.

Quote:

---

Originally Posted by maxorator

I agree space is not a big problem but anyway the proof's here:

---

Stroustrup has an FAQ on this: Why is the code generated for the "Hello world" program ten times larger for C++ than for C?

Then again, your point that "it doesn't make a difference on larger projects anyway" makes sense either way.

Quote:

---

Originally Posted by brewbuck

What if you used printf() which is far more equivalent to an ostream in terms of its formatting capabilities? And are you linking dynamically or statically?

---

printf() results the same size.

And I was using MinGW.

gcc-mingw automatically links the libstdc++ as a static library, since it is not normally distributed to other machines, so your code would not necessarily work on those machines if it wasn't that way. Of course, if you link in the stdc library for you C executable, you would also end up with a fairly large executable. The latests MSVC version presumes that the library files are also installed on the target system, so you need to supply a few megabytes of DLL's if you distribute that code (unless you link statically, and then you end up with a LARGE executable).

Obviously, producing similar code many times over, as template code CAN do, that isn't actually particularly different. Say for example we write a templated function that produces a string from a number - now, we could simply produce the exact same piece of code for both signed and unsigned integer, short int, unsigned short, etc, etc, and another for double and float values. That would produce (say) four variants of the integer code, essentially identical, and two variants of essentially identical code for the float/double variants. With some clever use of specialization, you could do:

Code:

---

std::string tostring(int x)
{
  std::string result;
  if (x < 0)
  {
      result = '-';
      x = -x;
  }
  return result + tostring(static_cast<unsigned int>(x));
}

std::string tostring(short int x)
{
    return tostring(static_cast<int>(x));
}

std::string tostring(unsigned short int x)
{
    return tostring(static_cast<unsigned int>(x));
}

std::string tostring(float f)
{
    return tostring(static_cast<double>(f));
}

---

Now, we only need to implement a full version of unsigned int and double variants of the tostring functions - which I'm too lazy to do here [and admittedly, it's probably not a lot of difference between this way and the expand everything variant - but I think it shows that you MAY be able to reduce the overhead from templates by thinking about it a little bit].

--
Mats

Quote:

---

Originally Posted by laserlight

Stroustrup has an FAQ on this: Why is the code generated for the "Hello world" program ten times larger for C++ than for C?

Then again, your point that "it doesn't make a difference on larger projects anyway" makes sense either way.

---

Quote:

---

Originally Posted by Bjarne Stroustrup

I tested using gcc -o2 on a Unix and the two versions

---

Who wants to be a peon, and tell him that he made a typo? :D

Is a knife obsolete for making woodwork? Or should we all stick to sanders and lathes? I think you can see the relation to more simple tools to more advanced ones. I still have screw drivers. Sometimes its just less work than charging up a power tool.

Quote:

---

Originally Posted by sphynxter

Is a knife obsolete for making woodwork? Or should we all stick to sanders and lathes? I think you can see the relation to more simple tools to more advanced ones. I still have screw drivers. Sometimes its just less work than charging up a power tool.

---

But you speak of hobbyists (I am not implying you are a hobby programmer) who just do odd jobs, not of professionals who are faced not with the task of sanding down a little knick-knack but (to carry your analogy forward) of creating cabinets and furniture; when they get one project done, they move on to another, and so on. And furthermore, for the professional, time is of the essence, because time is money. You only get paid for what you produce so, in general terms, the more that is produced, the more money that is made.

That said, I am in a more or less contentious mood at the moment, and so I would add that your point is noted.

Quote:

---

Originally Posted by sphynxter

Is a knife obsolete for making woodwork? Or should we all stick to sanders and lathes? I think you can see the relation to more simple tools to more advanced ones. I still have screw drivers. Sometimes its just less work than charging up a power tool.

---

Neither C nor C++ is only a knife/screwdriver or only a power tool. It just so happens that the C++ toolkit comes with more power tools while retaining the more sensitive equipment of C. Consequently, I agree with Stroustrup's opinion as stated in the FAQ: C is better than C++ for small projects, right?

On this topic (somewhat) ... I thought C++'s ability to compile C89 was supposed to be a feature. Of course I get blasted when I tried to discuss things with Elysia earlier. It's my sincere hope that my original messages are understood as I intended them to be: I felt that others were doing a sufficient job ridiculing the book and I merely wanted to quiet Elysia's evangelism.

The topic is stale now.

But I have to say that if using C++ as a better C is worthy of such scorn, then I don't see why it is tolerated by the compiler anymore. It seems like something that should have ran its course long ago, rather than shifting the blame on the person using the tool. I'm probably just perturbed by Elysia's example. I'll get over it.

Ironically,Stroustrup himself had said that language comparisons are rarely meaningful. ;)
http://www.research.att.com/~bs/bs_faq.html#compare

Quote:

---

Originally Posted by whiteflags

But I have to say that if using C++ as a better C is worthy of such scorn, then I don't see why it is tolerated by the compiler anymore. It seems like something that should have ran its course long ago, rather than shifting the blame on the person using the tool. I'm probably just perturbed by Elysia's example. I'll get over it.

---

Using C++ as a better can be done true, but I wanted to say my piece, it would be done when the more advanced features cannot be used for some reason.
Like why use a screw driver when you have an automatic screw driver?
Further, I would like to add, as to the original topic, that a good, modern C++ book should teach modern C++ and not C with C++, which is again, why I wanted the OP to actually try out the rest of the language instead of feeling it's unnecessary.