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

Можно увидеть аналог на C# для данного http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc простейшего кода с полиморфными лямбдами? ) Как только увижу его, можно будет начать разговор об удобстве синтаксиса...

1>>Что на выходе то быть должно? "8 7 6 5 4 3 2 1" или "1 2 3 4 5 6 7 8"? В не отстающем gcc или в не убогом clang баг?
_>В данном примере же это не принципиально.

Собственно на этом можно заканчивать...


_>Это не демонстрация работы готовых кортежей (типа std::tuple), а демонстрация рабочей реализации кортежей в пару строк (на полиморфных лямбдах). Разница думаю понятна? ) Естественно никто не собирается использовать такие кортежи в реальной работе, тем более, что есть std::tuple. Пример демонстрирует, что их можно легко создать с помощью такого мощного инструмента, как современные лямбды в C++.
Да, С++ нереально крут и аналог легкого и мощного Boost.Spirit в C#/Java не сделать.

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

1>> Это как раз тот пример, где оверхейд сборки мусора ничтожен. Много больших объектов... нет взаимной ссылочности... и нет печальных последствий.
_>Главный оверхед сборки мусора проявляется не таким тривиальным образом. А запретом на реализацию действительного эффективного кода и плюс недетерминированными задержками.
Эффективность определяется в первую очередь руками. И на счет эффективности и насчет Stop world — это никак не отменяет, что именно в приведенном примере эти эффекты наблюдать не будут. Ты привел именно тот крайний случай когда все будет близко к паритету, но поскольку не знаком с особенностями строк, работой менеджеров памяти Java/C# и их GC считаешь иначе. Ну или у меня сложилось впечатление, что не знаком.

_>Если хочется тормозное решение повышенной косвенности типа Java/C# то это делается элементарно — shared_ptr. При этом мы даже получим полноценный RAII с детерминированными задержками. Однако для мира C++ это всё равно не эффективное решение. А если хочется реальной эффективности, то надо чуть постараться и реализовать поддержку семантики перемещения. Тем более, что во всех классах из стандартной библиотеки это уже реализовано.
Вот тут то и выплывает, что если хочется энтерпрайзно С++ не так уж и хорош, а том и речь, что бери shared_ptr. А если хочется быстро, то уже нужны мозги.

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