Re: C++ Template Overloading
On Apr 11, 4:41 pm, "Emerson" <emerson.cla...@gmail.com> wrote:
This is going to be a bit of a rant, but its only becuase im
passionate about software and the state of the industry. We seem to
be ever more focused creating new and esoteric language features when
we should be trying to find ways to combine all languages at some
higher level and solve the fundamental problems of software
development, algorithm reuse, and binary interoperability.
Actually, templates are certainly the most interesting and novative
aspect of C++.
The fact that it is given more work than other 'problems' is proof
that more people are simply more interested with it.
I just finished watching a Google tech talk presentation on concepts
in the upcoming C++0x standard and it left me wondering.
Google is not really known for its modern usage of C++. To me it seems
they use it "the old way".
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.
Concepts, technically, aren't really needed. Similar functionality can
already be achieved by the language as it is.
The whole idea of concepts is to allow simpler code and simpler error
messages.
The metaphore that i refer to is that off iterators. 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.
I certainly wouldn't say that. Especially for boost, which contains
various different things.
The aim STL, as it names says, is to provide templates for data
structures and related algorithms.
I don't see the relation with operators.
"non type specific" is a weird expression, and makes me thing you
misunderstand templates.
With templates, everything is type specific, it's just that it can be
generated for any type. It's not obfuscation.
But it means that the algorithms and containers are
restricted to things which behave like pointers.
Huh? I fail to see the relation.
Are you talking about the fact that the iterator design is purposedly
modeled after pointers?
That's just a question of style, it could have used next(), etc.
C++ operators are
convinient becuase they dont require you to specify types in the
definition of your code
You always need to specify the type of the variable in C++.
(There will be type inference in C++0x though)
and they support primitive types which you
cannot do directly with interfaces, but it isnt very OO
Templates are just what they are, templates. A calibre of a class of
function, that you can instantiate with types or integers to generate
the given class or function.
They have no relation with OO. Which is a good thing, by the way. With
OO and subtyping polymorphism the real type of objects is not known
until runtime, while templates work at compile-time and can use
inference to instantiate themselves in the case of template functions.
and no, i dont
buy the notion of "parametric polymorphism".
It's not whether you buy it or not.
It's a notion that exists, and is heavily demonstrated by statically
typed functional languages such as ML.
Templates offer that kind of functionality for C++.
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.
If you don't know the types of your variables, maybe you shouldn't use
them in the first place.
The type of your iterator contains all the necessary information to
know the type of the derefenced element.
This is a clever workaround
It's not especially new or clever.
and it has allowed libraries like Boost
and STL to flourish, but it is not the only way, and it has its
drawbacks.
The only drawback it that, since it happens at compile-time, it can't
be dynamic.
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, the underlying type
is hidden.
That's absolutely false.
The iterator type contains the information of the type it iterates.
While such an information wouldn't be in the type using an OO design,
it is with templates.
Writing such a function can be done with SFINAE, which becomes easy
using tools from boost :
template<typename It>
typename enable_if<
is_same<It::value_type, int>,
void>::type
some_function(It it);
Iterators deal only with operators, not with types or
interfaces. Its more like passing around macros, with all of the
details being obscured.
There is nothing obscure.
All information is in the type.
So the STL metaphore necessarily does not integrate well with the
underlying C++ type system
It integrates very well. So well that people are still amazed by
things you can do with it.
and cannot be constrained by overloading
They can, using SFINAE.
or inheritance.
Templates apply on types. Inheritance is a special propriety of a
specific category of types.
They're of course not related.
I think we should not forget that C++ was an object
oriented language well before generic programming came about
That would be a very good thing to forget.
The OO idiom in C++ is certainly not its good side.
Generations of developers thought C++ was an OO language, but they
were simply coding in C with Classes. That's very far from the
functionality modern C++ gives.
and
perhaps some of the ideas which generic programming brings with it are
better suited to functional languages.
There is nothing especially functional in genericity.
And C++ can handle the functional idiom quite well.
Generic code is unfortunately opaque, and whilst it can be amazingly
useful, there is a high price to pay in terms or readability and
debugability.
It's not more opaque and non generic code.
Actually, it is often clearer, since it is generic and not specific to
some kind of type.
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 ?
Looks like you don't understand concept maps.
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;}
}
Here, you could just write your comparison as left < right, and if
operator<(decltype(left), decltype(right)) is not found, you get a
compile-time error.
template<typename Kind>
class Compare<Comparable Kind>
{
public:
int Compare(Kind left, Kind right) {return left.Compare(right);}
}
Thats a pretty useful feature when your doing generic programming
That's concepts.
They're doable using library techniques as of today, and are being
included in the next standard to be simpler.
that
does not use the STL or Boost metaphore
It *is* the STL metaphore.
For example, to instantiate std::set with a type, that type must
satisfy the requirement of comparable.
and it integrates tightly with
the more OO aspects of C++, overloading and inheritance.
I fail to see the OO integration.
And how about standardising the representation of function pointers so
that we can write better even handling and callbacks.
I don't see how standardizing the representation of function pointers
would help for callbacks.
What about
closures and coroutines ? Why do these ideas have to remain
"undefined" whilst we focus on much more esoteric problems.
Closures can certainly be very well done in C++, thanks to
overloading. It's called functors.
This is already highly used by the STL, by the way. Be it to indicate
how comparison is to be done or what code to apply with an algorithm
(for_each, transform, etc.)
Functors are usually used through templates, but you can also use them
through subtyping polymorphism, in case you need a single type (to
store the thing, eventually). Of course, the later introduces some
overhead.
For that there is an utility in boost and TR1 to unify all functors
with the same signature to a single type, it's called boost::function.
It could be implemented like this, but actually it uses other tricks
for efficiency.
Here is how for a function taking no argument. For other cases, the
template will have to be "overloaded". Usage of variadic templates (a
new C++0x feature) could also be considered.
template<typename R>
struct base
{
virtual R operator()() = 0;
};
template<typename R, typename F>
struct derived : base<R>
{
derived(const F& f)
{
f_ = f;
}
R operator()()
{
return f_();
}
F f_;
};
template<typename R>
class function
{
public:
template<typename F>
function(const F& f)
{
p_ = new derived<R, F>(f);
}
~function()
{
delete p_;
}
R operator()()
{
return (*p_)();
}
/* additional stuff */
private:
base<R>* p_;
};
Notice how templates and inheritance can be used together to create
that kind of generic, yet runtime-oriented, component.
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 !
Templates are one of the key features of C++, more important than
subtyping polymorphism, which can simply be done by hand with function
pointers anyway.
The only point where templates don't integrate well is with
virtuality, because that would mean the vtable can't be generated
until link-time. That's kinda problematic given the translation model
of C++.
That's too bad actually, that would allow very interesting things.
If your interested in some concrete examples of the alternative
generic programming metaphores which are out there, check out the
structure's namespace from the C++ framework that i recently released
called Reason.
http://reasoning.info/
When reading your work it seems your definition of OO varies.
I was assuming you meant subtyping polymorphism, but actually
sometimes it seems you're just talking about the idea of object based
programming, grouping state data in objects and attaching member
functions to them.
So basically, your reproach that STL is not OO is based on the fact
that to advance an iterator, you have to do ++it and not it.next() ?
It frustrates me that so much of the code that we write has to be
thrown away, but atleast i can take pride in the fact that the code i
write is readable and understandable. It can always be ported to
another language when C++ eventually digs a hole so deep we cant climb
out :(
That's not gonna happen, only C++ has this awesome feature called
templates. ;)
---
[ 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 ]