Re: C++ Template Overloading
on Wed Apr 11 2007, "Emerson" <emerson.clarke-AT-gmail.com> wrote:
I just finished watching a Google tech talk presentation on concepts
in the upcoming C++0x standard and it left me wondering. The
concepts seem like a good idea, but it does concern me that such
metaphore specific notions are making it into the C++ language ahead
of perhaps more basic and useful features.
The metaphore that i refer to is that off iterators.
Concepts are by no means specific to the iterator "metaphor."
Without iterators, STL would not be what it is. Both STL and Boost
are libraries which have been designed around a single idea, the use
of C++ operators to provide non type specific generic algorithms and
containers.
Hmm, C++ operators really have little to do with Generic Programming;
they just happen to be a convenient and expressive syntactic
construct. One could just as easily have implemented the STL so that
everything used function call notation, and it wouldn't have changed
the fundamental concepts. So, no, STL isn't designed around that
idea.
Boost (not one library, but a library collection) certainly has many
libraries that have Generic Programming at their core, but also has
several that are not at all oriented toward GP in the classic sense.
But it means that the algorithms and containers are restricted to
things which behave like pointers.
It means the algorithsm are restricted operating on things that are
*syntactically* pointer-like, but the behavior can be decidedly
un-pointer-like.
C++ operators are convinient becuase they dont require you to
specify types in the definition of your code
Huh? Maybe when you say "operators" you really mean "templates."
and they support primitive types
Certainly you can support primitive types with overloaded functions
just as well.
template <class T>
void some_algo(T x, T y)
{
foo(x + y); // requires "+" be overloaded for T
// when T is user-defined
}
template <class T>
void some_algo2(T x, T y)
{
foo(add(x,y)); // requires "add" be overloaded for T always.
}
which you cannot do directly with interfaces, but it isnt very OO
Well, you're not going to find a lot of sympathy here for the notion
that being "very OO" is always a good thing. Classic OO is good for
some things, but there are a *lot* of jobs to which it is extremely
ill-suited. Just for fun you might look up the "binary method
problem," which OO can't handle without resorting to runtime type
checking.
and no, i dont buy the notion of "parametric polymorphism".
Care to say any more about that, or are you just hanging it out there
like a flag?
The boundary between the opaque and the visible for the user only
occurs when they dereference an iterator, at this point the user must
know the underlying type and the generic metaphore falls away to
expose the details of the implementation.
Huh? No part of that made sense to me. Maybe you should try using a
specific example that shows what you mean.
This is a clever workaround
For what problem?
and it has allowed libraries like Boost and STL to flourish, but it
is not the only way, and it has its drawbacks. For instance, using
the STL metaphore it is not possible to create a function which
takes only an iterator of integers because there is no such thing as
an iterator of integers,
If you mean an "iterator over integers," then of course there is such
a thing. int* is a perfect example. And if your real complaint is
that there is no way for the author of that function to write it so
that its declaration limits the arguments to being iterators over
integers, then that's wrong too. You can do it in an ugly way in C++
today; making such a specification a first-class idiom is one of the
main points of having language support for concepts in C++0x.
the underlying type is hidden.
Underlying type of what?
Iterators deal only with operators, not with types or interfaces.
Iterators certainly deal with types. See value_type, reference,
pointer, ...
Its more like passing around macros, with all of the details being
obscured.
Huh?
So the STL metaphore necessarily does not integrate well with the
underlying C++ type system,
I disagree with that 200%.
and cannot be constrained by overloading or inheritance.
It certainly can be. That would be bad design and needlessly
limiting, but you can do it.
I think we should not forget that C++ was an object oriented
language well before generic programming came about
It was a multiparadigm language (and even had templates) well before
generic programming came about.
and perhaps some of the ideas which generic programming brings with
it are better suited to functional languages.
Stepanov tried the functional languages and they all failed to express
what he was trying to do.
Not that i have anything against generic programming. Its very
useful, so long as you remember not to be the carpenter and treat
every problem as a nail. How many generic libraries actually need
to be generic beyond the 5 combinations of types that they actually
use,
Well, that's a "when did you stop beating your wife?" sort of
question, innit?
as opposed to collections which are truly generic. I mean, since
when does a Socket class benefit form being generic ? ...ive seen
loads of those.
Maybe you should read the docs and rationale here:
http://asio.sourceforge.net/boost-asio-proposal-0.3.6/libs/asio/doc/
and if that doesn't answer your question, ask its author, Christopher
Kohlhoff.
Generic code is unfortunately opaque,
Any coding idiom will look somewhat opaque to those unfamiliar with
it. It's not an absolute.
and whilst it can be amazingly useful, there is a high price to pay
in terms or readability and debugability.
Generic code is no harder to debug than anything else.
So before we take library specific ideas like begin() and end() and
start building for loops and concept maps around them and adding
support for requirements in generic code, can we pause and considder
the alternatives ?
What about ensuring that C++ templates can be overloaded by interfaces
rather than just concrete types ?
template<typename Kind>
class Compare
{
public:
int Compare(Kind left, Kind right) {return left-right;}
}
template<typename Kind>
class Compare<Comparable Kind>
{
public:
int Compare(Kind left, Kind right) {return left.Compare(right);}
}
You can "already" do that in C++0x. I don't see how it's an alternative to
adding support for requirements in generic code. In fact it seems to
rely on that support.
Thats a pretty useful feature when your doing generic programming that
does not use the STL or Boost metaphore and it integrates tightly with
the more OO aspects of C++, overloading and inheritance.
The STL already integrates pretty well with OO code; go ahead and do
the above when you get concept support; it should work just fine.
And how about standardising the representation of function pointers
Not a chance; that's an issue for the platform vendors who specify
their standard ABIs.
so that we can write better even handling and callbacks.
I don't see how that would help.
What about closures and coroutines ? Why do these ideas have to
remain "undefined" whilst we focus on much more esoteric problems.
The glib non-answer is: where were your proposals and proof-of-concept
implementations for those features when some people on the committee
started working on concept support?
To answer a _little_ bit, C++0x will have support for concurrency and
probably for GC. GC is a prerequisite for true closures so we're
making progress in that direction. It's interesting that you're
asking about these features normally associated with functional
programming while suggesting that C++ should be "more OO" and GP
should be in the domain of functional languages.
For every generic programming feature in the C++0x standard, i fear
there will be 10 far more imporant and far more fundamental non
generic features which will be missed. And for all this we have to
wait till the end of the decade. Whoopy do !
Join the committee and do the hard work if you aren't happy with the
direction.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Don't Miss BoostCon 2007! ==> http://www.boostcon.com
---
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]