
For C programmers that hate C++ - fogus
http://users.softlab.ece.ntua.gr/~ttsiod/cpp.html
======
nkurz
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_pro...](http://www.reddit.com/r/programming/comments/fzwlh/for_c_programmers_that_hate_c/c1jx5ml)
]

~~~
corysama
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.

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

~~~
tree_of_item
Not a rant. Plenty of code, not just talk. And he made a very good point, at
that.

~~~
burgerbrain
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
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
How about: C++ is absurd to parse compared to higher level languages that
address it's _numerous_ flaws, and compared to C.

