4 ms·

"that C is superior to full-blown C++[...]" I disagree that C is superior to C++ for most projects. First of all, C++ offers higher-level semantics which lead

by blub 16y ago

"that C is superior to full-blown C++[...]" I disagree that C is superior to C++ for most projects. First of all, C++ offers higher-level semantics which leads to an increase in productivity. According to [1], the ratio of C++ to C LOC is 1 to 1-2.5, but I'd be interested to read other studies or articles. My experience and [1] also contradicts your statement that rewriting code with STL/Boost will lead to increased code size. It's almost impossible for C++ to be more verbose than C - consider that you can write C-like code directly in C++. Second of all, for a developer that has good knowledge of both C and C++, writing quality C is harder. C is very prone to programmer errors, much more so than C++ where you can choose to use libraries/language features that completely eliminate some of these errors. e.g: scope-based destruction, the STL data structures, string classes, etc. Third of all, when discussing C++ many try to make C++ look as a frightening monster ("full-blown C++"?) where you have template meta-programming interacting with automatic conversions and operator overloading and all the other features in the worst possible way. This is not much different to claiming C is bad because you can use macros and void* for everything. The languages should be compared by real-world use patterns, not dreamed up criteria. [1] Estimating Software Costs (Jones 1998) and Software Cost Estimation with Cocomo II (Boehm 2000) "[...]that object-oriented programming is no panacea[...]" While it is true that some have argued for OOP as panacea, this is mostly a strawman. OOP is one possible solution that works most of the time.

Stormbringer 16y ago
LOC means nothing, and if you want to generate subtle programmer errors, then templates is definitely the way to go.
- blub 16y ago
  LOC means a lot when it comes to: * reading and trying to understand source code * maintaining source code * typing and programming-related injuries The dynamic-typed camp argues that even declaring a variable is a pain. Conciseness is one of the favourite features of JS/Ruby/Python developers and prolixity is universaly loathed in Java. Please expand on your assertion that subtle programming errors are caused by templates. I'm interested especially in errors as a consequence of using templates from the STL or to build generic code. i.e: not metaprogramming
  - rdtsc 16y ago
    > reading and trying to understand source code ... maintaining source code I think it helps but in general those things are not related very well. For examples guess what this line of code does (this is APL) ? X[⍋X+.≠' ';] According to APL's Wikipedia entry it "sorts a word list stored in matrix X according to word length". It is just 1 line of code so it wins there. But now imagine reading code like that and maintaining it.
    - blub 16y ago
      An extreme example doesn't prove much and there are many languages that successfully balance readability with LOC. e.g: Python, JS.
      - rdtsc 16y ago
        Right, I was just trying to highlight that a simple metric of LOCs is not enough. One can right cryptic code to minimize LOCs but that usually leads in harder to read and maintain code.
    - anon_d 16y ago
      It's silly to expect to be able to understand text in a foreign language. If you want to read APL, learn APL; It's a great language.
- roel_v 16y ago
  "if you want to generate subtle programmer errors, then templates is definitely the way to go." Please indicate how so. I cannot think of ways that make templates more prone to programmer error than, let's say, str_xxx functions for which the programmer needs to allocate extra room for a \0 (or not, depending on which function you use...). Those types of C idiosyncrasies cause much more mistakes than any inadvertent template overload ever could.
  - antirez 16y ago
    agreed on str...(), but this is not semantic, is broken lib that is hard to update for backward compatibility issues, so in some way it is not a matter of the language.
    - roel_v 16y ago
      Fair enough, but I'm still interested in examples of subtle programmer errors with templates.
rdtsc 16y ago
> First of all, C++ offers higher-level semantics which leads to an increase in productivity. Strongly disagree. The full C++ spec, templates and all is pretty complicated. I am sure you can squeeze out less LOC out of it, but then why not just use APL. > Second of all, for a developer that has good knowledge of both C and C++. I think there are very few people who know C++ well. And by know I mean they know all of its aspects equally well. Now there are plenty of people who _think_ they know C++, but don't or just know just some parts of it well. I can easier trust someone who says they 'know C', because it is a fairly short spec, not so with C++. If you imagine a team of developers. If all of them are true C++, experts, then everything is fine. But I have never seen that. So one developer likes templates, another likes some other part of C++, and they start using that and eventually they all write C++ but they can't all necessarily read and understand each others' code. And here is where another 50 pages of C++ style guide comes in to help. But if a language needs 50 pages of custrom style guides to be useful, there is probably something wrong with that language. > It's almost impossible for C++ to be more verbose than C - consider that you can write C-like code directly in C++. I think it is a false dichotomy. I know the original article compared both head to head, your point picked it up, but in general it should'be be between C and C++ only. It should be C++ vs C+Python or C vs Go and so on. In other words comparing lines of code by presenting a somewhat artificial constraint is not that representative of the real world.
- blub 16y ago
  Templates again... Have you used them? In my current project we've used data structure and algorithm templates from the QTL (similar to STL) instead of inventing our own buggy versions. Then we've used templates to stream arbitrary data-types into an IPC socket. Finally, we've also used templates to create a generic repository class and to create a specialized compare function for multiple types of containers. All of these resulted in lesser lines of code without complicating the code base. This kind of template code is nothing fancy and brings real benefits. Now it's your turn to tell me how templates have complicated your projects. Please use real-world examples. By the way, we're not all true C++ experts in the team and yes, some of us prefer different coding styles. You know what we did? At the beginning we created a coding guidelines/standards document that outlines what is acceptable to use in the project. Problem solved. What you describe - "can't all necessarily read and understand each others' code" - is a dysfunctional team and a management failure. "it should'be be between C and C++ only" Ok, we can compare Python + C++ with Python + C, but C++ wins there too. e.g: PyQt/PySide.

