http://yosefk.com/c++fqa/index.html

A nice bash of the C++ FAQ, naturally bashing C++ as well. Makes a lot 
of good points, methinks, as well as expressing things with some good 
comedic timing and such.

One of my favorite entries:

[25.6] Is there a simple way to visualize all these tradeoffs?

FAQ: Here's a matrix with cute smilies for ya. Just don't apply it naively.

(Cute matrix omitted to avoid copyright problems, as well as cuteness 
problems)

FQA: WARNING: there's no known way to represent common sense in a 
tabular form at the time of writing. Therefore, if you choose to store 
the cute matrix anywhere in your brain, you do it at your own risk.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

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

Warp wrote:
>   Sure, there's no garbage collection and you can write out of string
> boundaries.

You can always override the new and delete operators for a class so that 
garbage collection becomes unnecessary, and while you *can* write out of 
a string boundary in C++, it's not a problem in a well-designed class 
(or in well-designed client code).

Regards,
John

Post a reply to this message

Warp wrote:

> Current computers have multi-gigabyte RAMs, so who cares?

This kind of attitude annoys me too...

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

What I dislike about C++ is its vast complexity. Even you surely won't 
try to claim that C++ is a "simple" language? ;-)

However, surely in anybody's books, abstract + efficient = very good 
thing. I certainly won't argue with that one.

>   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).

Haskell *can* do this - but it needs to become vastly easier.

In Haskell, I can make a list of Bool values where each one takes 
exactly 1 bit of storage (plus some constant overhead for the array 
itself). You use the array just like any other structure, but under the 
surface it's doing bit shifts and so forth for you to extract the bit 
you requested. All lovely and transparent.

The *problem* is... it's unreasonably hard to extend this lovely 
functionality to *new* data types. It's already set up for common 
primitive types like Booleans and integers and characters, but you'll 
have to poke around deep in the innards of the compiler's library source 
code if you want to do the same trick for your own types. It shouldn't 
be like that. But, currently, it is. :-(

>   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++.

It's something that is obviously desirable to have, and it's something 
that's being actively worked on in Haskell. (For example, the recent 
"ByteString" library, which vastly decreases the time and space 
requirements for string processing.) I guess ultimately time will tell...

Post a reply to this message

John VanSickle wrote:
> Warp wrote:
> 
>>   Sure, there's no garbage collection and you can write out of string
>> boundaries.
> 
> 
> You can always override the new and delete operators for a class so that 

OVERLOADING.  I meant OVERLOADING.  I was trying to remember this...

> garbage collection becomes unnecessary, and while you *can* write out of 
> a string boundary in C++, it's not a problem in a well-designed class 
> (or in well-designed client code).
> 
> Regards,
> John

Post a reply to this message

Warp wrote:
>   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?

This guy's ranting wasn't like that.  He repeatedly says "if you don't 
need that performance, use something safe. If you *do* need that 
performance, use C instead of C++. Or at least stay away from the deeply 
flawed parts of C++."

I don't think he disagrees there are such programs. It just looks like 
he disagrees C++ is a good solution for them. Or, more exactly, that the 
flaws and shortcomings in C++ don't make up for the power it gives you 
relative to other languages that have the same performance efficiency.

Me, I'll take C or Ada. :-)

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

That's a keyword in Ada, see. :-) You declare the array "packed" and you 
get that behavior without writing any extra code.

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

Yah. The problem is all the other folks one has to deal with. :-) If 
everything you're doing is nicely self-contained, that's one thing. When 
your job is interfacing half a dozen different things together, you 
can't really trust that there's no buffer overruns and so on.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

John VanSickle wrote:
> You can always override the new and delete operators for a class so that 
> garbage collection becomes unnecessary,

You know, I keep asking for people to show me an example of that, and I 
don't see any examples. :-) They all fall down as soon as you get enough 
complexity in the data structure.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> John VanSickle wrote:
> > You can always override the new and delete operators for a class so that 
> > garbage collection becomes unnecessary,

> You know, I keep asking for people to show me an example of that, and I 
> don't see any examples. :-) They all fall down as soon as you get enough 
> complexity in the data structure.

  The next C++ standard will commit a big sin and will define the concept
of garbage collection in C++. They couldn't resist the hype, I suppose... :P

  Seriously, though, it will actually be a great thing. It will be optional
(ie. GC is not shoved down your throat by force) and even if you use it you
can still destroy things explicitly (eg. because some resource needs to be
freed right now and not tomorrow), and it will obviously not affect the
lifetime of local instances.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> When 
> your job is interfacing half a dozen different things together, you 
> can't really trust that there's no buffer overruns and so on.

  Even though C and C++ are very unsafe languages in that regard, some
tools exist which can catch most of these problems, such as valgrind.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> When 
>> your job is interfacing half a dozen different things together, you 
>> can't really trust that there's no buffer overruns and so on.
> 
>   Even though C and C++ are very unsafe languages in that regard, some
> tools exist which can catch most of these problems, such as valgrind.

Except it's not my code, so I couldn't fix it if I wanted to. :-) And 
valgrind on real-time hardware I/O isn't going to help a whole lot. :-)

But yah, I've used valgrind and one other popular one whose name I don't 
remember? Pforce?

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message