www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - daii - allocator-friendly closures and raii

reply Boris-Barboris <ismailsiege gmail.com> writes:
Hi, I wrote a small library, inspired by atilaneves automem. I 
didn't like some things, especially that smart pointers proxied 
underlying types, also I wanted class upcasting.

https://github.com/Boris-Barboris/daii
https://code.dlang.org/packages/daii

What do you think about the delegate\closure syntax?

https://github.com/Boris-Barboris/daii#delegate

Any ideas and contributions are appreciated.
Jun 23
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 06/23/2017 09:02 PM, Boris-Barboris wrote:
 https://github.com/Boris-Barboris/daii
You've got bad ` trusted`s: https://github.com/Boris-Barboris/daii/blob/3e15429a4000494ce61330fb5adcfc700ec1942c/source/closure.d#L108 `_f` may be unsafe. It can't be trusted. `args` may have unsafe postblits which may be called when calling `_f`. -- https://github.com/Boris-Barboris/daii/blob/0e7a3e60f39be48c269826e75bd775b7cfefe51c/source/refcounted.d#L70 `T` may have an unsafe constructor. Can't trust `Allocator.instance.make!(T)`. Again, `args` may have unsafe postblits. -- https://github.com/Boris-Barboris/daii/blob/0e7a3e60f39be48c269826e75bd775b7cfefe51c/source/refcounted.d#L105 `T` may have an unsafe destructor. Can't trust `allocator.dispose(ptr)`. -- https://github.com/Boris-Barboris/daii/blob/3e15429a4000494ce61330fb5adcfc700ec1942c/source/unique.d Same issues as in refcounted.d.
Jun 23
parent reply Boris-Barboris <ismailsiege gmail.com> writes:
On Friday, 23 June 2017 at 20:13:07 UTC, ag0aep6g wrote:
 You've got bad ` trusted`s:
Ty, I misunderstood the concept. I guess in a code like this it's mostly system anyways, too many indirections to control safety level. I'm probably gonna remove most of the attributes.
Jun 23
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/23/17 4:24 PM, Boris-Barboris wrote:
 On Friday, 23 June 2017 at 20:13:07 UTC, ag0aep6g wrote:
 You've got bad ` trusted`s:
Ty, I misunderstood the concept. I guess in a code like this it's mostly system anyways, too many indirections to control safety level. I'm probably gonna remove most of the attributes.
The best advice is to leave safe and trusted and system out of any templates. safe will be inferred if everything is indeed safe. To prove that it's actually safe, use a safe unittest. For places where things are safe, but the compiler can't prove it, then you pull out the trusted attribute. But be very very careful -- as ag0aep6g says, there are often many hidden calls that can be system, and in those cases you have just broken the guarantee. Only use trusted where you know everything about every type that is used inside the call. -Steve
Jun 23
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 06/23/2017 09:02 PM, Boris-Barboris wrote:
 Hi, I wrote a small library, inspired by atilaneves automem. I didn't
 like some things, especially that smart pointers proxied underlying
 types, also I wanted class upcasting.
 
 https://github.com/Boris-Barboris/daii
 https://code.dlang.org/packages/daii
 
 What do you think about the delegate\closure syntax?
 
 https://github.com/Boris-Barboris/daii#delegate
 
 Any ideas and contributions are appreciated.
Looks interesting, covariance (upcasting) is definitely a feature requirement for an standard rc library. The delegates are interesting. A bit brittle, guess we need some compiler supported lowering to make non-GC allocated delegates cleaner. You could try sth. along the lines of delegate!(sum, "(int v) => sum += v") but that needs a mixin to rebind the lambda's context. -Martin
Jul 10