by blub 16y ago

Stormbringer 16y ago

LOC means nothing, and if you want to generate subtle programmer errors, then templates is definitely the way to go.

blub 16y ago
LOC means a lot when it comes to: * reading and trying to understand source code * maintaining source code * typing and programming-related injuries The dynamic-typed camp argues that even declaring a variable is a pain. Conciseness is one of the favourite features of JS/Ruby/Python developers and prolixity is universaly loathed in Java. Please expand on your assertion that subtle programming errors are caused by templates. I'm interested especially in errors as a consequence of using templates from the STL or to build generic code. i.e: not metaprogramming
- rdtsc 16y ago
  > reading and trying to understand source code ... maintaining source code I think it helps but in general those things are not related very well. For examples guess what this line of code does (this is APL) ? X[⍋X+.≠' ';] According to APL's Wikipedia entry it "sorts a word list stored in matrix X according to word length". It is just 1 line of code so it wins there. But now imagine reading code like that and maintaining it.
  - blub 16y ago
    An extreme example doesn't prove much and there are many languages that successfully balance readability with LOC. e.g: Python, JS.
    - rdtsc 16y ago
      Right, I was just trying to highlight that a simple metric of LOCs is not enough. One can right cryptic code to minimize LOCs but that usually leads in harder to read and maintain code.
  - anon_d 16y ago
    It's silly to expect to be able to understand text in a foreign language. If you want to read APL, learn APL; It's a great language.
roel_v 16y ago
"if you want to generate subtle programmer errors, then templates is definitely the way to go." Please indicate how so. I cannot think of ways that make templates more prone to programmer error than, let's say, str_xxx functions for which the programmer needs to allocate extra room for a \0 (or not, depending on which function you use...). Those types of C idiosyncrasies cause much more mistakes than any inadvertent template overload ever could.
- antirez 16y ago
  agreed on str...(), but this is not semantic, is broken lib that is hard to update for backward compatibility issues, so in some way it is not a matter of the language.
  - roel_v 16y ago
    Fair enough, but I'm still interested in examples of subtle programmer errors with templates.

rdtsc 16y ago

> First of all, C++ offers higher-level semantics which leads to an increase in productivity. Strongly disagree. The full C++ spec, templates and all is pretty complicated. I am sure you can squeeze out less LOC out of it, but then why not just use APL. > Second of all, for a developer that has good knowledge of both C and C++. I think there are very few people who know C++ well. And by know I mean they know all of its aspects equally well. Now there are plenty of people who _think_ they know C++, but don't or just know just some parts of it well. I can easier trust someone who says they 'know C', because it is a fairly short spec, not so with C++. If you imagine a team of developers. If all of them are true C++, experts, then everything is fine. But I have never seen that. So one developer likes templates, another likes some other part of C++, and they start using that and eventually they all write C++ but they can't all necessarily read and understand each others' code. And here is where another 50 pages of C++ style guide comes in to help. But if a language needs 50 pages of custrom style guides to be useful, there is probably something wrong with that language. > It's almost impossible for C++ to be more verbose than C - consider that you can write C-like code directly in C++. I think it is a false dichotomy. I know the original article compared both head to head, your point picked it up, but in general it should'be be between C and C++ only. It should be C++ vs C+Python or C vs Go and so on. In other words comparing lines of code by presenting a somewhat artificial constraint is not that representative of the real world.

blub 16y ago
Templates again... Have you used them? In my current project we've used data structure and algorithm templates from the QTL (similar to STL) instead of inventing our own buggy versions. Then we've used templates to stream arbitrary data-types into an IPC socket. Finally, we've also used templates to create a generic repository class and to create a specialized compare function for multiple types of containers. All of these resulted in lesser lines of code without complicating the code base. This kind of template code is nothing fancy and brings real benefits. Now it's your turn to tell me how templates have complicated your projects. Please use real-world examples. By the way, we're not all true C++ experts in the team and yes, some of us prefer different coding styles. You know what we did? At the beginning we created a coding guidelines/standards document that outlines what is acceptable to use in the project. Problem solved. What you describe - "can't all necessarily read and understand each others' code" - is a dysfunctional team and a management failure. "it should'be be between C and C++ only" Ok, we can compare Python + C++ with Python + C, but C++ wins there too. e.g: PyQt/PySide.