Lazy evaluation in C++

C++ does not have native support for lazy evaluation (as Haskell does).

I'm wondering if it is possible to implement lazy evaluation in C++ in a reasonable manner. If yes, how would you do it?

EDIT: I like Konrad Rudolph's answer.

I'm wondering if it's possible to implement it in a more generic fashion, for example by using a parametrized class lazy that essentially works for T the way matrix_add works for matrix.

Any operation on T would return lazy instead. The only problem is to store the arguments and operation code inside lazy itself. Can anyone see how to improve this?

> I'm wondering if it is possible to implement lazy evaluation in C++ in a reasonable manner. If yes, how would you do it?

Yes, this is possible and quite often done, e.g. for matrix calculations. The main mechanism to facilitate this is operator overloading. Consider the case of matrix addition. The signature of the function would usually look something like this:

matrix operator +(matrix const& a, matrix const& b);

Now, to make this function lazy, it's enough to return a proxy instead of the actual result:

struct matrix_add;

matrix_add operator +(matrix const& a, matrix const& b) {
    return matrix_add(a, b);
}

Now all that needs to be done is to write this proxy:

struct matrix_add {
    matrix_add(matrix const& a, matrix const& b) : a(a), b(b) { }

    operator matrix() const {
        matrix result;
        // Do the addition.
        return result;
    }
private:
    matrix const& a, b;
};

The magic lies in the method operator matrix() which is an implicit conversion operator from matrix_add to plain matrix. This way, you can chain multiple operations (by providing appropriate overloads of course). The evaluation takes place only when the final result is assigned to a matrix instance.

EDIT I should have been more explicit. As it is, the code makes no sense because although evaluation happens lazily, it still happens in the same expression. In particular, another addition will evaluate this code unless the matrix_add structure is changed to allow chained addition. C++0x greatly facilitates this by allowing variadic templates (i.e. template lists of variable length).

However, one very simple case where this code would actually have a real, direct benefit is the following:

int value = (A + B)(2, 3);

Here, it is assumed that A and B are two-dimensional matrices and that dereferencing is done in Fortran notation, i.e. the above calculates one element out of a matrix sum. It's of course wasteful to add the whole matrices. matrix_add to the rescue:

struct matrix_add {
    // … yadda, yadda, yadda …

    int operator ()(unsigned int x, unsigned int y) {
        // Calculate *just one* element:
        return a(x, y) + b(x, y);
    }
};

Other examples abound. I've just remembered that I have implemented something related not long ago. Basically, I had to implement a string class that should adhere to a fixed, pre-defined interface. However, my particular string class dealt with huge strings that weren't actually stored in memory. Usually, the user would just access small substrings from the original string using a function infix. I overloaded this function for my string type to return a proxy that held a reference to my string, along with the desired start and end position. Only when this substring was actually used did it query a C API to retrieve this portion of the string.

Boost.Lambda is very nice, but Boost.Proto is exactly what you are looking for. It already has overloads of all C++ operators, which by default perform their usual function when proto::eval() is called, but can be changed.

What Konrad already explained can be put further to support nested invocations of operators, all executed lazily. In Konrad's example, he has an expression object that can store exactly two arguments, for exactly two operands of one operation. The problem is that it will only execute one subexpression lazily, which nicely explains the concept in lazy evaluation put in simple terms, but doesn't improve performance substantially. The other example shows also well how one can apply operator() to add only some elements using that expression object. But to evaluate arbitrary complex expressions, we need some mechanism that can store the structure of that too. We can't get around templates to do that. And the name for that is expression templates. The idea is that one templated expression object can store the structure of some arbitrary sub-expression recursively, like a tree, where the operations are the nodes, and the operands are the child-nodes. For a very good explanation i just found today (some days after i wrote the below code) see here.

template<typename Lhs, typename Rhs>
struct AddOp {
    Lhs const& lhs;
    Rhs const& rhs;

    AddOp(Lhs const& lhs, Rhs const& rhs):lhs(lhs), rhs(rhs) {
        // empty body
    }

