Здравствуйте, alex_public, Вы писали:

1>>Как работать то должно? Какую задачу (кроме демонстрации лямбд) этот код должен решить, что на входе, что на выходе?
1>>Ну и как выше подметили, не хотелось бы видеть такое в реальных проектах.

_>Ну то, что компилятор C++ от MS давно отстал от конкурентов и превратился в убогое недоразумение, ни для кого не новость. А вот для компилятора от Intel похоже кто-то забыл включить поддержку C++14... )

icl /Qstd=c++14 /O2 /Wall main.cpp
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.2.179 Build 20150121
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

main.cpp
main.cpp(9): error: "auto" is not allowed here
  auto tuple = [](auto... args)

И дальше поехали ошибочки...

Можно конечно поливать майкрософт грязью, но из четырех распространенных компиляторов два собирать это отказались. Оставшиеся два выше выдали диаметрально противоположный результат.
Что на выходе то быть должно? "8 7 6 5 4 3 2 1" или "1 2 3 4 5 6 7 8"? В не отстающем gcc или в не убогом clang баг?

_>Что касается самого кода, то он демонстрирует альтернативную (т.к. в C++ и так есть std::tuple) реализацию кортежей, на замыканиях. А так же работу с ними (слияние, применение функции). Кстати, этот пример должен быть весьма актуален как раз для C# — там же стандартные кортежи очень забавные, кажется максимум на 8 элементов, да? )))

Какую задачу (кроме демонстрации лямбд) этот код должен решить, что на входе, что на выходе?

Ок, кроме демонстрации лямбд, замыкания, кортежей?

Да, действительно на 8-мь элементов. Правда восьмым может быть вложенный кортеж. Но поскольку я дальше двух элементов вроде не уходил не в курсе, насколько это удобно.


_>>>Фраза "исправили старый косяк" подразумевает, что в тоже время было известно правильное решение. Можно узнать в каком именно языке оно присутствовало? )
1>>Ха! Нужно поискать язык где бы оно отсутствовало. Сам факт лишних копирований был вызван таким подходом к семантике ссылок и увлечением абстракциями ООП. За абстракции всегдла надо платить.

_>Т.е. снова сравниваем разную функциональность? ) Естественно, что если делать убогую реализацию без RAII и со сборщиком мусора, то нет проблем. Два простейших примера:

_>1. У нас есть отдельные строки (по гигабайту каждая, для остроты ощущений) и пустой массив строк. Мы хотим положить одну строку в массив. Но чтобы при этом естественно не происходило копирования гигабайта. Ну и само собой при удаление массива все строки в нём должны удаляться.
_> — C: можно наколбасить руками эффективную реализацию
_> — Java/C#: работает автоматически, но не эффективно (сборщик мусора со всеми печальными последствиями из этого)
_> — C++: работает автоматически и эффективно
_> — так какой там язык давно имел эффективное автоматическое решение данной проблемы?
Это как раз тот пример, где оверхейд сборки мусора ничтожен. Много больших объектов... нет взаимной ссылочности... и нет печальных последствий.
И кстати насчет автоматически и эффективно. Если будет не массив, а свой контейнер к примеру? В Java/C# все действительно будет автоматически, а в C++ напиши ручками все полагающиеся методы value/lvalue/rvalue. Последнее требует немного большей квалификации, поэтому иногда и соглашаются на сборщик мусора. Так проще))

_>2. У нас есть объект, инкапсулирующий в себе некое соединение по сети и пустой массив такого же типа. Мы хотим положить этот объект в массив. Естественно мы хотим, чтобы при удаление массива все соединения закрывались.
_> — C: можно наколбасить руками эффективную реализацию
_> — Java/C#: можно наколбасить руками эффективную реализацию
_> — C++: работает автоматически и эффективно
_> — так какой там язык давно имел эффективное автоматическое решение данной проблемы?
Ну вот как-то совсем не вкурил разница между Java/C# и C++ тут в чем будет? Пример кода управляемого и нет можно?


_>В общем, если подвести итог, то можно сказать, что МП:
_>- в Java/C# просто нет
_>- в C++ есть, криво-косое
_>- в D, Nemerle и т.п. есть, нормальное.

_>Но есть один нюанс: мейнстрим языками тут являются только первые три... )
Понятно. Маленький нюанс ещё в том, что хотя последний язык и является мейнстримом, та часть, что ты называешь метапрограммированием нет. По крайней мере пока.