4 ms·

That whole paragraph is ridiculous. I'm commenting but really I should abstain because I feel I am lowering the tone with yet another great religious debate: C

That whole paragraph is ridiculous. I'm commenting but really I should abstain because I feel I am lowering the tone with yet another great religious debate: C vs. C++. "No. C isn’t simpler for C-style programming than C++ is, nor “closer to the hardware,” nor indeed more efficient. I have yet to see a program that can be written better in C than in C++. I don’t believe such a program could exist. By “better” I mean smaller, more efficient, or more maintainable." Firstly, I'm sure what he's writing there is predicated on the C++ STL being available, the use of which will in turn increase compilation times, because there's a lot of templated code to compile. I cannot see how you would implement strlen or malloc in C++ (EDIT: as efficiently and/or) more efficiently than C, particularly when you take casting void into account. It's not a far stretch then to imagine writing drivers and so on, where idiomatic C++ would be a distraction compared to C. In the above his metrics, smaller, more efficient, more maintainable - I can't see any features that C++ has that will allow them to be proven true. Any program that has to interact with a C library - Stroustroup would suggest library then to be wrapped to make it behave according to C++ style - if so - if the code is just calling a few library functions, C will be shorter and better by all his metrics. The most convincing is maintainability, but C++ has many more ways to skin a cat than C, so where C had the overhead of understanding someone else's data structure, C++ pretty much does too.

