3 ms·

For C programmers that hate C++

6 points by fogus 16y ago

burgerbrain 16y ago
Generic rant from someone who doesn't actually understand (and perhaps has not even heard?) the arguments people make against C++.
- tree_of_item 16y ago
  Not a rant. Plenty of code, not just talk. And he made a very good point, at that.
  - burgerbrain 16y ago
    Nothing about a rant that precludes it from having code... Everybody recognizes that C++ is generally safer to program in than C. This article doesn't discuss the real issues C++ has, it only addresses strawmen arguments against C++ that in reality are never actually seriously considered.
    - tree_of_item 16y ago
      It addresses pretty relevant issues concerning C vs C++. C++'s major faults are addressed not by C but by a higher level language.
      - burgerbrain 16y ago
        How about: C++ is absurd to parse compared to higher level languages that address it's numerous flaws, and compared to C.
nkurz 16y ago
I like the idea of this article, but I'm not sure that he chose a very good example. He's gone from showing a fragile run-time solution in C, to a slightly clunky compile-time approach in C++. But if this is the whole goal, why not just create a separate function for each of the three pixel types in C? For me, the interesting example would be showing how elegantly one can do the run-time solution in C++. In C, I'd probably give the structs a common header and add a rasterize function pointer called from a common loop. What's a more elegant way to do it in C++? [edit: The author does point out elsewhere that in this case he really does want a compile-time solution, although I'm not sure I understand his reasoning: http://www.reddit.com/r/programming/comments/fzwlh/for_c_programmers_that_hate_c/c1jx5ml http://www.reddit.com/r/programming/comments/fzwlh/for_c_pro... ]
- corysama 16y ago
  This example becomes much stronger when you have more than one rasterize function. Writing 3 separate functions for 3 pixel types is reasonable. Writing 9 functions for 3 pixel types * 3 rasterization styles is repetitive and error-prone. Writing 27 separate functions because you added 3 blend modes is very, very bad. At that point in C, you either start writing "creative" preprocessor macros, write a custom code generator or give up and eat the performance penalty of the run-time solution. A rasterization function needs to perform on the order of 1024x768x30 calls per second on the low end. Compared to inlinable static function calls, function pointer overhead becomes a big deal at that scale. "Creative" template abuse can be much worse than "creative" preprocessor abuse. However, elegant application of templates, such as policy-based design, can solve code permutation situations without repetition or performance problems.

6 points by fogus 16y ago

Generic rant from someone who doesn't actually understand (and perhaps has not even heard?) the arguments people make against C++.

tree_of_item 16y ago
Not a rant. Plenty of code, not just talk. And he made a very good point, at that.
- burgerbrain 16y ago
  Nothing about a rant that precludes it from having code... Everybody recognizes that C++ is generally safer to program in than C. This article doesn't discuss the real issues C++ has, it only addresses strawmen arguments against C++ that in reality are never actually seriously considered.
  - tree_of_item 16y ago
    It addresses pretty relevant issues concerning C vs C++. C++'s major faults are addressed not by C but by a higher level language.
    - burgerbrain 16y ago
      How about: C++ is absurd to parse compared to higher level languages that address it's numerous flaws, and compared to C.

nkurz 16y ago

I like the idea of this article, but I'm not sure that he chose a very good example. He's gone from showing a fragile run-time solution in C, to a slightly clunky compile-time approach in C++. But if this is the whole goal, why not just create a separate function for each of the three pixel types in C? For me, the interesting example would be showing how elegantly one can do the run-time solution in C++. In C, I'd probably give the structs a common header and add a rasterize function pointer called from a common loop. What's a more elegant way to do it in C++? [edit: The author does point out elsewhere that in this case he really does want a compile-time solution, although I'm not sure I understand his reasoning: http://www.reddit.com/r/programming/comments/fzwlh/for_c_programmers_that_hate_c/c1jx5ml http://www.reddit.com/r/programming/comments/fzwlh/for_c_pro... ]

corysama 16y ago
This example becomes much stronger when you have more than one rasterize function. Writing 3 separate functions for 3 pixel types is reasonable. Writing 9 functions for 3 pixel types * 3 rasterization styles is repetitive and error-prone. Writing 27 separate functions because you added 3 blend modes is very, very bad. At that point in C, you either start writing "creative" preprocessor macros, write a custom code generator or give up and eat the performance penalty of the run-time solution. A rasterization function needs to perform on the order of 1024x768x30 calls per second on the low end. Compared to inlinable static function calls, function pointer overhead becomes a big deal at that scale. "Creative" template abuse can be much worse than "creative" preprocessor abuse. However, elegant application of templates, such as policy-based design, can solve code permutation situations without repetition or performance problems.