    Lhs const& get_lhs() const { return lhs; }
    Rhs const& get_rhs() const { return rhs; }
};

That will store any addition operation, even nested one, as can be seen by the following definition of an operator+ for a simple point type:

struct Point { int x, y; };

// add expression template with point at the right
template<typename Lhs, typename Rhs> AddOp<AddOp<Lhs, Rhs>, Point> 
operator+(AddOp<Lhs, Rhs> const& lhs, Point const& p) {
    return AddOp<AddOp<Lhs, Rhs>, Point>(lhs, p);
} 

// add expression template with point at the left
template<typename Lhs, typename Rhs> AddOp< Point, AddOp<Lhs, Rhs> > 
operator+(Point const& p, AddOp<Lhs, Rhs> const& rhs) {
    return AddOp< Point, AddOp<Lhs, Rhs> >(p, rhs);
}

// add two points, yield a expression template    
AddOp< Point, Point > 
operator+(Point const& lhs, Point const& rhs) {
    return AddOp<Point, Point>(lhs, rhs);
}

Now, if you have

Point p1 = { 1, 2 }, p2 = { 3, 4 }, p3 = { 5, 6 };
p1 + (p2 + p3); // returns AddOp< Point, AddOp<Point, Point> >

You now just need to overload operator= and add a suitable constructor for the Point type and accept AddOp. Change its definition to:

struct Point { 
    int x, y; 

    Point(int x = 0, int y = 0):x(x), y(y) { }

    template<typename Lhs, typename Rhs>
    Point(AddOp<Lhs, Rhs> const& op) {
        x = op.get_x();
        y = op.get_y();
    }

    template<typename Lhs, typename Rhs>
    Point& operator=(AddOp<Lhs, Rhs> const& op) {
        x = op.get_x();
        y = op.get_y();
        return *this;
    }

    int get_x() const { return x; }
    int get_y() const { return y; }
};

And add the appropriate get_x and get_y into AddOp as member functions:

int get_x() const {
    return lhs.get_x() + rhs.get_x();
}

int get_y() const {
    return lhs.get_y() + rhs.get_y();
}

Note how we haven't created any temporaries of type Point. It could have been a big matrix with many fields. But at the time the result is needed, we calculate it lazily.

I have nothing to add to Konrad's post, but you can look at Eigen for an example of lazy evaluation done right, in a real world app. It is pretty awe inspiring.

I'm thinking about implementing a template class, that uses std::function. The class should, more or less, look like this:

template <typename Value>
class Lazy
{
public:
	Lazy(std::function<Value()> function) : _function(function), _evaluated(false) {}

	Value &operator*()  { Evaluate(); return  _value; }
	Value *operator->() { Evaluate(); return &_value; }

private:
	void Evaluate()
	{
		if (!_evaluated)
		{
			_value = _function();
			_evaluated = true;
		}
	}

	std::function<Value()> _function;
	Value _value;
	bool _evaluated;
};

For example usage:

class Noisy
{
public:
	Noisy(int i = 0) : _i(i)
	{
		std::cout << "Noisy(" << _i << ")"  << std::endl;
	}
	Noisy(const Noisy &that) : _i(that._i)
	{
		std::cout << "Noisy(const Noisy &)" << std::endl;
	}
	~Noisy()
	{
		std::cout << "~Noisy(" << _i << ")" << std::endl;
	}

	void MakeNoise()
	{
		std::cout << "MakeNoise(" << _i << ")" << std::endl;
	}
private:
	int _i;
};	

int main()
{
	Lazy<Noisy> n = [] () { return Noisy(10); };

	std::cout << "about to make noise" << std::endl;

	n->MakeNoise();
	(*n).MakeNoise();
	auto &nn = *n;
	nn.MakeNoise();
}

Above code should produce the following message on the console:

Noisy(0)
about to make noise
Noisy(10)
~Noisy(10)
MakeNoise(10)
MakeNoise(10)
MakeNoise(10)
~Noisy(10)

