3 ms·

The same underlying point can be made in such contrasting styles: Linus ( http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linu

The same underlying point can be made in such contrasting styles: Linus ( http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus ) vs the OP.

tsahyt 14y ago
Still they're both effectively right about it. "Object oriented niceness" comes at a cost. With C++ it might be smaller than in dynamic languages like Python, where things like function call overhead can be ridiculously big, but it's still there.
- zwieback 14y ago
  I think they are both wrong about it. What the argument boils down to is that the limitations of C prevent you from using things that might lead you astray. That's not an argument for or against C++ it's just an argument against large languages in general and an argument for programmer discipline in specific. It might work for Linus if he reimplements C++ features in a better way but it does not help all users and doesn't help all the time. Do we honestly believe a beginning programmer will be better off reimplementing std::vector or just using a fixed array instead? If I remember correctly somewhere further down in that particular Linus rant he was saying that you can look at a call site and tell what's going on, the same argument the poster here is making, but do we honestly believe Linus never uses function pointers? And the argument about the name of the function giving us a rough estimate of the overhead does not sound valid to me. As a C programmer and former C++ programmer I can see a valid argument hidden in these types of posts but I think we'd be better off with a little less attitude and a little more useful guidelines.
  - gte910h 14y ago
    I think this IS C++ specific. ObjectiveC has a much smaller call site complexity penalty.
    - JoeAltmaier 14y ago
      Well, not specific. Surely it is in C++; surely it is in other languages too.
  - tsahyt 14y ago
    > Do we honestly believe a beginning programmer will be better off reimplementing std::vector or just using a fixed array instead? I believe a beginning programmer will be best off using fixed arrays at first, then reimplementing a basic version of std::vector when the need for it arises (which it inevitably will) and then use whatever vector datatype his chosen language offers him. This will give the programmer an understanding of what is actually going on and why the array is suddenly resizeable/resizes itself. That's the sort of attention to detail that separates a good programmer from a great one. > do we honestly believe Linus never uses function pointers Actually, they're all over the place in the kernel. They're used all the time when writing device drivers. I use them myself in every bit of quasi-polymorphic C code I write (although I'm not a kernel hacker). I think they're quite nifty actually although they can obscure things. Here we come back to how we're using constructs a language gives us. Used correctly, specifying well documented interfaces, they give birth to hardly any problems. Executed the wrong way, they give birth to all sorts of bugs and weird behaviour and obscure the code. > the argument about the name of the function giving us a rough estimate of the overhead does not sound valid to me. It only will if you know the function, yes. Otherwise it's a weird argument. I think your opinion is just as valid as Linus' is. I think, larger languages open the flood gates for decisions which can come at a cost for performance or maintainability. Programmers should be aware of that and useful guidelines would definitely help.

The same underlying point can be made in such contrasting styles: Linus ( http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus ) vs the OP.

tsahyt 14y ago

Still they're both effectively right about it. "Object oriented niceness" comes at a cost. With C++ it might be smaller than in dynamic languages like Python, where things like function call overhead can be ridiculously big, but it's still there.

zwieback 14y ago
I think they are both wrong about it. What the argument boils down to is that the limitations of C prevent you from using things that might lead you astray. That's not an argument for or against C++ it's just an argument against large languages in general and an argument for programmer discipline in specific. It might work for Linus if he reimplements C++ features in a better way but it does not help all users and doesn't help all the time. Do we honestly believe a beginning programmer will be better off reimplementing std::vector or just using a fixed array instead? If I remember correctly somewhere further down in that particular Linus rant he was saying that you can look at a call site and tell what's going on, the same argument the poster here is making, but do we honestly believe Linus never uses function pointers? And the argument about the name of the function giving us a rough estimate of the overhead does not sound valid to me. As a C programmer and former C++ programmer I can see a valid argument hidden in these types of posts but I think we'd be better off with a little less attitude and a little more useful guidelines.
- gte910h 14y ago
  I think this IS C++ specific. ObjectiveC has a much smaller call site complexity penalty.
  - JoeAltmaier 14y ago
    Well, not specific. Surely it is in C++; surely it is in other languages too.
- tsahyt 14y ago
  > Do we honestly believe a beginning programmer will be better off reimplementing std::vector or just using a fixed array instead? I believe a beginning programmer will be best off using fixed arrays at first, then reimplementing a basic version of std::vector when the need for it arises (which it inevitably will) and then use whatever vector datatype his chosen language offers him. This will give the programmer an understanding of what is actually going on and why the array is suddenly resizeable/resizes itself. That's the sort of attention to detail that separates a good programmer from a great one. > do we honestly believe Linus never uses function pointers Actually, they're all over the place in the kernel. They're used all the time when writing device drivers. I use them myself in every bit of quasi-polymorphic C code I write (although I'm not a kernel hacker). I think they're quite nifty actually although they can obscure things. Here we come back to how we're using constructs a language gives us. Used correctly, specifying well documented interfaces, they give birth to hardly any problems. Executed the wrong way, they give birth to all sorts of bugs and weird behaviour and obscure the code. > the argument about the name of the function giving us a rough estimate of the overhead does not sound valid to me. It only will if you know the function, yes. Otherwise it's a weird argument. I think your opinion is just as valid as Linus' is. I think, larger languages open the flood gates for decisions which can come at a cost for performance or maintainability. Programmers should be aware of that and useful guidelines would definitely help.