std.signals and malloc

Robert jfanatiker at gmx.at
Sun Jan 20 03:25:48 PST 2013


Of course. Just at the moment issue:
http://d.puremagic.com/issues/show_bug.cgi?id=8441

is holding it back.

It will be probably named std.signals2 or something to maintain
backwards compatibility, but yeah I definitely want to get it into
phobos. In fact, I don't even have a use for it in my own projects, I
just saw the current implementation and thought there must be a better
way. So the whole point of implementing it, was to get it into phobos.

I strongly encourage you to use my implementation, because real world
testing before becoming a part of the standard library is always a good
idea. But keep in mind, that it wasn't formally reviewed yet so your
code might break, when being included into phobos. (Stuff might get
renamed for example.) On the other hand fixing this issues should not be
too much work. So yeah, please try it out, so it will be perfect when
included. The feature set and set of improvements, should be convincing
anyway, if not I have done something wrong.

As said before, you will have to remove the template mixin at the
beginning, (because of the above mentioned bug) and use the struct
FullSignal directly.

The split up in FullSignal and RestrictedSignal, was to be able to
disallow others from emitting the signal.

I would be glad to answer any questions about its use and improve
documentation where necessary.

Best regards,

Robert

On Sat, 2013-01-19 at 22:47 +0100, David wrote:
> Am 19.01.2013 19:39, schrieb eskimo:
> > The new implementation offers this possibility, with the strongConnect()
> > method. The old implementation wasn't able to do so, because a delegate
> > contains no type information about the context.
> > 
> Any plans of getting this into Phobos as a std.signals replacement?
> Otherwise using it doesn't make too much sense. (a class is the lesser
> of the two evils)




More information about the Digitalmars-d mailing list