Just another C vs C+ vs C++ debate

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.