On Wed, Nov 21, 2012 at 8:32 PM, john skaller <skal...@users.sourceforge.net
> wrote:
> I'm not completely sure what C++11 stuff would be most useful
> to Felix. A lot of the stuff that avoids book-keeping for human programmers
> is no problem in generated code.
>
> Some of the new library containers may be useful.
>
> In the core language, initialiser syntax like
>
> X = { .. }
>
> would be a big help. Felix has to either generate constructors to do this,
> or, it has to generate a separate variable somewhere and manually
> initialise
> it with assignments. For the compiler keeping track of this is hard because
> the need to generate the initialiser list is usually discovered too late
> to back track and insert statements to create the value .. i.e. you're in
> the middle of generating an expression and you run into something
> that can only be made into one by a magic function you have to define
> *earlier* in the code.
>
> For exactly the same reason the lambda feature would be useful.
> It allows a bunch of statements to be inserted into an expression.
>
> <rant>
> Curious the committee didn't bother to allow named nested functions!
> Oh .. was that because they stupidly used up the "auto" keyword which
> would have declared them? :-) Of course the whole worry about keywords
> is irrelevant these days because we have GLR parsers but I guess they
> didn't exist then. C++11 actually has a couple of "context sensitive
> keywords"
> now (identifiers treated as keywords only in a particular context).
> </rant>
>
Nested functions are less necessary once you have lambdas. Or, to put it
another way, you get one kind of nested function by writing
auto nested_fn = [&] { code; goes; here; }
A couple of the "easier reading" feature will also be useful not for
> the Felix compiler as such, but to make the generated code easier
> to read. Felix doesn't need "auto" but it could make generated code
> look nicer.
>
> The there's rvalue references and move semantics which will certainly
> be important even for Felix. These should allow significant performance
> improvements not possible otherwise (even with compiler generated code).
>
> I may have missed something. Any suggestions for other useful stuff
> in C++11?
>
> BTW: C++11 doesn't have arithmax. That annoys me :-)
> We need a trait:
>
> template<class T, class U> class result::type<T,U>
>
> which gives the type of
>
> x + y
>
> for all possible x,y in the set of standard scalar types. Felix has to have
> this. It currently (mis)calculates the result at configuration time.
> The result is platform dependent in corner cases eg
>
> long long + unsigned long
>
> could be long long or unsigned long depending on whether
> sizeof(long) == sizeof(long long). If they're equal the unsigned
> long is used otherwise long long is used (i.e. the biggest one is
> used or the unsigned one if they're the same).
>
On the bright side, decltype/declval make it a one-liner.
#include <utility> // for declval
template <typename LHS, typename RHS>
using type_of_sum = decltype(::std::declval<LHS>() + ::std::declval<RHS>());
type_of_sum<long long, unsigned long> s = 1LL + 7UL;
-- James
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
