View mode: basic / threaded / horizontal-split · Log in · Help
December 28, 2009
Re: the const correctness of the this pointer
On Mon, 28 Dec 2009 15:18:21 -0500, Sönke Ludwig  
<ludwig_nospam@informatik.uni-luebeck.de> wrote:


>
> 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, ...).

I'd agree that the typechecking for const (and immutable) can be done on  
the point of delegate creation, especially since one of the perks of  
delegates is you don't have to tell the compiler what type the context  
pointer is already.  However, shared is a different story, since the  
calling convention is different.

I think we need shared delegates as Denis said.  They would be different  
types than normal delegates.  What you are proposing is that every shared  
function that you wish to take a delegate of has a "wrapper" function also  
implemented which does the shared synchronization and then calls the  
underlying function, just so it looks like a normal delegate.  I'd rather  
see the compiler simply treat shared delegates as different types than  
normal delegates, and insert the synchronization code before calling the  
delegate.  With such delegates, you could easily make a shared delegate  
wrapper type that did exactly what you wanted anyways.

It appears that delegate contravariance isn't required here after all  
(unfortunately), but we definitely need shared delegates.

-Steve
January 02, 2010
Re: the const correctness of the this pointer
Am 28.12.2009 21:46, schrieb Steven Schveighoffer:
> On Mon, 28 Dec 2009 15:18:21 -0500, Sönke Ludwig
> <ludwig_nospam@informatik.uni-luebeck.de> wrote:
>
>
>>
>> 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, ...).
>
> I'd agree that the typechecking for const (and immutable) can be done on
> the point of delegate creation, especially since one of the perks of
> delegates is you don't have to tell the compiler what type the context
> pointer is already. However, shared is a different story, since the
> calling convention is different.
>
> I think we need shared delegates as Denis said. They would be different
> types than normal delegates. What you are proposing is that every shared
> function that you wish to take a delegate of has a "wrapper" function
> also implemented which does the shared synchronization and then calls
> the underlying function, just so it looks like a normal delegate. I'd
> rather see the compiler simply treat shared delegates as different types
> than normal delegates, and insert the synchronization code before
> calling the delegate. With such delegates, you could easily make a
> shared delegate wrapper type that did exactly what you wanted anyways.
>
> It appears that delegate contravariance isn't required here after all
> (unfortunately), but we definitely need shared delegates.
>
> -Steve

I agree on what you say about shared. My thought was just that maybe 
there is actually no place where you would ever declare a function which 
gets a shared delegate, because normally it does not matter for the 
caller on what kind of thing a delegate is called. Seen that way, an 
implicit non-shared wrapper would be a helpful feature for the 99% case. 
Of course, having shared delegates would never hurt (maybe for some 
class internal use?).

Sönke
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home