Note that the constructor printing Noisy(10) will not be called until the variable is accessed.

This class is far from perfect, though. The first thing would be the default constructor of Value will have to be called on member initialization (printing Noisy(0) in this case). We can use pointer for _value instead, but I'm not sure whether it would affect the performance.

Johannes' answer works.But when it comes to more parentheses ,it doesn't work as wish. Here is an example.

Point p1 = { 1, 2 }, p2 = { 3, 4 }, p3 = { 5, 6 }, p4 = { 7, 8 };
(p1 + p2) + (p3+p4)// it works ,but not lazy enough

Because the three overloaded + operator didn't cover the case

AddOp<Llhs,Lrhs>+AddOp<Rlhs,Rrhs>

So the compiler has to convert either (p1+p2) or(p3+p4) to Point ,that's not lazy enough.And when compiler decides which to convert ,it complains. Because none is better than the other . Here comes my extension: add yet another overloaded operator +

    template <typename LLhs, typename LRhs, typename RLhs, typename RRhs>
AddOp<AddOp<LLhs, LRhs>, AddOp<RLhs, RRhs>> operator+(const AddOp<LLhs, LRhs> & leftOperandconst, const AddOp<RLhs, RRhs> & rightOperand)
{
	return  AddOp<AddOp<LLhs, LRhs>, AddOp<RLhs, RRhs>>(leftOperandconst, rightOperand);

}

Now ,the compiler can handle the case above correctly ,and no implicit conversion ,volia!

As it's going to be done in C++0x, by lambda expressions.

Anything is possible.

It depends on exactly what you mean:

class X
{
     public: static X& getObjectA()
     {
          static X instanceA;

          return instanceA;
     }
};

Here we have the affect of a global variable that is lazily evaluated at the point of first use.

As newly requested in the question.
And stealing Konrad Rudolph design and extending it.

The Lazy object:

template<typename O,typename T1,typename T2>
struct Lazy
{
    Lazy(T1 const& l,T2 const& r)
        :lhs(l),rhs(r) {}

    typedef typename O::Result  Result;
    operator Result() const
    {
        O   op;
        return op(lhs,rhs);
    }
    private:
        T1 const&   lhs;
        T2 const&   rhs;
};

How to use it:

namespace M
{
    class Matrix
    {
    };
    struct MatrixAdd
    {
        typedef Matrix  Result;
        Result operator()(Matrix const& lhs,Matrix const& rhs) const
        {
            Result  r;
            return r;
        }
    };
    struct MatrixSub
    {
        typedef Matrix  Result;
        Result operator()(Matrix const& lhs,Matrix const& rhs) const
        {
            Result  r;
            return r;
        }
    };
    template<typename T1,typename T2>
    Lazy<MatrixAdd,T1,T2> operator+(T1 const& lhs,T2 const& rhs)
    {
        return Lazy<MatrixAdd,T1,T2>(lhs,rhs);
    }
    template<typename T1,typename T2>
    Lazy<MatrixSub,T1,T2> operator-(T1 const& lhs,T2 const& rhs)
    {
        return Lazy<MatrixSub,T1,T2>(lhs,rhs);
    }
}

In C++11 lazy evaluation similar to hiapay's answer can be achieved using std::shared_future. You still have to encapsulate calculations in lambdas but memoization is taken care of:

std::shared_future<int> a = std::async(std::launch::deferred, [](){ return 1+1; });

Here's a full example:

#include <iostream>
#include <future>

#define LAZY(EXPR, ...) std::async(std::launch::deferred, [__VA_ARGS__](){ std::cout << "evaluating "#EXPR << std::endl; return EXPR; })

int main() {
    std::shared_future<int> f1 = LAZY(8);
    std::shared_future<int> f2 = LAZY(2);
    std::shared_future<int> f3 = LAZY(f1.get() * f2.get(), f1, f2);

    std::cout << "f3 = " << f3.get() << std::endl;
    std::cout << "f2 = " << f2.get() << std::endl;
    std::cout << "f1 = " << f1.get() << std::endl;
    return 0;
}

