Re: C++ Template Overloading
On Apr 23, 2:23 pm, Emerson <emerson.cla...@gmail.com> wrote:
But remember that concepts are fixing problems that exist with the STL/
Boost metaphor.
That's a very narrow view of what concepts "are". Concepts support the
Generic Programming paradigm.
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...
Is that a bad thing? I dare say that it's common practice in the OO
world, too, with Python using iterator protocols in its foreach loop
and C# using library-defined interfaces.
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++.
With concepts, they're concepts and they have names.
All types support operators, but you
dont have to explicitly say that a type inherits from interfaces like
"LessThanComparable", "GreaterThanComparable", "EqualsComparable".
With concepts, we say that the type "models" a concept. If you want to
be explicit about this relationship, write a concept map.
The curse is that in exchange for that 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. So
what you end up with is some very complicated and opaque code, with
lots of workarounds and messy business like type traits to try to
compensate.
We're still talking about pre-concept C++, aren't we? *sigh* This mess
goes away with concepts.
You will note that the interfaces like "LessThanComparable" which i
mentioned above match pretty closely the kindof examples that are used
in the Google tech talk about concepts. In a way its kindof pointing
to the fact that the STL/Boost metaphor has a flaw, and that in the
end we really need a way of expressing and verifying those constraints
and ideas in an "interface" like way.
Concepts and interfaces have a common kernel: they both express
abstractions and are used to implement polymorphic algorithms.
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. 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.
Reason is an OO library that adheres to OO principles. STL is a
generic library that adheres to GP principles. Both have their
trade-offs.
Yes, its possible with concepts, which i think is great. But
unfortunately were all going to have to wait a while to get our hands
on that... :)
Well, you can try ConceptGCC now---but industrial-strength
implementations of concepts are still several years away.
Although in general one would probably want to take any Integral type,
since C++ has so many to choose from:
template<InputIterator Iter>
requires Integral<Iter::value_type>
void foo(Iter first, Iter last);
How deep does the concept go here ? Is an integral type just a type
which supports + and - or does it enforce rules of associativity and
other mathematical properties. If it does then that is very exciting
indeed. I think there was mention of this in the tech talk...
The concept can express these mathemetical properties, and the
compiler is free to use or enforce them.
I didnt quite follow that, were you implying that becuase STL/Boost
style iterators drop the unimportant details they are polymorphic ?
The essence of polymorphism is that one can ignore unimportant
details, such as the specific name/layout/members/etc. of a type.
Too me, polymorphism is too closely linked with the notion of
inheritance and type. Without type there is a disconnect, its not so
much polymorphism as it is just anonymous abstraction.
This is a very narrow view of polymorphism that is completely
out of line with the idea of polymorphism in the programming languages
community. The Wikipedia page on type polymorphism seems to give a
reasonable definition:
http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
Theres a huge difference between using some of the amazingly clever
hacks and tricks in Boost to having native language support for things
like function pointers and coroutines though. For a start the syntax
would be a lot simpler, and there would be no where near so many hoops
to jump through or caveats and special cases to avoid.
Have you used std::function (or its Boost predecessor)? I find that
it's syntax is as clean as any language feature would be. A quick
example:
int square(int x) { return x*x; }
function<int(int)> f = square;
std::cout << f(3) << std::endl; // prints "9"
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 ? Makes me think
that either the initial standards were very loose, or the language is
far too complicated, or perhaps people are just extremely ingenious ?
Maybe a bit of everything :)
Lots of languages are getting operator overloading and "generics"; C++
just has more powerful variants of these features, and that is
completely intentional. The philosophy C++ has been that with a
powerful core language, users can write libraries that in turn make
the language more powerful. Why wait 5 years for C++ to get a
generalized function pointer in the language when you can write the
function template in a day and get all of that functionality
immediately? Why wait forever for C++ to get a niche language feature
for your specific domain (say, quaternions) when you can build that
functionality into a domain-specific library for yourself?
You've said that you want the C++0x standard to be more far-reaching,
but I think you've missed the point of C++: C++0x provides a lot of
features that make it easier to build great libraries. It's these
libraries that make C++ more far-reaching, because programmers that
really understand their domain---whether it is mathemetics, or
physics, or network apps, or whatever---will always build better
library abstractions than any language designer could build language
features.
- Doug
---
[ 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 ]