On 07/12/2012, at 6:55 AM, srean wrote:

> 
> yes pretty much, just that the "plus" is provided at compile time and it 
> returns a random_access iter if both a and b are random access, otherwise 
> returns a bidirectional one. Well, thats very limiting, but for now I did not 
> need anything other than random_access and bidirectional. Figuring out the 
> constness rules was painful, so I forced it so that *p is always const.

Yeah. Felix does the opposite, it casts away const.
I mean the compiler does this systematically as does the library.

> Since these lazy iterators can be arguments for chaining them further, i.e. q 
> = minus (p, r); taming the combinatorial explosion of the 
> lazy_iterator_generator was the other thing to bother about, that is to have 
> both, not too many overloaded functions, yet be exhaustive.

You'd use the decltype thing in C++11.

> 
> Using generators in Felix:
> 
>         gen binop (f: int * int -> int ) (a: 1 -> int, b: 1 -> int) () => f ( 
> a(), b() );
> 
> one liner :)
> 
>  Indeed. The C++ code had gobs of other crap around this oneliner overload of 
> the '*' operator.

Yes, but it still won't work. You can have smart pointers, but not
smart references. So you can overload * and -> but not . so you're screwed.

The right way to do this (in C++) is to copy the Felix method and use
genuinely polyadic operations. Instead of

        *  ++ ==

which are the three core operations for iterators in C++, use generators.

        template<class T>
        struct Generator { 
                virtual T get() = 0;
        }

will work fine for infinite streams. You can of course now write one that
uses an normal Vector iterator. Since C++ iterators are not polyadic
you need one for each data structure.

But once you have the translation you only need ONE generator
for each combination.

I would not fear the overhead of a virtual call too much.

Fully expanded code is only faster in theory.
In practice, C++ compiler backends like gcc and LLVM are incapable
of optimising code very well in big functions. So inlining has to be
limited or the compiler will die. Given that plus the ability of modern
caching, branch prediction etc, a few extra indirections probably don't
cost much.

> I have access to a 8 core so should be able to test things out, but fair 
> warning I cannot promise to be very responsive.

I'll keep that in mind.

--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org




------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to