avoiding boilerplate recursion code - visitors, iterators

Discussion in 'C++' started by n.torrey.pines@gmail.com, Apr 30, 2007.

  1. Guest

    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?
     
    , Apr 30, 2007
    #1
    1. Advertising

  2. On May 1, 4:54 am, 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_inserter 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
     
    =?iso-8859-1?q?Kirit_S=E6lensminde?=, May 1, 2007
    #2
    1. Advertising

  3. Guest

    On Apr 30, 9:16 pm, Kirit Sælensminde <>
    wrote:
    > On May 1, 4:54 am, 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.
     
    , May 1, 2007
    #3
  4. On May 2, 1:40 am, wrote:
    > On Apr 30, 9:16 pm, Kirit Sælensminde <>
    > 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
     
    =?iso-8859-1?q?Kirit_S=E6lensminde?=, May 2, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dwok
    Replies:
    2
    Views:
    491
    Lucas Tam
    May 11, 2005
  2. Ralf W. Grosse-Kunstleve
    Replies:
    16
    Views:
    620
    Lonnie Princehouse
    Jul 11, 2005
  3. Ralf W. Grosse-Kunstleve
    Replies:
    18
    Views:
    620
    Bengt Richter
    Jul 11, 2005
  4. Ralf W. Grosse-Kunstleve
    Replies:
    2
    Views:
    427
    Dan Sommers
    Jul 12, 2005
  5. meltedown
    Replies:
    9
    Views:
    1,054
    Steve Pugh
    Oct 17, 2006
Loading...

Share This Page