the const correctness of the this pointer

Sönke Ludwig ludwig_nospam at informatik.uni-luebeck.de
Mon Dec 28 12:18:21 PST 2009


Am 28.12.2009 18:44, schrieb Denis Koroskin:
> On Mon, 28 Dec 2009 03:02:23 +0300, TM <ithink at therefore.iam> wrote:
>
>> Hello,
>> I was dealing with delegates when I found that the const correctness
>> of the this pointer was 'lost' when accessing a member function of a
>> class through a temporary delegate.
>>
>> Here is an example:
>>
>> class A{
>> void f () {}
>> }
>>
>> const A a = new A;
>> a.f() //error, this is normal.
>> auto g = &a.f;
>> g(); //no error. Is this normal ?
>>
>> I may be wrong, but it seems to me that as the const property of the
>> this pointer is linked to the instance of the class (here 'a'), the
>> delegate 'g' should contain a const pointer to A (because 'a' is const).
>>
>> More generally, I seems that there is no management of the const
>> correctness of the frame pointer of a delegate in D2
>>
>> What about adding the const keyword for delegates, as we do for
>> methods ? The const property of the delegate's frame pointer would be
>> part of its type.
>>
>> Example:
>>
>> void f()
>> {
>> int x;
>> void g() const {
>> x ++; //would produce an error since the type of g is [void delegate()
>> const]
>> }
>> }
>>
>> Any thoughts about this ?
>
> It shouldn't compile: it makes no sense to can't non-const method
> through const reference, and the same applies to shared. OTOH, the
> following should just work:
>
> class A {
> void constMethod() const {}
> void sharedMethod() shared {}
> }
>
> const A a1 = new A();
> void delegate() const dg1 = &a1.constMethod;
>
> shared A a2 = new shared A();
> void delegate() shared dg2 = &a2.sharedMethod();
>
> (in examples above, const and shared attributes are applied to both
> function pointer and frame pointer)
>
> I already wrote about a necessity of introduction of "shared delegates"
> in a separate thread. Until then, Thread creation is broken in D.

Actually in both cases the error is not happening when the delegate is 
called but at the point where the delegate is created. _Creating_ a 
delegate to a non-const function should simply be impossible when a 
const object is bound (result in a compile time error). Similarily, for 
a shared object, the necessary synchronization code should be added to 
the delegate instead of having the shared attribute attached to the 
delegate.

Typing the delegate will just create superfluous type combinations and 
complicate delegate usage - additionally it would be strange in the 
sense that it makes assumptions about the type of the "context pointer" 
without knowing what it is (object, stack frame, struct, ...).

Sönke



More information about the Digitalmars-d mailing list