stinos 13y ago
[note: I use both C and C++ heavily, and I think you are interpreting Bjarne wrong here] the use of which will in turn increase compilation times sure, but that does not makes anything he says about it less true. You could even argue it has nothing to do with the discuession at all. I cannot see how you would implement strlen or malloc in C++ more efficiently than C He says "C is not more efficient" which means "C++ is as effecient, or more efficient". Which in turns means you are right, and he does not imply you are not (that's the "as efficient" part). Yeeha, you're both right, no need to start a war. Stroustroup would suggest library then to be wrapped to make it behave according to C++ style I'd rather think he'd suggest the library should have been written in C++ in the first place. Which is definitely shorter and better by his metrics. The most convincing is maintainability which again comes down to the "as efficient" part then.
- eliasmacpherson 13y ago
  Code that takes longer to compile is not better, more efficient, more maintainable. A C++ compiler will take longer than a C compiler to produce the same code from some C source code, providing it will compile, because they are not an exact match. I could argue about compilation times until I am very blue in the face, but I'll leave it at that and I won't do it here. I am saying that I think that it will take more C++ than C to write malloc or strlen, because of casting to void, so I am saying he's wrong. I could be mistaken however. I think a wrapper is less of stretch, to suggest that a library be rewritten in C++ as a defence of the simplicity of C++ would suggest a very large amount of cognitive dissonance.
  - CJefferson 13y ago
    "A C++ compiler will take longer than a C compiler to produce the same code from some C source code" While this is technically true, I have in the past measured this, and the difference on my code when optimising was < 5%, so I think nothing to worry about.
    - eliasmacpherson 13y ago
      Basically if you had to get a distro out the door, and 100 days to do it, given your example, if the code was written in C with a C compiler, you'd be done 5% quicker. It's not the sort of thing you can measure once and just forget about. Then of course by moving to a C++ compiler, the temptation is to use features that take forever to compile!
    - eliasmacpherson 13y ago
      This isn't really relevant to your point or to the discussion, but this is not the first time I've heard of these kinds of improvements in compile time: http://tech.slashdot.org/comments.pl?sid=4410261&cid=45332543 http://tech.slashdot.org/comments.pl?sid=4410261&cid=4533254... Obviously, what's being compiled is not exactly equivalent but the time difference is startling.
CJefferson 13y ago
Firstly, you can always assume the "C++ STL" is present, it is part of C++. While implementing strlen faster in c++ is harder, implementing qsort faster is easier, as you have the option of compiling a version with the size of type, and comparator, known and inlinable. Also, you could use a constexpr version of strlen on strings known at compiletime, and be sure the compiker will optimise out the call, unlike in C where you just have to hope the compiler will
- eliasmacpherson 13y ago
  Thanks for your reply. You can assume it's available in a general sense but you may not be allowed to use it, sometimes this happens. Stroustrup made a bold claim that no program exists, I pointed out strlen and malloc - that there exist programs that can be written more efficiently by his metric - your e.g. qsort, I do not dispute, but I refuted his claim. I didn't say implementing strlen faster, I merely said implementing strlen is not by any of his metrics a superior experience in C++. C would just use hardcoded strings or defines, with sizeof(). This is also a possibility in C++, but I was talking about the implementation of strlen not the usage.
  - adwn 13y ago
    Neither strlen nor malloc (nor qsort) count as programs under any pragmatic, non-nitpicking, definition. Even the assumption that implementing, e.g., a memory allocation algorithm in C++ is not more comfortable than in C, does no lead to the conclusion that writing a device driver (your example) in C++ is not more comfortable than doing it in C.
    - eliasmacpherson 13y ago
      I agree with you. Just to be clear: I'm not making bold statements like "I don’t believe such a program could exist.". But you do admit they are programs! That was all I was trying to do, refute his ridiculous claim - albeit with something marginally less ridiculous. How about a program calling a C library? The driver thing doesn't automatically lead to the conclusion - but it's not a far stretch to picture it being so. A simple thought exercise does not make a water tight argument. I can imagine writing certain parts of drivers being better under his metrics in C++ than C but I don't see it in black and white terms like he does. I can see the opposite being the case also. All that needs to happen for Stroustrup to be wrong is for one program to exist that beats his metrics in C instead of C++.

stinos 13y ago

[note: I use both C and C++ heavily, and I think you are interpreting Bjarne wrong here] the use of which will in turn increase compilation times sure, but that does not makes anything he says about it less true. You could even argue it has nothing to do with the discuession at all. I cannot see how you would implement strlen or malloc in C++ more efficiently than C He says "C is not more efficient" which means "C++ is as effecient, or more efficient". Which in turns means you are right, and he does not imply you are not (that's the "as efficient" part). Yeeha, you're both right, no need to start a war. Stroustroup would suggest library then to be wrapped to make it behave according to C++ style I'd rather think he'd suggest the library should have been written in C++ in the first place. Which is definitely shorter and better by his metrics. The most convincing is maintainability which again comes down to the "as efficient" part then.

eliasmacpherson 13y ago
Code that takes longer to compile is not better, more efficient, more maintainable. A C++ compiler will take longer than a C compiler to produce the same code from some C source code, providing it will compile, because they are not an exact match. I could argue about compilation times until I am very blue in the face, but I'll leave it at that and I won't do it here. I am saying that I think that it will take more C++ than C to write malloc or strlen, because of casting to void, so I am saying he's wrong. I could be mistaken however. I think a wrapper is less of stretch, to suggest that a library be rewritten in C++ as a defence of the simplicity of C++ would suggest a very large amount of cognitive dissonance.
- CJefferson 13y ago
  "A C++ compiler will take longer than a C compiler to produce the same code from some C source code" While this is technically true, I have in the past measured this, and the difference on my code when optimising was < 5%, so I think nothing to worry about.
  - eliasmacpherson 13y ago
    Basically if you had to get a distro out the door, and 100 days to do it, given your example, if the code was written in C with a C compiler, you'd be done 5% quicker. It's not the sort of thing you can measure once and just forget about. Then of course by moving to a C++ compiler, the temptation is to use features that take forever to compile!
  - eliasmacpherson 13y ago
    This isn't really relevant to your point or to the discussion, but this is not the first time I've heard of these kinds of improvements in compile time: http://tech.slashdot.org/comments.pl?sid=4410261&cid=45332543 http://tech.slashdot.org/comments.pl?sid=4410261&cid=4533254... Obviously, what's being compiled is not exactly equivalent but the time difference is startling.

CJefferson 13y ago

Firstly, you can always assume the "C++ STL" is present, it is part of C++. While implementing strlen faster in c++ is harder, implementing qsort faster is easier, as you have the option of compiling a version with the size of type, and comparator, known and inlinable. Also, you could use a constexpr version of strlen on strings known at compiletime, and be sure the compiker will optimise out the call, unlike in C where you just have to hope the compiler will

eliasmacpherson 13y ago
Thanks for your reply. You can assume it's available in a general sense but you may not be allowed to use it, sometimes this happens. Stroustrup made a bold claim that no program exists, I pointed out strlen and malloc - that there exist programs that can be written more efficiently by his metric - your e.g. qsort, I do not dispute, but I refuted his claim. I didn't say implementing strlen faster, I merely said implementing strlen is not by any of his metrics a superior experience in C++. C would just use hardcoded strings or defines, with sizeof(). This is also a possibility in C++, but I was talking about the implementation of strlen not the usage.
- adwn 13y ago
  Neither strlen nor malloc (nor qsort) count as programs under any pragmatic, non-nitpicking, definition. Even the assumption that implementing, e.g., a memory allocation algorithm in C++ is not more comfortable than in C, does no lead to the conclusion that writing a device driver (your example) in C++ is not more comfortable than doing it in C.
  - eliasmacpherson 13y ago
    I agree with you. Just to be clear: I'm not making bold statements like "I don’t believe such a program could exist.". But you do admit they are programs! That was all I was trying to do, refute his ridiculous claim - albeit with something marginally less ridiculous. How about a program calling a C library? The driver thing doesn't automatically lead to the conclusion - but it's not a far stretch to picture it being so. A simple thought exercise does not make a water tight argument. I can imagine writing certain parts of drivers being better under his metrics in C++ than C but I don't see it in black and white terms like he does. I can see the opposite being the case also. All that needs to happen for Stroustrup to be wrong is for one program to exist that beats his metrics in C instead of C++.