Jim Sievert <jas1@rsvl.unisys.com> wrote:
>I've been struggling to use C++ generic programming to define a collection
>of classes that work polymorphically but are of different types.  I've
>finally convinced myself that it can't be done.  I'm wondering if such a
>concept could be a future language enhancement.

This can be done using what Coplien calls the "envelope-and-letter"
paradigm.  Basically you derive all the different classes (or template
class instances) from a single base class, and you use a wrapper
class which contains a pointer or reference to this base class.
The wrapper class must delegate all operations to virtual functions
in the base class, which then dispatch to the appropriate function
in the given derived class.

>Basically what I'd like is the concept of a template class that doesn't
>change type when it's been instanciated so that I can collect them into
>various types of collections (arrays, vectors, etc.).
>
>I realize that I can derive the template class from a base class and use
>virtual functions to accomplish the same thing.  I'm trying to avoid the
>use of virtual functions.

Why?

You're going to need run-time dispatch, so virtual functions seem
like the obvious thing to use.

>Consider the following class:
>
>template< class T >
>class CFoo
>{
>public:
>   CFoo( T p ) : m_p( p ) {}
>
>   template< class C >
>      bool operator ==( C to ) { return to == m_p; }
>
>private:
>   T m_p;
>};
>
>I'd like to be able to have a single vector that can contain CFoo< int >,
>CFoo< CBar >, etc.  With such an ability, I could iterate over the vector
>evaluating operator ==().  Again, I realize that making operator ==()
>virtual from a base class would work, but I think it's overkill in that the
>address of operator ==() can be evaluated at compile-time.

You lost me here.  If the single vector contains both CFoo<int> and
CFoo<CBar>, then there are at least two operator ==() functions involved.
I don't see how a compiler could figure out at compile time
which one to use when iterating over a vector whose elements
could be of either type.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

[Since this discution is about using C++, I redirect
followups to comp.lang.c++.moderated]

Jim Sievert <jas1@rsvl.unisys.com> writes _not litterally_:

My summary> I've been struggling to use C++ to have polymorphic
My summary> classes. I'm trying to avoid polymorphism. I've
My summary> finally convinced myself that it can't be done.

You are correct: C++ won't let you use polymorphism without
using polymorphism. This flaw was there from the very beginning.
Actually it's worse than that: it's hard to use C++ when you
are trying to avoid using C++.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Fergus Henderson <fjh@cs.mu.oz.au> wrote in article
<fjh-980113-023744@cs.mu.oz.au>...
> Jim Sievert <jas1@rsvl.unisys.com> wrote:
>
> Why?

I've been doing some work with STL lately.  From what I've read, STL is
touted for its ability to generalize type-related expressions and
algorithms.  In much of STL, this generalization is done with no virtual
functions.  Compilers are then able to reduce these expressions and
algorithms into very tight code.  When possible, we've used STL-like
techniques for solving various problems.  The resulting code is highly
optimized.

I'd like to apply the same ideas of generic programming across collections
of different object types.

>
> You're going to need run-time dispatch, so virtual functions seem
> like the obvious thing to use.
>

I'm not so sure...

> >Consider the following class:
> >
> >template< class T >
> >class CFoo
> >{
> >public:
> >   CFoo( T p ) : m_p( p ) {}
> >
> >   template< class C >
> >      bool operator ==( C to ) { return to == m_p; }
> >
> >private:
> >   T m_p;
> >};
> >
>
> You lost me here.  If the single vector contains both CFoo<int> and
> CFoo<CBar>, then there are at least two operator ==() functions involved.
> I don't see how a compiler could figure out at compile time
> which one to use when iterating over a vector whose elements
> could be of either type.

Let me change the example slightly:

template< class T >
class CFoo
{
public:
   CFoo( T p ) : m_p( p ) {}

    bool operator ==( CBarBar to ) { return to == m_p; }

private:
   T m_p;
};

For all instances of the CFoo template, operator ==() is at a fixed offset.
 For example, with CFoo< int > and CFoo< CBar >, operator ==() is always at
offset 0.  Therefore, iterating over a vector with instances of CFoo< int >
and CFoo< CBar > would imply invoking offset 0 with a given CBarBar
parameter.

The original example code forces the compiler to create a fixed set of
offsets for all CFoo template instances where only some of those offsets
are valid for a particular instance of CFoo.  This may get messy?



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Fergus Henderson <fjh@cs.mu.oz.au> wrote in article
<fjh-980113-023744@cs.mu.oz.au>...
> Jim Sievert <jas1@rsvl.unisys.com> wrote:
>
> Why?

I've been doing some work with STL lately.  From what I've read, STL is
touted for its ability to generalize type-related expressions and
algorithms.  In much of STL, this generalization is done with no virtual
functions.  Compilers are then able to reduce these expressions and
algorithms into very tight code.  When possible, we've used STL-like
techniques for solving various problems.  The resulting code is highly
optimized.

I'd like to apply the same ideas of generic programming across
collections
of different object types.

>
> You're going to need run-time dispatch, so virtual functions seem
> like the obvious thing to use.
>

I'm not so sure...

> >Consider the following class:
> >
> >template< class T >
> >class CFoo
> >{
> >public:
> >   CFoo( T p ) : m_p( p ) {}
> >
> >   template< class C >
> >      bool operator ==( C to ) { return to == m_p; }
> >
> >private:
> >   T m_p;
> >};
> >
>
> You lost me here.  If the single vector contains both CFoo<int> and
> CFoo<CBar>, then there are at least two operator ==() functions
involved.
> I don't see how a compiler could figure out at compile time
> which one to use when iterating over a vector whose elements
> could be of either type.

Let me change the example slightly:

template< class T >
class CFoo
{
public:
   CFoo( T p ) : m_p( p ) {}

    bool operator ==( CBarBar to ) { return to == m_p; }

private:
   T m_p;
};

For all instances of the CFoo template, operator ==() is at a fixed
offset.
 For example, with CFoo< int > and CFoo< CBar >, operator ==() is always
at
offset 0.  Therefore, iterating over a vector with instances of CFoo<
int >
and CFoo< CBar > would imply invoking offset 0 with a given CBarBar
parameter.

The original example code forces the compiler to create a fixed set of
offsets for all CFoo template instances where only some of those offsets
are valid for a particular instance of CFoo.  This may get messy?
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

I've been struggling to use C++ generic programming to define a collection
of classes that work polymorphically but are of different types.  I've
finally convinced myself that it can't be done.  I'm wondering if such a
concept could be a future language enhancement.

Basically what I'd like is the concept of a template class that doesn't
change type when it's been instanciated so that I can collect them into
various types of collections (arrays, vectors, etc.).

I realize that I can derive the template class from a base class and use
virtual functions to accomplish the same thing.  I'm trying to avoid the
use of virtual functions.

Consider the following class:

template< class T >
class CFoo
{
public:
   CFoo( T p ) : m_p( p ) {}

   template< class C >
      bool operator ==( C to ) { return to == m_p; }

private:
   T m_p;
};

I'd like to be able to have a single vector that can contain CFoo< int >,
CFoo< CBar >, etc.  With such an ability, I could iterate over the vector
evaluating operator ==().  Again, I realize that making operator ==()
virtual from a base class would work, but I think it's overkill in that the
address of operator ==() can be evaluated at compile-time.

Any feedback would be appreciated.

Thanks.



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]