C++0x is nice and all.... but for those of us living in the present you have Boost lambda library and Boost Phoenix. Both with the intent of bringing large amounts of functional programming to C++.

Lets take Haskell as our inspiration - it being lazy to the core. Also, let's keep in mind how Linq in C# uses Enumerators in a monadic (urgh - here is the word - sorry) way. Last not least, lets keep in mind, what coroutines are supposed to provide to programmers. Namely the decoupling of computational steps (e.g. producer consumer) from each other. And lets try to think about how coroutines relate to lazy evaluation.

All of the above appears to be somehow related.

Next, lets try to extract our personal definition of what "lazy" comes down to.

One interpretation is: We want to state our computation in a composable way, before executing it. Some of those parts we use to compose our complete solution might very well draw upon huge (sometimes infinite) data sources, with our full computation also either producing a finite or infinite result.

Lets get concrete and into some code. We need an example for that! Here, I choose the fizzbuzz "problem" as an example, just for the reason that there is some nice, lazy solution to it.

In Haskell, it looks like this:

module FizzBuzz
( fb
)
where
fb n =
	fmap merge fizzBuzzAndNumbers
	where
		fizz = cycle ["","","fizz"]
		buzz = cycle ["","","","","buzz"]
		fizzBuzz = zipWith (++) fizz buzz
		fizzBuzzAndNumbers = zip [1..n] fizzBuzz
		merge (x,s) = if length s == 0 then show x else s

The Haskell function cycle creates an infinite list (lazy, of course!) from a finite list by simply repeating the values in the finite list forever. In an eager programming style, writing something like that would ring alarm bells (memory overflow, endless loops!). But not so in a lazy language. The trick is, that lazy lists are not computed right away. Maybe never. Normally only as much as subsequent code requires it.

The third line in the where block above creates another lazy!! list, by means of combining the infinite lists fizz and buzz by means of the single two elements recipe "concatenate a string element from either input list into a single string". Again, if this were to be immediately evaluated, we would have to wait for our computer to run out of resources.

In the 4th line, we create tuples of the members of a finite lazy list [1..n] with our infinite lazy list fizzbuzz. The result is still lazy.

Even in the main body of our fb function, there is no need to get eager. The whole function returns a list with the solution, which itself is -again- lazy. You could as well think of the result of fb 50 as a computation which you can (partially) evaluate later. Or combine with other stuff, leading to an even larger (lazy) evaluation.

So, in order to get started with our C++ version of "fizzbuzz", we need to think of ways how to combine partial steps of our computation into larger bits of computations, each drawing data from previous steps as required.

You can see the full story in a gist of mine.

Here the basic ideas behind the code:

Borrowing from C# and Linq, we "invent" a stateful, generic type Enumerator, which holds

• The current value of the partial computation
• The state of a partial computation (so we can produce subsequent values)
• The worker function, which produces the next state, the next value and a bool which states if there is more data or if the enumeration has come to an end.

In order to be able to compose Enumerator<T,S> instance by means of the power of the . (dot), this class also contains functions, borrowed from Haskell type classes such as Functor and Applicative.

The worker function for enumerator is always of the form: S -> std::tuple<bool,S,T where S is the generic type variable representing the state and T is the generic type variable representing a value - the result of a computation step.

All this is already visible in the first lines of the Enumerator class definition.

template <class T, class S>
class Enumerator
{
public:
	typedef typename S State_t;
	typedef typename T Value_t;
	typedef std::function<
		std::tuple<bool, State_t, Value_t>
		(const State_t&
			)
	> Worker_t;

	Enumerator(Worker_t worker, State_t s0)
		: m_worker(worker)
		, m_state(s0)
		, m_value{}
	{
	}
    // ...
};

So, all we need to create a specific enumerator instance, we need to create a worker function, have the initial state and create an instance of Enumerator with those two arguments.

