Здравствуйте, 11molniev, Вы писали:
_>>Ну то, что компилятор C++ от MS давно отстал от конкурентов и превратился в убогое недоразумение, ни для кого не новость. А вот для компилятора от Intel похоже кто-то забыл включить поддержку C++14... )
1>1>icl /Qstd=c++14 /O2 /Wall main.cpp
1>Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.2.179 Build 20150121
1>Copyright (C) 1985-2015 Intel Corporation. All rights reserved.
1>main.cpp
1>main.cpp(9): error: "auto" is not allowed here
1> auto tuple = [](auto... args)
1>
1>И дальше поехали ошибочки...
Ааа, ну 15-ая версия. Поддержка полиморфных лямбд у них с 16-ой.
1>Можно конечно поливать майкрософт грязью, но из четырех распространенных компиляторов два собирать это отказались. Оставшиеся два выше выдали диаметрально противоположный результат.
Тут вот уже показали, что даже убогий C++ от MS уже поддерживает, просто в последней версии. Так что в итоге поддерживают все четыре.
1>Что на выходе то быть должно? "8 7 6 5 4 3 2 1" или "1 2 3 4 5 6 7 8"? В не отстающем gcc или в не убогом clang баг? 
В данном примере же это не принципиально.
1>Ок, кроме демонстрации лямбд, замыкания, кортежей?
Это не демонстрация работы готовых кортежей (типа std::tuple), а демонстрация рабочей реализации кортежей в пару строк (на полиморфных лямбдах). Разница думаю понятна? ) Естественно никто не собирается использовать такие кортежи в реальной работе, тем более, что есть std::tuple. Пример демонстрирует, что их можно легко создать с помощью такого мощного инструмента, как современные лямбды в C++.
1>Да, действительно на 8-мь элементов. Правда восьмым может быть вложенный кортеж. Но поскольку я дальше двух элементов вроде не уходил не в курсе, насколько это удобно.
Кстати, для двух элементов в C++ есть более удобный std::pair. А много элементов — это удобно, но при условие, что язык поддерживает всякие удобные техники работы с ними (типа автоматического разворачивания в наборы параметров и т.п.).
1>
Это как раз тот пример, где оверхейд сборки мусора ничтожен. Много больших объектов... нет взаимной ссылочности... и нет печальных последствий.
Главный оверхед сборки мусора проявляется не таким тривиальным образом. А запретом на реализацию действительного эффективного кода и плюс недетерминированными задержками.
1>И кстати насчет автоматически и эффективно. Если будет не массив, а свой контейнер к примеру? В Java/C# все действительно будет автоматически, а в C++ напиши ручками все полагающиеся методы value/lvalue/rvalue. Последнее требует немного большей квалификации, поэтому иногда и соглашаются на сборщик мусора. Так проще))
Если хочется тормозное решение повышенной косвенности типа Java/C# то это делается элементарно — shared_ptr. При этом мы даже получим полноценный RAII с детерминированными задержками. Однако для мира C++ это всё равно не эффективное решение. А если хочется реальной эффективности, то надо чуть постараться и реализовать поддержку семантики перемещения. Тем более, что во всех классах из стандартной библиотеки это уже реализовано.
_>>2. У нас есть объект, инкапсулирующий в себе некое соединение по сети и пустой массив такого же типа. Мы хотим положить этот объект в массив. Естественно мы хотим, чтобы при удаление массива все соединения закрывались.
_>> — C: можно наколбасить руками эффективную реализацию
_>> — Java/C#: можно наколбасить руками эффективную реализацию
_>> — C++: работает автоматически и эффективно
_>> — так какой там язык давно имел эффективное автоматическое решение данной проблемы?
1>Ну вот как-то совсем не вкурил разница между Java/C# и C++ тут в чем будет? Пример кода управляемого и нет можно?
Как на Java/C# получить автоматическое закрытие всех соединений сразу после удаления массива? На C++ это будет просто закрытие соединение в деструкторе объекта обёртки.
