> > > I never had any aha moments...C++ was always a
> struggle
> > > for me...an endless chase of pointers, analysis of
> > > crashes, and things like that!
>
> > Absorb RAII and the struggle will go away.
>
> OMG. I went and looked up RAII and was [hardly?] surprised
> to see that it is nothing but "clean up in a destructor".
> Wow, that was a waste of a half hour of reading.
>
> The problem in large-scale C++ wasn't cleaning up stuff in
> a destructor, it was knowing when you could (and when you
> had to) destroy things. Modern platforms (i.e. what we've
> been using for the past 10 years) automatically handle
> this for us perfectly -- in most cases.

And so can C++, but it seems from your posting it may be a while since you've looked at C++, and therefore may judge it based on how it was 10 or more years ago. Things have changed a lot since then. It would be similar to judging today's Java against your experience with Java 1.0.

If you're referring to garbage collection, then (unless you count things like reference-counting - which C++ is perfectly able to handle - as garbage collection), then they don't - ever - destroy things... Finalisers? Forget it; they are not guaranteed to run, ever, and even if they were, it's nothing much useful they could do.

People who confuse lifetime management from memory management, and thinks GC handles it all, is in for a rude awakening... GC only handles the latter, and not necessarily being the best way of doing it. In other words, GC only handles memory. For a lot of other resources (such as file handles, graphical contexts, etc.), you need to manage their lifetimes, as well, and GC gives you no help with that. Using RAII, you may handle both, and get deterministic lifetimes, without using ugly try-finally clauses (which really only handles _one_ resource at a time, too).

Besides, as has been said many times, it's perfectly possible to use a garbage collector for C++. However, there are often better ways of doing things.

> > Absorb RAII and the struggle will go away.
>
> OMG. I went and looked up RAII and was [hardly?] surprised
> to see that it is nothing but "clean up in a destructor".
> Wow, that was a waste of a half hour of reading.

You haven't understood RAII. 'Waste' another half hour to get it.

> The problem in large-scale C++ wasn't cleaning up stuff in
> a destructor, it was knowing when you could (and when you
> had to) destroy things. Modern platforms (i.e. what we've
> been using for the past 10 years) automatically handle
> this for us perfectly -- in most cases.

RAII means automatic and deterministic resource management. Compared to Java this saves 99% of all try/catch/finally blocks. Allocation and deallocation of resources (any resources, not just new-ed objects) disappears from the surface level of your code (see: http://www.artima.com/intv/modern3.html ). C++ has one asset, one advantage over newer (modern?) platforms, RAII.

It should be ++C.

C++ is the same result as C, just with a side effect you may not notice till later. Apparently even the designers can't deal with the complexities of the language.

> > > I never had any aha moments...C++ was always a
> struggle
> > > for me...an endless chase of pointers, analysis of
> > > crashes, and things like that!
>
> > Absorb RAII and the struggle will go away.
>
> OMG. I went and looked up RAII and was [hardly?] surprised
> to see that it is nothing but "clean up in a destructor"... [snip]

Actually, it is shocking how much code there is in existence that claims to be C++ code, but uses handles and error codes exclusively. I would guess the idea of RAII is unknown to a large percentage of people who call themselves C++ programmers.

> > > My best Aha! moment wasn't directly related to C++
> > > although it uses it. I realised that programming
> > doesn't
> > > need functions, execution points or any execution
> > control
> > > statements at all. [...] It's
> > a
> > > a 30 year old idea that will probably take another 30
> > > years to come to fruition by the looks of things.
> >
> > This sounds interesting, could you elaborate on it, or
> > give any pointers to where to learn about this idea?
>
> I'm talking about specifying instructions on data and not
> the machine. It can come in any form. Right now, only
> data flow "languages" come close, but not completely. I
> took it for granted. I didn't understand the power that
> this gives.
>
> I don't know where I could give you a link because there's
> nothing out there that fully exploits this power. I'm
> working on a tool for this though.
>
> The simplest way I could describe this is by comparison.
> When we add two numbers, we take for granted that we're
> e asking the computer to do it.
>
> a = b+c;
>
> is actually
>
> a = CPU->Add(b,c);

Well, not really from a functional programming view of things, i.e. "a = b+c" _declares_ that a is the sum of b and c; no instruction about how to do that, or in which order (compared to other things) is given. However, that distinction may not be important in this context.

That's also something like a 30 year old idea.

Indeed, declarative programming (such as functional programming) is recognised as a powerful way of doing things, but like other "paradigms", there may be areas where it may be hard to write something in a purely declarative style.

We have the example in HTML, which is declarative (it only specifies that something is a header, another thing is a paragraph, etc.; nothing about how it's supposed to look (unless you use presentational markup...)). However, for behaviour, JavaScript is typically used, an imperative language, again.

However, recent developments of HTML (XHTML 2.0) aims to take care of 90% or so of what we now use scripting for (validation, calculations, etc.) using declarative constructs.

It seems you're talking about something quite different, though.

> I don't like that. I'd rather specify that b and c should
> be added and sent to a.
>
> (b,c)->ADD->(c).
>
> I found the majority of people think that the two Add
> statements above are the same. They're not even
> equivalent, but that's irrelevant. One is machine
> specific (low level), the other is not.

Regarding the last paragraph: The same can be said for the distinction between imperative and declarative programming: a=b+c is a statement about the relationship between a, b and c, but it _can_ also be viewed as the instruction: "Add b and c, and assign the result to a".

> This seemingly
> small detail in the previous sentence can open up a whole
> new area in the computing industry. Understanding this
> was my AHA! moment.

I see. Hm, you say the variables are _streams_... I still have a little difficulty understanding what is meant by the pseudo-code you gave. How is it different from the FP-interpretation of a=b+c?