Here an example - function range(first,last) creates a finite range of values. This corresponds to a lazy list in the Haskell world.

template <class T>
Enumerator<T, T> range(const T& first, const T& last)
{
	auto finiteRange =
		[first, last](const T& state)
	{
		T v = state;
		T s1 = (state < last) ? (state + 1) : state;
		bool active = state != s1;
		return std::make_tuple(active, s1, v);
	};
	return Enumerator<T,T>(finiteRange, first);
}

And we can make use of this function, for example like this: auto r1 = range(size_t{1},10); - We have created ourselves a lazy list with 10 elements!

Now, all is missing for our "wow" experience, is to see how we can compose enumerators. Coming back to Haskells cycle function, which is kind of cool. How would it look in our C++ world? Here it is:

template <class T, class S>
auto
cycle
( Enumerator<T, S> values
) -> Enumerator<T, S>
{
	auto eternally =
		[values](const S& state) -> std::tuple<bool, S, T>
	{
		auto[active, s1, v] = values.step(state);
		if (active)
		{
			return std::make_tuple(active, s1, v);
		}
		else
		{
			return std::make_tuple(true, values.state(), v);
		}
	};
	return Enumerator<T, S>(eternally, values.state());
}

It takes an enumerator as input and returns an enumerator. Local (lambda) function eternally simply resets the input enumeration to its start value whenever it runs out of values and voilà - we have an infinite, ever repeating version of the list we gave as an argument:: auto foo = cycle(range(size_t{1},3)); And we can already shamelessly compose our lazy "computations".

zip is a good example, showing that we can also create a new enumerator from two input enumerators. The resulting enumerator yields as many values as the smaller of either of the input enumerators (tuples with 2 element, one for each input enumerator). I have implemented zip inside class Enumerator itself. Here is how it looks like:

// member function of class Enumerator<S,T> 
template <class T1, class S1>
auto
zip
( Enumerator<T1, S1> other
) -> Enumerator<std::tuple<T, T1>, std::tuple<S, S1> >
{
	auto worker0 = this->m_worker;
	auto worker1 = other.worker();
	auto combine =
		[worker0,worker1](std::tuple<S, S1> state) ->
		std::tuple<bool, std::tuple<S, S1>, std::tuple<T, T1> >
	{
		auto[s0, s1] = state;
		auto[active0, newS0, v0] = worker0(s0);
		auto[active1, newS1, v1] = worker1(s1);
		return std::make_tuple
			( active0 && active1
			, std::make_tuple(newS0, newS1)
			, std::make_tuple(v0, v1)
			);
	};
	return Enumerator<std::tuple<T, T1>, std::tuple<S, S1> >
		( combine
		, std::make_tuple(m_state, other.state())
		);
}

Please note, how the "combining" also ends up in combining the state of both sources and the values of both sources.

As this post is already TL;DR; for many, here the...

Summary

Yes, lazy evaluation can be implemented in C++. Here, I did it by borrowing the function names from haskell and the paradigm from C# enumerators and Linq. There might be similarities to pythons itertools, btw. I think they followed a similar approach.

My implementation (see the gist link above) is just a prototype - not production code, btw. So no warranties whatsoever from my side. It serves well as demo code to get the general idea across, though.

And what would this answer be without the final C++ version of fizzbuz, eh? Here it is:

std::string fizzbuzz(size_t n)
{
	typedef std::vector<std::string> SVec;
	// merge (x,s) = if length s == 0 then show x else s
	auto merge =
		[](const std::tuple<size_t, std::string> & value)
		-> std::string
	{
		auto[x, s] = value;
		if (s.length() > 0)	return s; 
		else return std::to_string(x);
	};

	SVec fizzes{ "","","fizz" };
	SVec buzzes{ "","","","","buzz" };

	return
	range(size_t{ 1 }, n)
	.zip
		( cycle(iterRange(fizzes.cbegin(), fizzes.cend()))
		  .zipWith
			( std::function(concatStrings)
			, cycle(iterRange(buzzes.cbegin(), buzzes.cend()))
			)
		)
	.map<std::string>(merge)
	.statefulFold<std::ostringstream&>
	(
		[](std::ostringstream& oss, const std::string& s) 
		{
			if (0 == oss.tellp())
			{
				oss << s;
			}
			else
			{
				oss << "," << s;
			}
		}
		, std::ostringstream()
	)
	.str();
}

