Re: Preventing type extensions

[Florian Weimer <fw@deneb.enyo.de>]

* Dmitry A. Kazakov:

> On Wed, 22 Sep 2010 21:51:16 +0200, Florian Weimer wrote:

>> It's hard to beat the C++ type system in terms of expressiveness.
>
> As someone designing component libraries for both Ada and C++ I would say
> that the C++'s type system is far behind Ada. Though C++ has some
> substantial and evident advantages over Ada, e.g. proper constructors,
> proper MI, partial inheritance from concrete types, that does not pay off,
> because the rest is too bad.
>
> At least to me, it is impossible to achieve consistency and clearness of
> design any close to what can be done in Ada. Looking at C++ class libraries
> designed by other people assures me that I am not alone.

I don't doubt that this has been your experience, but this in no way
contradicts that the C++ type system is way more expressive than
Ada's.  It's probably the other way round: C++ is too expressive, and
it is difficult to find the right amount of type-level programming.

>>> Hey, just a wild idea: how about
>>>
>>> type T_Stack_Access is access aliased T;
>>>
>>> which indicates that access values of this type can *only* designate
>>> aliased objects that are on the stack, and never on the heap?
>> 
>> I don't think this would provide useful information.  Tasks blur the
>> boundary between heap and stack allocation.
>
> Stack/heap allocation refer to a memory management policy rather than
> physical location. This boundary is very sharp: the stack policy presumes
> two important constraints: 1. LIFO ordering, 2. Ownership by the task.

Neither is true if you can create tasks dynamically.  Instead of using
an allocator, you just wrap the object to be created in a task, where
you put it on the stack.  In effect, you have bypassed both
constraints (because the owner is not you, but some other task).