Re: future of the C++
On Jul 7, 3:21 am, Andre Kaufmann <akfmn...@t-online.de> wrote:
Function objects yes. But the C++ compiler hasn't any notion of semantic
of the function (internals) anymore - it has generated code.
I do not really understand what you're talking about, and neither why
it would be a problem.
You can't (that easily) pass function objects to another function
There is nothing hard about it.
Either take it as a template argument or use type erasure with
std::function (but once you erase the type, you necessarily make any
function object monomorphic, as you have to specify a signature).
use pattern matching (e.g. if parameter number2 is of type int and has
value 5 then emit that code).
Pattern matching is a feature of sum types, not of functions. They are
tagged unions of different possible types, and pattern matching is a
process that happens at runtime. Note typical statically compiled
implementations do not do any code generation at runtime, so it's
basically a switch or a an indirect function call.
You can do the same thing with boost::variant (which visitors use a
switch under the hood), for example, albeit it's getting a bit old and
would be in need of modernization. I've written myself a helper that
generates a visitor from a set of function objects (possibly lambdas)
and the end syntax is basically the same as pattern matching, except
it only matches at the first level. Matching arbitrarily deep would be
possible, but it would require a DSEL-based visitor mechanism that
would do unification, rather than relying on plain old overloading to
select the function to invoke depending on the type.
It's more like a mixture of C++ templates
and delegates, but without the restrictions.
I don't get what that is about.
Besides that it's more compact to write:
Example:
let r f(x, y, z) = fx + fy + fz;
I do not know what this syntax is supposed to do. This is not valid
OCaml for example.
would be something like:
template <typename T, typename F, typename X, typename Y, typename Z>
T r(F function, X x, Y y, Z z)
{
return function(x) + function(y) + function(z);
}
Well yeah, when you name the function "function", the code tends to be
more verbose than when you name it "f" ;).
Otherwise, it is true the template<...> part is more verbose than type
inference. You can have something like type inference with the GCC
polymorphic lambda extension I discussed, however.
I don't think it would be good to have that in normal function
definition, because to do type-inference-like behaviour you need to
put the whole expression-body in a decltype return clause, and that's
not very nice when function declaration and definition are decoupled
like they are in C++.
Hm, but this ABI standard (wasn't aware of it) isn't part of the C++
standard ?
No it isn't, it's an industry standard.
I don't think that a general ABI standard would be needed for all
platforms (although this would be nice), but a single one for each
platform would be IMHO sufficient, since you can't mix any libraries of
different platforms either.
But any "basic open (C++) ABI standard" for each platform should exist
and supported by all C++ compilers for this platform.
Isn't that basically the state of things?
All platforms follow the Itanium C++ ABI adapted to their
architecture, except the windows platforms that follows the Microsoft
ABI.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]