And... to drive the point home even further - here a variation of fizzbuzz which returns an "infinite list" to the caller:

typedef std::vector<std::string> SVec;
static const SVec fizzes{ "","","fizz" };
static const SVec buzzes{ "","","","","buzz" };

auto fizzbuzzInfinite() -> decltype(auto)
{
	// merge (x,s) = if length s == 0 then show x else s
	auto merge =
		[](const std::tuple<size_t, std::string> & value)
		-> std::string
	{
		auto[x, s] = value;
		if (s.length() > 0)	return s;
		else return std::to_string(x);
	};

	auto result =
		range(size_t{ 1 })
		.zip
		(cycle(iterRange(fizzes.cbegin(), fizzes.cend()))
			.zipWith
			(std::function(concatStrings)
				, cycle(iterRange(buzzes.cbegin(), buzzes.cend()))
			)
		)
		.map<std::string>(merge)
		;
	return result;
}

It is worth showing, since you can learn from it how to dodge the question what the exact return type of that function is (as it depends on the implementation of the function alone, namely how the code combines the enumerators).

Also it demonstrates that we had to move the vectors fizzes and buzzes outside the scope of the function so they are still around when eventually on the outside, the lazy mechanism produces values. If we had not done that, the iterRange(..) code would have stored iterators to the vectors which are long gone.

Using a very simple definition of lazy evaluation, which is the value is not evaluated until needed, I would say that one could implement this through the use of a pointer and macros (for syntax sugar).

#include <stdatomic.h>

#define lazy(var_type) lazy_ ## var_type

#define def_lazy_type( var_type ) \
	typedef _Atomic var_type _atomic_ ## var_type; \
	typedef _atomic_ ## var_type * lazy(var_type);  //pointer to atomic type

#define def_lazy_variable(var_type, var_name ) \
	_atomic_ ## var_type _ ## var_name; \
	lazy_ ## var_type var_name = & _ ## var_name;

#define assign_lazy( var_name, val ) atomic_store( & _ ## var_name, val )
#define eval_lazy(var_name) atomic_load( &(*var_name) )

#include <stdio.h>

def_lazy_type(int)

void print_power2 ( lazy(int) i )
{
      printf( "%d\n", eval_lazy(i) * eval_lazy(i) );
}

typedef struct {
    int a;
} simple;

def_lazy_type(simple)

void print_simple ( lazy(simple) s )
{
	simple temp = eval_lazy(s);
	printf("%d\n", temp.a );
}


#define def_lazy_array1( var_type, nElements, var_name ) \
	_atomic_ ## var_type  _ ## var_name [ nElements ]; \
	lazy(var_type) var_name = _ ## var_name; 
	
int main ( )
{
	//declarations
	def_lazy_variable( int, X )
	def_lazy_variable( simple, Y)
	def_lazy_array1(int,10,Z)
	simple new_simple;
	
	//first the lazy int
	assign_lazy(X,111);
	print_power2(X);

	//second the lazy struct
	new_simple.a = 555;
	assign_lazy(Y,new_simple);
	print_simple ( Y );

	//third the array of lazy ints
	for(int i=0; i < 10; i++)
	{
		assign_lazy( Z[i], i );
	}
	
	for(int i=0; i < 10; i++)
	{
		int r = eval_lazy( &Z[i] ); //must pass with &
		printf("%d\n", r );
	}

	return 0;
}

You'll notice in the function print_power2 there is a macro called eval_lazy which does nothing more than dereference a pointer to get the value just prior to when it's actually needed. The lazy type is accessed atomically, so it's completely thread-safe.