Здравствуйте, 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 54 3 2 1" или "1 2 3 45 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 и т.п. есть, нормальное.
_>Но есть один нюанс: мейнстрим языками тут являются только первые три... )
Понятно. Маленький нюанс ещё в том, что хотя последний язык и является мейнстримом, та часть, что ты называешь метапрограммированием нет. По крайней мере пока.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Учитывая, что большинство корпоративных приложений проводят время, ожидая ответа от СУБД/сети, то никакого выигрыша от перехода на С++ не получишь.
Интересно, трейдинг — это корпоративные приложения? А какой-нибудь АСУ ТП?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>Ха, так это не Embedded DSL — зачем он в теме про МП? Это в точности реализация пункта 2 отсюда http://rsdn.ru/forum/philosophy/6116603.1
. Только вместо собственного лексера и парсера на flex+bizon используется готовое решение на базе компилятора C#. Можно пообсуждать плюсы и минусы подобного решения, но к нашей теме дискуссии это пример явно не относится.
Это Embedded DSL. Может ты под этим что-то свое понимаешь, но тогда давай определение своих терминов.
_>Да, т.к. изначально шаблоны не были предназначены для МП, то оно получилось в C++ весьма кривым. Но при этом есть существенный нюанс: вся сложность проявляется при создание соответствующего МП кода (т.е. лежит на авторах библиотек), а вот использование его обычно не существенно сложнее (вот разве что сообщения об ошибках бывают печальные, и то если авторы библиотеки не озаботились этим вопросом). Ну и в любом случае даже кривой инструмент лучше никакого (как у остальных мейнстрим языков). )))
Использование их вообще кошмар. Ну сообщает оно, что в вариадик темплейте какая-то ошибка. И что?
У остальных "мейстрим" языков нет никакой проблемы, потому что нет привязки к языку. Ничего не мешает писать часть на c#, часть на f# часть на хоть на том же с++. Предоставляя в совокупности гораздо более мощный инструмент, чем любые шаблоны. В с++ же полный ад. Проблемы возникают даже внутри с++. Хочется использовать VS2015 и с++14? Будешь сидеть на VS2012, просто потому что какой-нибудь производитель библиотеки не считает нужным поддерживать что-то новее.
Здравствуйте, Ops, Вы писали:
SVZ>>Учитывая, что большинство корпоративных приложений проводят время, ожидая ответа от СУБД/сети, то никакого выигрыша от перехода на С++ не получишь.
Ops>Интересно, трейдинг — это корпоративные приложения? А какой-нибудь АСУ ТП?
А какой-нибудь САПР? А како-нибудь биллинг, а (подставить по вкусу)?
Что ты хочешь услышать?
Да, есть нагруженный софт. К нему и требования не такие, как к ERP.
Дабы не скатываться в офтопик расскажи лучше, выиграет ли этот софт, если С++, по мысли ТС, "прокачать" до Явы — навертеть стандартную либу, расширить язык (непонятно, правда, в какую сторону).
Моё ИМХО — нет, не выиграет. Только инструмент (С++) будет испорчен.
Для таких приложений возможно подошел бы D, но он пока сырой и непонятно, взлетит ли.
Существующего С++ вполне хватает. Да, выше трудоемкость, нужна более высокая квалификация разработчиков. Но об этом коллеги уже высказались.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А какой-нибудь САПР? А како-нибудь биллинг, а (подставить по вкусу)? SVZ>Что ты хочешь услышать?
Что все-таки не большинство ждет базу.
SVZ>Да, есть нагруженный софт. К нему и требования не такие, как к ERP.
Угу. ERP — это электронное перекладывание бумажек, и это далеко не всегда основное занятие бизнеса. SVZ>Дабы не скатываться в офтопик расскажи лучше, выиграет ли этот софт, если С++, по мысли ТС, "прокачать" до Явы — навертеть стандартную либу, расширить язык (непонятно, правда, в какую сторону).
Либу — только за, при условии низкой связности модулей. 100500 велосипедов, раскиданных по разным крупным библиотекам, реально задалбывают, и часто вынуждают писать свои велосипеды под проект. Но тут другая сложность, в отличие от явы с дотнетом, здесь мы имеем неповоротливый комитет и кучу формалистики, для подобной библиотеки такой подход нежизнеспособен. Да, есть буст, который развивается по гораздо лучшей модели, но там уже начинается коллективное безответственное с поддержкой некоторых библиотек. Ну и до сих пор слышу про его категорическое неприятие и запрет в некоторых проектах, из которых процент аргументированных в окрестностях 0.
SVZ>Моё ИМХО — нет, не выиграет. Только инструмент (С++) будет испорчен.
С чего вдруг он будет испорчен? При всех его минусах, библиотекой с ним ничего не сделаешь.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Stanislav V. Zudin, Вы писали:
Ops>Угу. ERP — это электронное перекладывание бумажек, и это далеко не всегда основное занятие бизнеса. SVZ>>Дабы не скатываться в офтопик расскажи лучше, выиграет ли этот софт, если С++, по мысли ТС, "прокачать" до Явы — навертеть стандартную либу, расширить язык (непонятно, правда, в какую сторону). Ops>Либу — только за, при условии низкой связности модулей. 100500 велосипедов, раскиданных по разным крупным библиотекам, реально задалбывают, и часто вынуждают писать свои велосипеды под проект. Но тут другая сложность, в отличие от явы с дотнетом, здесь мы имеем неповоротливый комитет и кучу формалистики, для подобной библиотеки такой подход нежизнеспособен. Да, есть буст, который развивается по гораздо лучшей модели, но там уже начинается коллективное безответственное с поддержкой некоторых библиотек. Ну и до сих пор слышу про его категорическое неприятие и запрет в некоторых проектах, из которых процент аргументированных в окрестностях 0.
Идея в том, что если:
1) добавить в stl(или stl_full) поддержку HTTP, SSL, и проч.
2) сделать системы сборки более интуитивными
3) по вкусу, добавить учет памяти. Например в Objective-C отключаемый учет ссылок.
4) на правах флейма: убрать C++11 и C++14
То получится инструмент, подходящий для корпоративных приложений, который все умеет, быстрый, и который легко использовать как Java.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[17]: так все же gcc или clang компилирует этот код правильно?
Здравствуйте, 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 54 3 2 1" или "1 2 3 45 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++ это будет просто закрытие соединение в деструкторе объекта обёртки.
Здравствуйте, Poopy Joe, Вы писали:
_>>Ха, так это не Embedded DSL — зачем он в теме про МП? Это в точности реализация пункта 2 отсюда http://rsdn.ru/forum/philosophy/6116603.1
. Только вместо собственного лексера и парсера на flex+bizon используется готовое решение на базе компилятора C#. Можно пообсуждать плюсы и минусы подобного решения, но к нашей теме дискуссии это пример явно не относится. PJ>Это Embedded DSL. Может ты под этим что-то свое понимаешь, но тогда давай определение своих терминов.
Это обычный DSL, правда реализованный сомнительным способом — с помощью некого препроцессора перед компилятором C#. Если это EDSL, то тогда можно будет вставить все эти куски с when и т.п. внутрь нормального C# кода и он нормально соберётся? )
PJ>Использование их вообще кошмар. Ну сообщает оно, что в вариадик темплейте какая-то ошибка. И что?
А в чём кошмар? ) Я вот легко использую тот же Boost.Spirit и не испытываю никаких сложностей. Более того, мне при этом даже не требуются какие-то знания о техниках метапрограммирования.
PJ>У остальных "мейстрим" языков нет никакой проблемы, потому что нет привязки к языку. Ничего не мешает писать часть на c#, часть на f# часть на хоть на том же с++. Предоставляя в совокупности гораздо более мощный инструмент, чем любые шаблоны. В с++ же полный ад. Проблемы возникают даже внутри с++. Хочется использовать VS2015 и с++14? Будешь сидеть на VS2012, просто потому что какой-нибудь производитель библиотеки не считает нужным поддерживать что-то новее.
Здравствуйте, lpd, Вы писали:
lpd>Идея в том, что если: lpd>1) добавить в stl(или stl_full) поддержку HTTP, SSL, и проч.
Я написал про проблемы добавления в стандартную либу. Но да, идея вполне нормальная. lpd>2) сделать системы сборки более интуитивными
Какие ваши предложения? Даже если сделать стандартную систему сборки, останутся еще гигатонны легаси, под нее не приспособленные. lpd>3) по вкусу, добавить учет памяти. Например в Objective-C отключаемый учет ссылок.
Этого не понял. Подсчет ссылок есть у shared_ptr. lpd>4) на правах флейма: убрать C++11 и C++14
Зачем? Тебя ж никто не заставляет использовать эти фичи. А многим это сильно упрощает жизнь. lpd>То получится инструмент, подходящий для корпоративных приложений, который все умеет, быстрый, и который легко использовать как Java.
Легко использовать никогда не получится, придется все же учить.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, lpd, Вы писали:
lpd>>Идея в том, что если: lpd>>1) добавить в stl(или stl_full) поддержку HTTP, SSL, и проч. Ops>Я написал про проблемы добавления в стандартную либу. Но да, идея вполне нормальная. lpd>>2) сделать системы сборки более интуитивными Ops>Какие ваши предложения? Даже если сделать стандартную систему сборки, останутся еще гигатонны легаси, под нее не приспособленные.
Слышал но не видел, что у Java удобные системы сборки. В любом случае make несколько стар. lpd>>3) по вкусу, добавить учет памяти. Например в Objective-C отключаемый учет ссылок. Ops>Этого не понял. Подсчет ссылок есть у shared_ptr.
Кроме подсчета ссылок в Objective-C память очищается когда счетчик ссылок объекта оказывается=0. Правда, есть некоторые проблемы с круговыми ссылками. Но виртуальная машина только для сборки мусора- это перебор. lpd>>4) на правах флейма: убрать C++11 и C++14 Ops>Зачем? Тебя ж никто не заставляет использовать эти фичи. А многим это сильно упрощает жизнь.
Если один программист будет использовать эти фичи в проекте, то остальным прийдется их учить. Что имхо невыносимо ибо на бесполезно, т.к. С++14/11 добавляют в С++ примерно тоже количество новых синтаксических конструкций, которое было в исходном С++; при этом мало в чем реально помогая. C++14 может и красив, но только для ценителей языков программирования. lpd>>То получится инструмент, подходящий для корпоративных приложений, который все умеет, быстрый, и который легко использовать как Java. Ops>Легко использовать никогда не получится, придется все же учить.
Имеется ввиду, что, например, менеджер памяти облегчает отладку, а система сборки может быть интуитивна.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Идея в том, что если: lpd>1) добавить в stl(или stl_full) поддержку HTTP, SSL, и проч.
Теоретически не плохая мысль. Однако на практике я знаю десяток самых эффективных реализаций данного дела и все они написаны как раз на C/C++ — какую из них выбрать канонической? )
lpd>2) сделать системы сборки более интуитивными
Что-то мне кажется, что здесь имеет место путаница между системами сборки и системами управления зависимостями. Просто в мире Java эти сущности часто совмещены в один инструмент. А в C++ не так. Систем сборок здесь полно и многие поудобнее вариантов из Java (к примеру я предпочитаю waf, который наследник scons'a). А вот с зависимостями действительно всё очень печально и делается только руками.
lpd>3) по вкусу, добавить учет памяти. Например в Objective-C отключаемый учет ссылок.
Если хочется подсчёт ссылок, то чем не подходит std::shared_ptr? )
lpd>4) на правах флейма: убрать C++11 и C++14
Бред.
lpd>То получится инструмент, подходящий для корпоративных приложений, который все умеет, быстрый, и который легко использовать как Java.
В принципе на C++ можно программировать и без низкоуровненого кода (игр с указателями в C стиле) и без шаблонной магии. Тогда он действительно становится похож на Java. В этом смысле весьма показателен фреймворк Qt. Когда с ним работаешь (вынужденно, ради кроссплатформенного GUI), то прямо создаётся впечатление, что пишешь на Жабке. ))) Вопрос только в востребованности подобных решений.
Re[18]: так все же gcc или clang компилирует этот код правильно?
Можно увидеть аналог на C# для данного http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc простейшего кода с полиморфными лямбдами? ) Как только увижу его, можно будет начать разговор об удобстве синтаксиса...
1>>Что на выходе то быть должно? "8 7 6 54 3 2 1" или "1 2 3 45 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# это будет просто закрытие соединений в деструкторе объекта обертки? Я вообще потому и прошу пример кода, что в упор не вижу разницы.
Здравствуйте, 11molniev, Вы писали:
1>Собственно на этом можно заканчивать...
Ну т.е. в итоге так и записываем: лямбды в C# не сравнимо слабее по функциональности C++ реализации.
_>>Главный оверхед сборки мусора проявляется не таким тривиальным образом. А запретом на реализацию действительного эффективного кода и плюс недетерминированными задержками. 1>Эффективность определяется в первую очередь руками. И на счет эффективности и насчет Stop world — это никак не отменяет, что именно в приведенном примере эти эффекты наблюдать не будут. Ты привел именно тот крайний случай когда все будет близко к паритету, но поскольку не знаком с особенностями строк, работой менеджеров памяти Java/C# и их GC считаешь иначе. Ну или у меня сложилось впечатление, что не знаком.
Stop world шёл у меня отдельным пунктом (недетерминированные задержки). А неэффективность появляется в других местах: повышенная косвенность (это критично для современных процессоров, т.к. данные начинают идти не из кэша), невозможность нормальной работы с указателями (т.е. недоступны самые эффективные техники типа арифметики указателей и SIMD) и т.д. и т.п.
1>Вот тут то и выплывает, что если хочется энтерпрайзно С++ не так уж и хорош, а том и речь, что бери shared_ptr. А если хочется быстро, то уже нужны мозги.
А с этим никто и не спорил.
_>>Как на Java/C# получить автоматическое закрытие всех соединений сразу после удаления массива? На C++ это будет просто закрытие соединение в деструкторе объекта обёртки. 1>На Java/C# это будет просто закрытие соединений в деструкторе объекта обертки? Я вообще потому и прошу пример кода, что в упор не вижу разницы.
Ну так а в какой момент будет вызван этот самый деструктор? )))
Здравствуйте, lpd, Вы писали:
lpd>Слышал но не видел, что у Java удобные системы сборки. В любом случае make несколько стар.
Так что с легаси-то делать? lpd>Если один программист будет использовать эти фичи в проекте, то остальным прийдется их учить. Что имхо невыносимо ибо на бесполезно, т.к. С++14/11 добавляют в С++ примерно тоже количество новых синтаксических конструкций, которое было в исходном С++; при этом мало в чем реально помогая. C++14 может и красив, но только для ценителей языков программирования.
То же самое про старые плюсы: если один программист будет использовать многоэтажного Александреску...
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Это как раз тот пример, где оверхейд сборки мусора ничтожен. Много больших объектов... нет взаимной ссылочности... и нет печальных последствий.
