Pull to refresh

Comments 29

А как с поддержкой всего этого дела? GCC держит?
VS2010 держит. У GCC поддержка лямбд вроде в отдельном бранче была.
visual studio 2010 RC и GCC 4.5 такое осилят.
В gcc 4.4 не хватает лямбд.
Студия от gcc 4.5 отстает в поддержке списков инициализации (но их тут нет).
последние снапшоты gcc из оверлея toolchain деражат
Извините, промазал. Отвечал Gorthauer87 (-:
Честно говоря, словосочетание «ленивые вычисления» у меня ассоциируются с несколько иным смыслом. Но вообще код выглядит неплохо.
Ориентировался на википедию:
«Отложенные вычисления, ленивые вычисления или нестрогие вычисления — концепция в некоторых языках программирования, согласно которой вычисления следует откладывать до тех пор, пока не понадобится их результат.»

Код функтора выполнится при первом требовании, сохранит результат для последующих вызовов.
Если функтор не будет вызван — никакой работы не будет.
Если будет вызван несколько раз — работа произойдет один раз, при первом вызове.

Разве не лениво? :)
Лениво было бы вот так:
Пардон, отправил случайно :)

В общем, лениво было бы вот так:

int a = some_lazy_func();  // по идее возвращает какое-то значение,
                           // но на самом деле пока ничего не вычислялось


cout << a; // нужно отобразить результат, значит,
           // самое время вычислить то, что должны были

Совсем такое только компилятор может обеспечить.
С функтором немного сложнее, зато имеем явную декларацию поведения — откладывать или не откладывать.
auto a = calc_once([]{ return some_func(); });
cout << a();
Ну, поэтому я и удивился немного такому названию.

А чем этот Ваш пример будет отличаться от:

auto a = []{ return some_func(); };
cout << a();

?
А, ну в общем я понял. Если мы будем вызывать функтор несколько раз в разных местах, то он будет вычисляться только единожды. То есть фактически Вы просто запомнили возвращённое значение, но внутри самого функтора. Не очень-то лениво :)
Не совсем лениво. Вы правильно цитируете, что «вычисления откладываются до тех пор, пока не понадобится их результат». Но на самом деле методика с кэшированием недостаточно ленива.

Один из любимых примеров в ленивых языках — это численный поиск решения уравнения. Представьте себе, что решение итеративно ищется алгоритмом x[i+1] = F(x[i]). Если разница между соседними решениями меньше e, алгоритм прекращает работу.

Так вот, в ленивом языке можно запустить генерацию бесконечного списка x, а затем просто пройтись по нему и посмотреть, где соседние элементы близки. В реальности пока мы не прочтём значение x[i], его и не вычисляют. Я не думаю, что с помощью кэширование такого можно добиться.
Все просто: x — это ленивый генератор ленивых функторов :).
Когда от него просят x[i], и в своем контейнере функторов для i у него ничего нет — он делает ленивый функтор и сохраняет его в контейнер. Функторы знают свой индекс и знают X, у которого могут запрашивать доступ к соседям.

И вся эта чехарда, чтобы написать что-то вроде:
for (unsigned i = 0; ( x[i + 1]() - x[i]() ) >= eps; ++i);
Ну понятно, что можно левой ногой правое ухо чесать :)

А вся эта история, быть может, в данном конкретном случае притянута за уши, но в общем виде преследует ясную цель: разделение алгоритмов.
Допустим, есть некий алгоритм генерации списка (потенциально бесконечного) и алгоритм анализа списка.

Если ленивые вычисления доступны, можно писать эти алгоритмы независимо друг от друга, а потом тривиально объединить. Как обычно, просто повышаем абстракцию, ради этого все надстройки над Ассемблером и выдуманы…
Я ещё не слишком знаком со стандартом C++0x, но мне кажется, что вы просто написали урезанную версию std::future. Разве что там вычисление асинхронное.
Спасибо за наводку, но это не совсем то.
Насколько я понял, std::future делает вычисления в параллельном потоке, и начинает сразу (т.е. нифига не ленится :)).
Ее стоит использовать, когда вам гарантировано понадобится результат, но вы хотите, пока он считается, заняться чем-нибудь другим.
Это не ленивые вычисления, а типа «чистая» функция с некоторой оптимизацией. Например, в Digital Mars D есть для таких случаев ключевое слово pure, а компилятор уже сам занимается запоминанием готовых результатов.

ленивые вычисления в фунциональных языках — это получение результата только по непосредственному требованию; к оптимизации отношение такая фича имеет только косвенное.
Это именно класс, реализующий ленивое вычисление. pure в Digital Mars D не имеет к данному топику никакого отношения, как и lazy, который не запоминает результат первого вычисления.

Кстати, AndrewAZ, у этой реализации на C++ будут проблемы, если функция не чистая т.к. при изменении глобального состояния может измениться результат вызова функции, а при использовании calc_once результат не изменится.

