Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #11183 > unrolled thread

Extending Template Classes - Best Practices

Back to article view | Back to comp.lang.c++

Contents

  Extending Template Classes - Best Practices Tom <no@email.com> - 2011-11-02 00:08 +0000
    Re: Extending Template Classes - Best Practices "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2011-11-02 03:37 +0100
    Re: Extending Template Classes - Best Practices Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-02 06:05 +0000

#11183 — Extending Template Classes - Best Practices

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

[toc] | [next] | [standalone]

#11184

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.,

[toc] | [prev] | [next] | [standalone]

#11186

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   .

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web