Re: future of the C++
On Jul 8, 4:37 am, George Neuner <gneun...@comcast.net> wrote:
I think Andre is complaining about the lack of introspection.
Runtime introspection is not particularly needed for anything real,
and certainly not functional programming.
The point of a function object (or any closure-like device) is to use
it generically.
I'm not sure I see what this is supposed to mean.
The point of a closure-like device is to be able to call it, combine
it with other closures, and pass it around to code that has no
knowledge of what the closure is or does, except that it accepts the
types it gives.
C++'s lack of <dynamic typing> prevents easy use of <things you can do when you have dynamic typing>.
(Edited by myself)
Unrelated.
The fact Lisp is dynamically typed doesn't mean that this is what
functional programming is about.
Emulating multiple dispatch with argument type checking gets messy
very quickly.
I didn't claim it wasn't.
The best way to do multiple dispatch is certainly to use dynamic
typing. CLOS does it very nicely.
std::function defeats the purpose entirely - it removes the ability of
the compiler to type check arguments even for a normal call.
It does type checking all right. Trying to assign a function object
that cannot be called with the signature given will lead to a compile-
time error.
Pattern matching is not a "run time" or "compile time" thing
I am talking about the programming feature as presented in a language
like OCaml, not the theoretical foundations behind it or whatever you
were understanding.
It is indeed a runtime thing, as a variable may be of a different type
depending on runtime conditions. The identification of what type is
being held and the appropriate dispatch to a piece of code is done at
runtime, and this is what pattern matching does.
How exactly do you think a C++ compiler determines which overload of a
function to call? Hint, it's described in ?13.3.1 on page 292 of the
current draft (n3090).
It happens at compile-time, yes, and I never claimed otherwise.
The problem is that C++ overload resolution only matches static types
at compile time, so there is no _good_ way to perform multiple
dispatch on runtime object types.
You don't seem to understand what I was talking about, so here is an
example.
Say you have, in ML
type btree = Leaf | Node of int * btree * btree
with variant, you express that as (it's been a while since I've used
recursive ones, but I think this syntax is correct)
struct leaf_t {};
typedef tuple<int, recursive_wrapper<_>, recursive_wrapper<_>> node_t;
typedef variant<leaf_t, node_t> btree_t;
In ML, to visit it, you write
match mytree with
Leaf -> do_something_for_leaf ()
| Node(v, lft, rgt) -> do_something_for_node v lgt rgt
;
With variant, you could write
apply_visitor(make_overload<void>(
[&](leaf_t) { do_something_for_leaf(); },
[&](node_t& n) { do_something_for_node(n.get<0>(), n.get<1>(),
n.get<2>()); }
), mytree);
(Not this also works to visit multiple objects at the same time)
apply_visitor, from boost.variant, does internally the dispatch, then
casts the variant objects back to their real types, and finally calls
a polymorphic function object.
By generating that polymorphic function object through overloading
several monomorphic functions, you obtain syntax similar to that of
pattern matching.
The limitation of that technique is that you can't ask to match on
things like Node(_, Leaf, Leaf), but that kind of thing would still be
possible to do using a DSEL.
Which is a long-winded way to accomplish 1/3 of runtime multiple
dispatch ... namely it solves identification of the argument's runtime
type. You still need a way to describe function argument lists and to
match the list of variant arguments to the descriptions.
And overloading does just that; nothing prevents you however from
coding your own resolution scheme as a pure library implementation,
using a DSEL to describe what you want to match on.
(I really feel like I am repeating myself)
Sorry, but you are misinformed. ABIs are register level function
linkage specifications
The register-level part, that is architecture-specific, is not the
problem. This is taken care of by the C ABI anyway.
All platforms follow the Itanium C++ ABI adapted to their architecture,
That statement doesn't even make sense. You can be certain that the
ABIs for PowerPC, ARM, SPARC, etc. most definitely are NOT adapted
from the Itanium.
It's called the Itanium C++ ABI, but it aims at being generic and has
very few Itanium-specific parts, easily adaptable to any other
architecture.
See <http://www.codesourcery.com/public/cxx-abi/abi.html>
If there is a common ABI for a platform, it should be supported by all
compilers for all languages.
Language features dictate the ABI. Consider name mangling, exceptions
and vtables.
Those are actually the things that vendors historically had difficulty
to agree on, and that is what the Itanium C++ ABI specifies.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]