Void pointers

ag0aep6g via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Mon May 16 15:28:04 PDT 2016


On 05/16/2016 11:35 PM, Alex wrote:
> Background:
> Say, I have objects of kind E, which operate on structs of kind M. The
> problem: if an action is done on a struct, say M42, there should be also
> some action done on other structs, which have some relation to M42, but
> neither the operating object, nor M42 is aware of them (and the action
> which is required), as this would break encapsulation.
> So, I choosed another approach:
> There are some describing objects, say of kind B and G, which hold a
> specific information (a single property) of all existent M structs.
> These objects know which "neighbors" are also affected in case of some
> action of E on the struct M42 and can perform appropriate actions on
> them, at least on the contained property.
> The problem which is still unsolved:
> objects of kind E operates on structs M randomly. For this goal, they
> have to save the information between their actions, on which structs
> they are interested in, to report the ordinal number to the describing
> objects.
> The saving of ordinal numbers with minimum computational costs (nogc,
> even no construction of iota-structs, etc) is crucial.

I can't say that I understand the setup you describe. But are you sure 
that iota has a higher cost than (ab)using a slice?

I mean, they're pretty much exactly the same: an offset, a length, and 
an increment operation. If inlining doesn't fail, they should perform 
the same, no?

And if iota does perform worse for some reason, I feel like there must 
be a way to implement something that matches the speed of the slice 
without inheriting its ugliness.


More information about the Digitalmars-d-learn mailing list