Ironclad C++

Timon Gehr timon.gehr at gmx.ch
Sat Aug 3 19:41:14 PDT 2013


On 08/04/2013 04:28 AM, Walter Bright wrote:
> On 8/3/2013 7:08 PM, Timon Gehr wrote:
>> On 08/04/2013 04:06 AM, Walter Bright wrote:
>>> On 8/3/2013 5:49 PM, Timon Gehr wrote:
>>>> On 08/04/2013 01:55 AM, Walter Bright wrote:
>>>>> On 8/3/2013 4:32 PM, bearophile wrote:
>>>>>> The paper explains the various cases: assign from ptr<T> into
>>>>>> lptr<T>,
>>>>>> assign
>>>>>> from lptr<T> into ptr<T>, and assign from lptr<T> into lptr<T>.
>>>>>>
>>>>>> So with a mix of run-time tests and a small amount of static analysis
>>>>>> the code
>>>>>> is safe and fast enough. It seems a simple enough idea.
>>>>>
>>>>> The problem with different pointer types is, of course, what do you do
>>>>> with functions that take pointers as arguments?
>>>>>
>>>>
>>>> Why would that be a problem?
>>>
>>> Consider the canonical example:
>>>
>>>      void* foo(void *p) { return p; }
>>>
>>> Do you write an overload for each kind of pointer?
>>
>> No, you use lptr<void> because it is the most specialized type that
>> works.
>
> Then the pointer coming out is more specialized than the pointer that
> went in?

Yes, but as far as I understood it you can assign lptr<void> back to 
ptr<void> implicitly by paying for a runtime check. It's what D will be 
doing with T* <-> ref T, right?

(The general problem is easily addressed at the type system level using 
some kind of parametric polymorphism, but they don't do that. D's inout 
is a somewhat failed attempt that gets quite close to solving the issue 
for the mutability qualifiers.)


More information about the Digitalmars-d mailing list