Re: With Concepts, it seems a truly heterogeneous container is almost there, but...
pongba@gmail.com wrote:
See if this would be cool had it been true:
concept WithText<typename T>
{
void text(std::string const&);
std::string const& text() const;
};
You are talking about "auto concept", the concept that automatically
applied to any type:
auto concept WithText<typename T>
{
void T::text(std::string const&);
std::string const& T::text() const;
};
Lourens Veen wrote:
The thing is, if you want to do what you want to do, then you have to
keep the type information around for the objects. C++ has a way to do
that, and it's through an abstract base class, pointers to base, and
overloaded virtual member functions.
Problem is, though, you're talking about implementing this in current
C++(via a traditional OOP way which is bounded as opposed to the
unbounded polymorphism provided by templates), while I'm thinking about
the new possibilities Concepts opened.
The possibility is already opened for template code:
template <class T>
void f(vector<T>& vec) { // vector<T> is a heterogeneous container
T& x = vec.front();
x.text("what is it for?"); // access unknown type T
}
With concept "WithText", the things remain the same:
template <WithText T>
void f(vector<T>& vec) {
T& x = vec.front();
x.text("what is it for?");
}
When you are in template code, you deal with heterogeneous types,
otherwise your types are strict. This will not change. Concepts
are unrelated to your intent, because they are intended to further
restrict template programming.
I mean, sure, we *should* and *could* achieve the goal using abstract
class and inheritance, which is the easiest way to go.
However, using abstract class and inheritance this way will highly
constrain the power(e.g. existent classes which actually have but don't
implement the interface can't be stored in the container).
The essence of duck typing(in C++, Structral Conformance) is "if it
waddles like a duck, and quacks like a duck, then it is a duck",
In other words, if it looks like a plug, it could be inserted into
socket. Two fingers are like a plug, so you want to be able to insert
them into 220V socket.
in
other words, we don't need a class to implement the interface, instead,
we just need it to *look like* it has the interface, which GP is all(
well, almost) about (i.e. the unbounded polymorphisms).
And I doubt it should be that. For example:
class Lottery {
void draw();
};
class Shape {
void draw();
};
auto concept Drawable<T> {
void T::draw();
};
template <Drawable T> // matches both Lottery and Shape
void f(T t) {
t.draw(); // what kind of "draw"?
}
This case is a homonymy error, which "auto concepts" is all about.
Further more, Bjarne Stroustrup in one of his proposal about Concepts
said that it *is* possible to implement a separate compilation model
via Concept, using some kind of vtable. I know what he means, here
Concept can serve as the *unbounded interface*, which could mean that
every type that satisfy a particular concept actually *implements* the
interface postulated by the concept.
The meaning of "separate compilation" could be quite different.
Probably, he didn't mean what you mean.
The biggest downside of using abstract class and inheritance to
approaching a heterogeneous container is that it's bounded, and the
power limited, for example, someone would implement a class that
satisfies the interface( in that it has all(or even partial) of the
methods required by the interface) while doesn't derive
from(implements) the interface at all. With the OOP way, you have to
make the class implement some (maybe)occasional interface in order to
put it in the container, but with Concepts, it opened another gate for
a completely type-safe and unbounded solution, where every type, no
matter old or new, changeable or not, could effectively be stored in
it, as long as it is *Structrually conform* to the Concept.
Adapter pattern <http://en.wikipedia.org/wiki/Adapter_pattern>
can force any animal to quack:
class Duck {
public:
virtual void quack() = 0;
};
template <class T>
class DuckAdapter : public Duck {
T t;
public:
DuckAdapter(const T& t = T()) : t(t) {}
void quack() {
t.quack();
}
};
class Frog {
public:
void quack() {
cout << "croak! croak!" << endl;
}
};
vector<Duck*> ducks;
Frog frog;
ducks.push_back(new DuckAdapter<Frog>(frog));
ducks[0]->quack(); // ok: quacking frog is like a duck
--
Andrei Polushin
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]