On 09/04/13 13:42, Joseph Rushton Wakeling wrote:
> On 03/09/13 12:00, Sönke Ludwig wrote:
>> Just a warning: This can still easily crash due to D's struct move semantics.
>> Structs are moved around sometimes without any postblit constructor or
>> destructor being called, so fixing self-references
On 03/09/13 12:00, Sönke Ludwig wrote:
Just a warning: This can still easily crash due to D's struct move semantics.
Structs are moved around sometimes without any postblit constructor or
destructor being called, so fixing self-references like this won't work in
general.
Is the patch to Phobos
On 09/03/13 12:00, Sönke Ludwig wrote:
> Am 02.09.2013 15:39, schrieb Artur Skawina:
>>
>> this(this) { jump.ptr = &this; }
>>
>
> Just a warning: This can still easily crash due to D's struct move semantics.
> Structs are moved around sometimes without any postblit constructor or
> destruc
Am 02.09.2013 15:39, schrieb Artur Skawina:
this(this) { jump.ptr = &this; }
Just a warning: This can still easily crash due to D's struct move
semantics. Structs are moved around sometimes without any postblit
constructor or destructor being called, so fixing self-references like
thi
On 09/02/13 20:21, Joseph Rushton Wakeling wrote:
> On 02/09/13 19:31, Artur Skawina wrote:
>> "Fixing" type system bugs by adding library helpers is not really a good
>> idea. '.funcptr' returning incorrect type (and 'typeof(T.method)' etc)
>> needs to be fixed properly. Until that happens, the al
On 02/09/13 19:31, Artur Skawina wrote:
"Fixing" type system bugs by adding library helpers is not really a good
idea. '.funcptr' returning incorrect type (and 'typeof(T.method)' etc)
needs to be fixed properly. Until that happens, the alternatives are:
a) convention - don't directly access these
On 09/02/13 18:32, Joseph Rushton Wakeling wrote:
> On 02/09/13 17:44, Artur Skawina wrote:
>> The nasty part of that is that the type of .funcptr, hence also of the
>> '_jump' pointer, is bogus. So calling via '_jump' directly can succeed,
>> but do the wrong thing. It's a language issue; one reas
On 02/09/13 17:44, Artur Skawina wrote:
The nasty part of that is that the type of .funcptr, hence also of the
'_jump' pointer, is bogus. So calling via '_jump' directly can succeed,
but do the wrong thing. It's a language issue; one reasonable workaround
would be to define a MemberPtr type, whic
On 09/02/13 17:06, Joseph Rushton Wakeling wrote:
> On 02/09/13 17:02, Artur Skawina wrote:
>> I'm not sure where the delegates are supposed to be defined, the above
>> allows defining then externally. If that is not required and you only
>> need to select them from a set of predefined internal one
On 02/09/13 17:02, Artur Skawina wrote:
I'm not sure where the delegates are supposed to be defined, the above
allows defining then externally. If that is not required and you only
need to select them from a set of predefined internal ones, then you can
use your original code with something like:
On 09/02/13 16:43, Joseph Rushton Wakeling wrote:
>> In this case, there's no need for a delegate, as you do not want
>> to operate on the original object. So you can simply do:
>>
>> //...
>> private void function(ref typeof(this)) _jump;
>> private void jump() { _jump(this); }
>>
>
On 02/09/13 16:18, Artur Skawina wrote:
Requiring captures to be explicit would reduce the chance of such
bugs happening, but also have a significant cost and be a rather
drastic change to the language...
For what it's worth, I'm not advocating for any change in the language. I'm
simply highl
On 09/02/13 15:49, Joseph Rushton Wakeling wrote:
> On 02/09/13 15:39, Artur Skawina wrote:
>> While this may not seem ideal, sometimes you do *not* want to do it
>> (when you need to keep the original context), so there are no obvious
>> alternatives that would handle all cases automagically.
>
>
On 02/09/13 15:39, Artur Skawina wrote:
While this may not seem ideal, sometimes you do *not* want to do it
(when you need to keep the original context), so there are no obvious
alternatives that would handle all cases automagically.
I'm sure there are valid use cases where this behaviour is de
On 09/02/13 00:27, Joseph Rushton Wakeling wrote:
> Hello all,
>
> I came across an interesting little pitfall of delegates recently which I
> thought I'd share.
>
> TL;DR: having reference types as struct members can be dangerous. ;-)
>
> Suppose we have a fairly simple range which is supposed
On 02/09/13 06:41, H. S. Teoh wrote:
Spot the bug. :)
Ouch!! :-)
The first time I ever implemented random sampling was in C, and it was a version
of the same algorithm as in Phobos, but written for the GNU Scientific Library
instead. Most of the complex types in GSL are implemented as point
On Mon, Sep 02, 2013 at 12:27:44AM +0200, Joseph Rushton Wakeling wrote:
> Hello all,
>
> I came across an interesting little pitfall of delegates recently
> which I thought I'd share.
>
> TL;DR: having reference types as struct members can be dangerous. ;-)
Yes.
> Suppose we have a fairly sim
Hello all,
I came across an interesting little pitfall of delegates recently which I
thought I'd share.
TL;DR: having reference types as struct members can be dangerous. ;-)
Suppose we have a fairly simple range which is supposed to count from 0 to some
maximum. The trick is that the count
18 matches
Mail list logo
