[M3devel] "target specific pragmas"?

[hendrik at topoi.pooq.com]

On Wed, Feb 13, 2008 at 05:43:13PM -0800, Mika Nystrom wrote:

> Not even C++ has virtual methods in stack-allocated objects does
> it?

To my knowledge (as former C++ implementor), it does.  But such a 
stack-allocated variable is of statically-known actual type, so the 
compiler can statically resolve all virtual methods to the actual 
function implementing them.  And it you pass the address of such an 
object to another function, the other function will handle its virtual 
methods by the usual virtual function lookup.

The only real problem is that it's a bloody disaster if you try to 
free one of them as if it has been dynamically allocated.  But that 
wouldn't be a problem in a garbage-collected language.

> If there's a language that has a lot of arbitrary limitations
> in this area it's C++.  It's kind of funny: if you know Modula-3,
> you start by wondering how C++ implements X, where X is a feature
> you would like but M3 lacks, and then you find that while C++ does
> indeed implement X', that is, X in a restricted sense, it does
> actually not implement X in the full generality you'd like.  And
> for the same reasons that M3 doesn't touch it in the first place.
> Stack-allocated objects are an example of this.  If you want
> stack-allocated data structures, use a RECORD and a PROCEDURE.  That
> will give you almost exactly the same thing that a stack-allocated
> object gives you in C++!

Not quite -- you lose its ability to be considered an inheritor of 
another class.  That's a big loss.

> About C++: do you *really* know C++?  I was reading Stroustrup's
> book a while back and after reading four or five times "if you want
> to try this, ask an experienced colleague first" I gave up in disgust
> on trying to understand C++.

As implementor, I suppose I might be considered an experienced 
colleague.

> There are so many odd little ways you
> can go wrong in C++.

Yup.  That's why I like to avoid using it.

> Sometimes assigning an object to a variable
> causes your program to break in mysterious and horrible ways,
> sometimes...

It should never have allowed those potentially type-violating 
assignments.

> C++ programmers also tend to underestimate how effective
> garbage collection is in simplifying things.  This is different
> from saying "garbage collection helps you avoid memory management
> errors" (because you say "I am a competent C++ programmer, I never
> make memory management errors").  Garbage collection lets you
> structure your code in ways that simply is not possible if you have
> to worry about which part of it is going to allocate and which part
> is going to deallocate memory.

There's code I wouldn't venture to write without built-in garbage 
collection.  C++ throws a sop at the programmer in the form of enabling 
him to core reference-counting in an at least semi-automatic way, but it 
isn't enough.

-- hendrik