[M3devel] "target specific pragmas"?

[Tony Hosking]

PS The C++ standard committee is actively developing the next C++  
standard to include garbage collection as part of the spec.

The worm has turned...

On Feb 14, 2008, at 1:59 PM, hendrik at topoi.pooq.com wrote:

> 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