Darren New <dne### [at] sanrrcom> wrote:
> http://yosefk.com/c++fqa/index.html

  There are some valid points (which are well known among most C++
programmers), some minor issues which are artificially exaggerated to
look much worse than they really are, and also some completely unfounded
claims (bashing just for the sake of bashing).

  What always bothers me with all these C++ rants is the generalizations.

  I agree: If you are, let's say for example, a C++ expert and a C# expert
and you are writing a program which doesn't need to care so much about
memory usage, then by all means go ahead and use C#. There are plenty of
such programs and it isn't such a big deal. In these memory usage is not
an issue at all. The safety benefits of C# are well worth it.

  However, these ranters go ahead and generalize that this is the case
with *all* possible programs. You should *always* use C# instead of C++,
no matter what kind of program you are writing. Current computers have
multi-gigabyte RAMs, so who cares?

  Somehow they just don't seem to grasp the concept that there are programs
which need to handle humongous amounts of data, and they must do it very
efficienty (both memorywise and speedwise).

  A few of these anti-C++ advocates will then argument that if what you
need is extreme memory usage efficiency, then you should use C, not C++
(that webpage has a few comments of that type too). This is absolutely
ridiculous, and just a bashing C++ for the sake of bashing mentality.

  In their religious hatred of C++ they will completely refuse to admit
any advantage things like C++ classes and templates provide over C. They
will jump through any amount of hoops just to make C++ sound bad, even
if it means making completely ridiculous claims in the line of "C is in
all ways better than C++".

  What I like about C++ is that it provides strong tools for creating
very abstract code which is very memory-efficient at the same time.

  For example, if I want to create a class named "Pixel" which has a
nice public interface (and with its actual implementation hidden), and
with all kinds of commodity functionalities, I can do so. Yet I can do
so in a way that lets me create, for example, an array of 1000000 such
Pixels which only requires, for example, 4000000 bytes of memory (4 bytes
per pixel) and nothing more.

  I can even create several types of pixels (for example varying in number
of color components and bits per color component), each one with the same
interface. I can create functions which take "anything that looks like a
Pixel" (ie. implements certain public functions) and do something to it.
All this still requiring just a minimum amount of bytes per pixel. If I don't
need, for example, dynamic binding, then no memory is needlessly wasted in
a useless virtual table pointer. Also memory is not needlessly wasted in
ancillary memory allocation data, keeping the memory usage still at 4 bytes
per pixel (or whatever the actual amount of data in the pixel is).

  Another good example is what I did in a job project years ago. Memory
usage efficiency was an absolute must, and every single bit saved was
important (even one single bit saved per element could mean that some
tens of millions of graph nodes more could be calculated).
  I had a class which acted like a vector of integers, thus requiring
32 bits per element. In many cases, though, the range of integer values
stored in the vector was much smaller than that, and thus many of those
bits were wasted. I re-implemented the this class so that it would only
store as many bits as necessary for each element. This meant that if,
for example, the integers stored in this vector had value ranges between
0 and 100000, only 17 bits were allocated for each element, producing a
saving of 46% in memory usage. This meant that, roughly speaking, the
processing capacity of the program almost doubled in this case (ie. almost
twice as large graphs could be processed).
  Yet the class still looked and acted like a regular vector and was still
exactly as easy to use.

  As far as I can see this is the reason why so many "high-level" languages
still provide such "low-level" features as byte arrays. Their problem is
usually that you can't create abstract classes which would represent each
element. For example, you can't create a "Pixel" class with a nice public
interface and then store instances of this class in such a byte array in
a way that it will only require eg. 4 bytes or less.

  So in many "high-level" languages it's a tradeoff between abstraction
and memory usage. You can't have both at the same time. In C++, to a
relatively large extent, you can. That's what I like about C++.

  Sure, there's no garbage collection and you can write out of string
boundaries. Quite bad, sure, but I can live with that. I don't even
remember the last time I had a bug related to that.

-- 
                                                          - Warp

Post a reply to this message