Re: C++ Template Overloading
on Mon Apr 23 2007, Emerson <emerson.clarke-AT-gmail.com> wrote:
Doug Gregor wrote:
There's nothing to "buy" with parametric polymorphism. It's a way of
expressing polymorphism, and it has various pros and cons relative to
subtype polymorphism, which is used by object-oriented languages, or F-
bounded polymorphism, which is used by the generics features of Java
and C#.
I understand the idea behind the expression, i was really just trying
to say that i don't equate templating with polymorphism in an OO
sense.
Nor should you; it's different. That said, the term "polymorphism"
wasn't invented for OO, so the idea of "parametric polymorphism"
shouldn't be judged in terms of "dynamic polymorphism" as some sort of
fundamental truth.
Templates give you types which can be composed in many
different ways, but this is far from the concept of OO polymorphism
where derived types share a relationship. Without notions like
concepts in the C++0x standard templates dont really share any
relationship with other templates.
Concepts as a notion exist in the C++98 standard. They're just
realized as a language feature in C++0x.
Also, they don't establish relationships among templates, but among
types, such as int and long (each is Integral) and int* and
std::list<int>::iterator (each is a ForwardIterator).
They can't be used as interfaces,
Depends what you mean by "used as interfaces"
and they can't be passed as polymorhpic arguments (in the OO sense)
except in other templates.
No, not templates (e.g. std::vector), but that's probably not what you
meant. Class template specializations (e.g. std::vector<int>)
certainly can be passed as polymorphic arguments.
There is a distinct boundary between templates and OO,
it can be difficult to see and even harder to cross.
Not really; see Andrei Alexandrescu's "Modern C++ Design." It's all
about applying templates to classic OO design patterns.
It addresses many of the problems with the STL/Boost metaphor
I doubt you mean "metaphor" (metaphor for what?). You probably meant
"paradigm," right?
Anyway, I wish you would stop using the "STL/Boost whatever" phrase.
STL has one main paradigm which predates Boost by many years. Boost
is a collection of libraries with many paradigms, but of course since
STL is part of the standard library it's advantageous to use its
paradigms whenever possible. The STL paradigm in no way belongs to
Boost. Boost doesn't deserve credit for it, and also isn't hamstrung
by it.
and the use of type traits. Specifically, most STL and Boost
templates use typedefs like value_type to get around the fact that
the types are unknown. Personally, i dont much like that. I find
it too opaque, which is why if you look in the Reason::Structure
namespace of the framework which i wrote you will find that most
collections return actual types
I don't see how your framework could be less opaque, especially when
the language used to describe it is so vague. In what sense can
collections "return actual types?" Generally, one can only return
objects, which themselves have type.
which are always known i.e. Iterand<int> for any collection working
with "int" and likewise iterators are always of some type
STL iterators are always "of some type" as well. Every object in C++
has a type.
and can be passed and constrained as arguments i.e. Iterator<int>
That's a well-known approach (see boost/tr1::function). It has some
advantages, but also has costs. Buying wholesale into the use of
dynamic polymorphism will make some code prohibitively expensive. The
brilliance of the STL is in the fact that it generalizes the domain of
sequence processing *without loss of efficiency*.
But remember that concepts are fixing problems that exist with the STL/
Boost metaphor.
What's your point?
They will be very useful to other metaphors too so
long as they are not constructed in a STL/Boost specific way. When
looking at examples like the "foreach" loop, things start to get a
little bit too specific, especially if "foreach" is defined in terms
of concepts which support begin() and end(). Thats blurring the lines
between language and library...
Too late. See std::typeinfo
It can be quite difficult to conceptualise how the operator
overloading used in STL/Boost is both a blessing and a curse. Its a
blessing becuase operators provide a way to effectively expression
"anonymous" interfaces in C++.
As I mentioned earlier, operators have absolutely nothing to do with
it. They're merely a different syntax for function calls.
All types support operators,
Really? Hmm...
struct x {};
typedef void y;
but you dont have to explicitly say that a type inherits from
interfaces like "LessThanComparable", "GreaterThanComparable",
"EqualsComparable".
What's your point?
The curse is that in exchange for that magic
What magic?
you have to trade all your knowledge of the type that you are
working with and you can no longer easily integrate your templates
with OO programming models.
Sorry, you lost me here.
In the Reason framework i tried very hard to find an alternative which
gave me better association with OO priciples, yet still had the
anonymous power of the STL/Boost metaphor.
The solution can be seen
in the classes Template<Kind>, Type<Kind> and in interfaces like
Comparable<Kind> and Disposable<Kind>. In Reason there is no
requirement for type traits, becuase types are transparent, likewise
the code is simpler and more easily understood.
Or, looking at it differently, types are erased behind an opaque
barrier of dynamic polymorphism, costing the ability to perform
important optimizations, resulting in much larger code when used on
fine-grained concepts
(http://groups.google.com/group/comp.lang.c++.moderated/msg/82674634c2a6b3a0?hl=en&),
and ultimately requiring error-prone and complicated type switching to
handle the binary method problem.
There are upsides and downsides to every approach.
Comparable<Kind> provides a mapping between the anonymous operators
and OO interfaces like those provided by the Object class. By
avoiding heavy reliance on the STL/Boost operator metaphor, i was
able to avoid some of the associated traps. Even the templates that
exist in Reason are very OO. They are fundamentally inheritable
becuase they are closer to being classes than they are to being
generics.
You're conflating two very different things. Classes are classes;
templates are templates. Function templates have nothing to do with
classes. Class templates, when instantiated, produce classes.
There's no way in which one class template can be "closer to being a
class" than another.
Too me, polymorphism is too closely linked with the notion of
inheritance
Much too closely.
C++ is a multi-paradigm language, and one of those paradigms is object-
oriented programming.
Ok. I think i was just trying to say that generic programming is a
relatively new focus for the language though.
8 years since standardization (not to mention a few years before that)
is not all that new.
Templates initially im sure were merely an advanced macro mechanism
for avoiding code duplication.
Bjarne Stroustrup would tell you otherwise.
And by the way, just becuase generic programming is popular with a
subset of C++ users does not make it necessarily important.
True. Generic programming is important because of what it can do.
There has always been a tendancy for programmers to gravitate
towards what is new and exciting, and even sometimes complicated.
Im not sure i really understand the psychology, but non the less, it
is a phenomenon. And it goes without saying that sometimes creating
simpler things is actually far more difficult than creating complex
things.
This sounds a bit patronizing. Do you suppose it's possible that this
happens just as often with OO as with GP?
True generics, in an asbtract algorithmic sense is a software
development holy grail.
See STL. Have you ever read or listened to Stepanov's discussion of
his work?
However i havnt found many examples where all my code needs to be
generic. Im sure there are examples where generic libraries truly
benefit from being generic, but i think there are a lot of generic
libraries which are only generic becuase the authors are stuck on
the STL/Boost metaphor and cant get off it (see the comment above
about carpenters and nails).
And I'm sure very little code "is OO" the authors are "stuck on the OO
metaphor and can't get off of it."
Do you think OO is a fundamentally good and proper paradigm, and thus
should be the basis for all programming without particular scrutiny,
while other paradigms are probably overused and require special
justification?
This is probably partly due to knowledge, once you know a certain
way of working it becomes easier for you, but also partly due to the
fact that the STL/Boost metaphor is actually hard to break out of
once you start using it because it does not easily blend back in
with the more OO principles of C++.
There are no "OO principles of C++." If you read D&E, you can find
exactly the principles upon which C++ was designed, and none of them
(IIRC) have anything to do with OO. In fact, if you talk to proponents
of some other languages they'll disparage C++ by claiming that it
"isn't truly an object-oriented language".
Furthermore, I challenge your claim (which you have so far made
repeatedly and without any justification) that generic programming
doesn't blend well with OO.
Its kindof a shame to see a language like C++ diverge into class based
programming and generic programming. We should be trying to merge
them back together i think, and hopefully concepts will go a long way
towards doing this...
I don't see how.
For me, the cost of abstraction in generic libraries like GIL (Generic
Image Library) which i happened across the other day, outweigh the
benefits.
I guess Adobe, which sponsored GIL's development, would strongly
disagree with you. As I'm sure you can imagine, Adobe really needs
good image processing abstractions and the highest efficiency, so the
design of GIL was very intentionally chosen, and not just the product
of some sort of addiction to templates.
I like to always see what im dealing with in my code, down to the
point that i would rather use "char" than "typedef char byte"
because abstractions make things harder to understand.
Then why do you use C++? When you program in C++ you're operating at
a higher level of abstraction than you would if you were using 'C' or
assembly language. Most people use C++ because it helps them express
complex ideas more simply, maintainably, and effectively than they
would be able to when working at a lower level of abstraction.
Even Charles Symonyi (See NASA TV) would now agree that abstractions
like the dreaded "hungarian" notation (which he helped to design)
are no longer a good idea.
Except that hungarian notation isn't an abstraction. It is, in fact,
the exact opposite: it breaks abstraction by binding a variable's
actual type into its name and thus exposing implementation details
where they don't belong.
I think the efforts to make things like std::function and std::bind
are admirable, but far from acceptable. I still find it astonishing
that C++ lets you do that kindof stuff, how many other languages out
there have the same kindof loop holes and tricks ?
It's amazing that you're calling boost/tr1::function the product of
loopholes and tricks, considering that it seems to be, fundamentally,
exactly the same thing you're advocating with your "Reason" framework.
I also wonder what kind of loopholes and tricks you think are at play
with boost/tr1::bind. C++ certainly has its share of tricky corners,
but AFAICT none of them are in play in the implementation of
that component.
--
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 ]