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