avoiding boilerplate recursion code - visitors, iterators

[n.torrey.pines]

Hi

I work with a nested tree-like data structure template (that happens
to be a tuple of vectors of tuples of trees of something, with
different tuple elements having different types)

I need to define a variety of ELEMENTWISE operations, like

a. increment all leaves (unary)
b. match two data structures (binary)
c. subtract two operands, write into third (ternary)
d. increment the first operand by a product of second, third and
fourth (quaternary)
... etc.

Because of the complexity of the data structure (it's more than a
simple tree), recursing through the whole thing requires 50 lines of
code.

I'd like to avoid writing this boilerplate code for each operation,
obviously.

If all elements in a given structure had the same type, I could define
iterators for this data structure, which would ease the task.

If all of the operations to be defined were unary, a visitor pattern
of some sort would be useful here (although even then, I would need a
const and non-const versions).

However, neither of these conditions applies. I could implement a
visitor-like pattern for each arity (up to 4), but that's roughly 300
lines of very dull code, ignoring const-ness.

Considering that a quaternary procedure can have 2^4 = 16 const-ness
types, this makes the problem of factoring out the boilerplate
recursion code for any possible elementwise operation even harder
(thousands of lines of code) and pointless.

Any suggestions?

[=?iso-8859-1?q?Kirit_S=E6lensminde?=]

On May 1, 4:54 am, n.torrey.pi...@ gmail.com wrote:

I work with a nested tree-like data structure template (that happens
to be a tuple of vectors of tuples of trees of something, with
different tuple elements having different types)

I need to define a variety of ELEMENTWISE operations, like

a. increment all leaves (unary)
b. match two data structures (binary)
c. subtract two operands, write into third (ternary)
d. increment the first operand by a product of second, third and
fourth (quaternary)
... etc.

[snip]

Considering that a quaternary procedure can have 2^4 = 16 const-ness
types, this makes the problem of factoring out the boilerplate
recursion code for any possible elementwise operation even harder
(thousands of lines of code) and pointless.

Any suggestions?

If you have iterators that can walk the structure then std::transform
should handle the unary case. Taking this idea further it ought to be
possible to build along those lines for what you want.

You will probably also want something like the std::back_inser ter as
well, but that depends on how the structures work.

Take a look at std::bind, boost::bind and boost::lambda:: bind - they
should help you write the transformation functions and apply them
within the transforms.
K

[n.torrey.pines]

On Apr 30, 9:16 pm, Kirit Sælensminde <kirit.saelensm [e-mail]>
wrote:

On May 1, 4:54 am, n.torrey.pi...@ gmail.com wrote:

I work with a nested tree-like data structure template (that happens
to be a tuple of vectors of tuples of trees of something, with
different tuple elements having different types)

I need to define a variety of ELEMENTWISE operations, like

a. increment all leaves (unary)
b. match two data structures (binary)
c. subtract two operands, write into third (ternary)
d. increment the first operand by a product of second, third and
fourth (quaternary)
... etc.

[snip]

Considering that a quaternary procedure can have 2^4 = 16 const-ness
types, this makes the problem of factoring out the boilerplate
recursion code for any possible elementwise operation even harder
(thousands of lines of code) and pointless.

Any suggestions?

If you have iterators that can walk the structure then std::transform
should handle the unary case. Taking this idea further it ought to be
possible to build along those lines for what you want.

I wrote about iterators (in the part you snipped) :

"If all elements in a given structure had the same type, I could
define
iterators for this data structure, which would ease the task."

IOW, the problem is that *i has different type, depending on where i
is pointing. I'm currently thinking about a kind of discriminated
union (variant) iterator generalization, but that too has its own
downsides, like runtime overhead compared to hand-written code.

[=?iso-8859-1?q?Kirit_S=E6lensminde?=]

On May 2, 1:40 am, n.torrey.pi...@ gmail.com wrote:

On Apr 30, 9:16 pm, Kirit Sælensminde <kirit.saelensm [e-mail]>
wrote:

If you have iterators that can walk the structure then std::transform
should handle the unary case. Taking this idea further it ought to be
possible to build along those lines for what you want.

I wrote about iterators (in the part you snipped) :

Whoops! My reading comprehension often leaves a little something to be
desired :(

>
"If all elements in a given structure had the same type, I could
define
iterators for this data structure, which would ease the task."

IOW, the problem is that *i has different type, depending on where i
is pointing. I'm currently thinking about a kind of discriminated
union (variant) iterator generalization, but that too has its own
downsides, like runtime overhead compared to hand-written code.

Can you wrap the changing iterators into a containing iterator that de-
references to a abstract data type that can have the operations
applied to it? This doesn't mean that the items in the structure need
to be part of the same class hierarchy.

It might be a bit easier to understand if you give a concrete example
of how the items change. You must be able to store the non-homogeneous
data in the structure now. What does part of a structure actually look
like?

I've done something for the O/RM part of FOST.3 which also needs to
iterate over an arbitrary data structure (the classes, their
attributes and nested classes etc.). To do this I wrote a custom
message dispatcher to dynamically match the code with the type (using
reflection/RTTI) and/or attribute name.

In another part of the system we used boost::bind and
boost::lambda:: bind to abstract out arguments and return types for
functions in order to schedule work for execution in separate threads.
K