Extending Template Classes - Best Practices

Discussion in 'C++' started by Tom, Nov 2, 2011.

  1. Tom

    Tom Guest

    Hi,

    I am trying to understand best practices in extending template container
    classes. Say one has implemented an effecient parameterised tree
    container that does not allow for duplicate values. Let us further
    assume the tree method is parameterised by a single type T and a
    functional C . The functional defines an order relation on the tree and
    is provided a default value say std::less< T >. The tree interface
    supports a minimal interface, providing insert, and remove methods. One
    would now like to implement a parameterised Set container. Let us
    suppose there are two cases here

    - The set supports the same interface - insert/remove but with slightly
    different implementation from the tree

    - The set supports and augmented interface - insert/remove (with no
    change in implementation), and additional methods such as union
    intersection and complement.

    In either case what is the appropriate approach, i.e set composes tree
    or set inherits tree or tree is also parameterised by another type
    (traits ?) that makes it behave as a set alternatively ?

    What would be a good resource (book/website) to learn more about such
    issues in developing parameterised classes and complexities of name
    lookup rules for parameterised class hierarchies.

    regards
    Tom
    Tom, Nov 2, 2011
    #1
    1. Advertising

  2. On 02.11.2011 01:08, Tom wrote:
    > Hi,
    >
    > I am trying to understand best practices in extending template container
    > classes. Say one has implemented an effecient parameterised tree
    > container that does not allow for duplicate values. Let us further
    > assume the tree method is parameterised by a single type T and a
    > functional C . The functional defines an order relation on the tree and
    > is provided a default value say std::less< T>. The tree interface
    > supports a minimal interface, providing insert, and remove methods. One
    > would now like to implement a parameterised Set container. Let us
    > suppose there are two cases here
    >
    > - The set supports the same interface - insert/remove but with slightly
    > different implementation from the tree
    >
    > - The set supports and augmented interface - insert/remove (with no
    > change in implementation), and additional methods such as union
    > intersection and complement.
    >
    > In either case what is the appropriate approach, i.e set composes tree
    > or set inherits tree or tree is also parameterised by another type
    > (traits ?) that makes it behave as a set alternatively ?
    >
    > What would be a good resource (book/website) to learn more about such
    > issues in developing parameterised classes and complexities of name
    > lookup rules for parameterised class hierarchies.


    At the design level a set is different from a tree.

    So the tree stuff should not be publicly available from the set interface.

    In practice containment is generally preferable over private or
    protected inheritance, but whatever works & feels right (e.g.
    convenience) and isn't immediately attacked by code reviewer. :)


    Cheers & hth.,
    Alf P. Steinbach, Nov 2, 2011
    #2
    1. Advertising

  3. Tom

    Jorgen Grahn Guest

    On Wed, 2011-11-02, Tom wrote:
    > Hi,
    >
    > I am trying to understand best practices in extending template container
    > classes. Say one has implemented an effecient parameterised tree
    > container that does not allow for duplicate values. Let us further
    > assume the tree method is parameterised by a single type T and a
    > functional C .

    ....

    > What would be a good resource (book/website) to learn more about such
    > issues in developing parameterised classes and complexities of name
    > lookup rules for parameterised class hierarchies.


    I don't see how your problem relates to templates -- are you sure
    you're not confusing yourself? Step back and think of the two plain
    classes SetOfFoo and TreeOfFoo (for some example type Foo) if you
    notice your head beginning to spin. (That's what I do.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Nov 2, 2011
    #3
    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. karim
    Replies:
    0
    Views:
    441
    karim
    Jul 13, 2003
  2. Craig Deelsnyder

    Best Practices - solution - namespaces - classes

    Craig Deelsnyder, Aug 3, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    424
    Vincent V
    Aug 4, 2003
  3. Janus Knudsen

    Best Practices for System.Net Classes what?

    Janus Knudsen, Jun 26, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    414
    DalePres
    Jun 26, 2004
  4. Miranda Evans

    best practices - how to organize classes

    Miranda Evans, Nov 25, 2003, in forum: Python
    Replies:
    1
    Views:
    335
    Roy Smith
    Nov 25, 2003
  5. John Dalberg
    Replies:
    3
    Views:
    558
    samuelhon
    Nov 16, 2006
Loading...

Share This Page