Вы можете возразить, что использовать глобальное состояние — плохо, на что я отвечу, что в таком случае вам не нужен C++ ;)
ну я не очень знаю D, факт, но вот с функциональными языками знаком нормально.

Где здесь ленивые вычисления?
С Вики:

«Отложенные вычисления, ленивые вычисления или нестрогие вычисления (англ. lazy evaluation) — концепция в некоторых языках программирования, согласно которой вычисления следует откладывать до тех пор, пока не понадобится их результат.»

с английской вики:

«In computer programming, lazy evaluation is the technique of delaying a computation until the result is required.»
А зачем вам дополнительная анонимная функция понадобилась?
Почему не просто

auto my_func = calc_once(SomeHugeCalculation);

Так выразительней — практически связное предложение получается :)

Да и стрелочка лишняя, можно так:

template
calc_once_func calc_once(LambdaFunc func)
{
return calc_once_func(func);
}

А так — моя версия буста не захотела собираться:

template
class calc_once_func
{
public:
typedef decltype(LambdaFunc) result_type; //(*)

public:
calc_once_func(LambdaFunc func): func_(func) {}
result_type operator()()
{
return val_.is_initialized()? val_.get(): (val_ = func_()).get();
};
private:
boost::optional val_; //1>c:\boost\boost_1_37_0\boost\optional\optional.hpp(110): error C2070: '': illegal sizeof operand

LambdaFunc func_;
};

template
calc_once_func calc_once(LambdaFunc func)
{
return calc_once_func(func);
}
Да и стрелочка лишняя, можно так:
template<typename LambdaFunc>
calc_once_func<LambdaFunc, decltype(LambdaFunc)> calc_once(LambdaFunc func)
{
 return calc_once_func<LambdaFunc, decltype(LambdaFunc)>(func);
}

Так не собралась моя версия буста:

template<typename LambdaFunc>
class calc_once_func
{
public:
  typedef decltype(LambdaFunc) result_type;

public:
 calc_once_func(LambdaFunc func): func_(func) {}
 result_type operator()()
 {
  return val_.is_initialized()? val_.get(): (val_ = func_()).get();
 };
private:
 boost::optional<result_type> val_; //1>c:\boost\boost_1_37_0\boost\optional\optional.hpp(110): error C2070: '': illegal sizeof operand
 LambdaFunc func_;
};

template<typename LambdaFunc>
calc_once_func<LambdaFunc> calc_once(LambdaFunc func)
{
 return calc_once_func<LambdaFunc>(func);
}

int SomeHugeCalculation()
{
  return 7;
}

int _tmain(int argc, _TCHAR* argv[])
{
  auto my_func = calc_once(SomeHugeCalculation);
  if (my_func())
  {

  }

  return 0;
}

* This source code was highlighted with Source Code Highlighter.
Не собирается, потому что decltype(LambdaFunc) — это совсем не то. Для того там и стрелочка чтобы написать decltype(func()) — т.е. тип, который бы вернул объект(функтор) func, в ответ на свою операцию скобочки.
Стрелочка для того чтобы перенести определение возвращаемого значения ф-ции правее, в то место, где входной параметр ф-ции, объект func уже определен и может нам сказать, что он возвращает на операцию скобочки.

А decltype(LambdaFunc) — это идентично просто написать LambdaFunc, или даже просто не имеет значения.
Так то работает:
Да и стрелочка лишняя, можно так:
template<typename LambdaFunc>
calc_once_func<LambdaFunc, decltype(LambdaFunc)> calc_once(LambdaFunc func)
{
return calc_once_func<LambdaFunc, decltype(LambdaFunc)>(func);
}

* This source code was highlighted with Source Code Highlighter.

Ибо:
If the expression parameter is a call to a function or an overloaded operator function, decltype(expression) is the return type of the function. Parentheses around an overloaded operator are ignored.
Первая посылка: компилятор вам заявляет «дружище, что бы у тебя в качестве result_type не было определено, но sizeof я для этого сделать никак не могу».

Вторая посылка: обычно компиляторы не испытывают проблем с sizeof(int).

Вывод: result_type не является типом int.

«If the expression parameter is a call to a function...» — означает «Если вы в скобочках написали что-то, что похоже на вызов ф-ции...».
А вызов ф-ции/функтора обычно выглядит как применение оператора скобочки для объекта ф-ции/функтора (т.е. func()), а не чистое написание типа ф-ции/функтора (LambdaFunc).
template<typename LambdaFunc, typename result_type = decltype(LambdaFunc()())>
class calc_once_func
{

};

Так работает, но Студия 2010 говорит что не стандарт.
Описанный процесс называется мемоизацией. www.botik.ru/~abram/blackhead/s_09_a.ru.html
И в С++ применять его, как мне кажется, нужно с умом. Потому что нельзя контролировать «чистоту» функции от влияния глобальных переменных. А что если они изменятся, а закэшировано будет то же самое.

За пост спасибо!
Sign up to leave a comment.

Articles