Очень похоже, что стреляли вы из пушек по воробьям. Речь идет об обработке локально сохраненных данных объемом в жалкие пару мегабайт…
Ну либо есть черный пояс в области написания SQL запросов, а самостоятельное написание алгоритмов хромает на обе ноги.
Еще раз о моей позиции, она очень проста.
Я против цирка под названием «new есть зло вселенского масштаба», когда на самом деле надо всего лишь сказать, что иногда make_shared может принести ощутимую пользу вашему приложению.
#1. Не надо путать shared_ptr и make_shared. Мой комментарий был именно о последнем в контексте «радиоактивности» new.
#2. GCC тут вообще не при чем, изначально shared_ptr это зверь из boost.
Если мы говорим о старом коде, до make_shared, то ваш пример должен выглядеть примерно так
foo( std::shared_ptr<Type1>( new Type1( /* arguments for Type1 */) ), std::shared_ptr<Type2>( new Type2( /* arguments for Type2 */) ) );
Не знаю, кто как, но люди, которые моют руки перед едой, так код писать точно не будут. А напишут его, например, так:
std::shared_ptr<Type1> arg0( new Type1( /* arguments for Type1 */) );
std::shared_ptr<Type2> arg1( new Type2( /* arguments for Type2 */) )
foo(arg0, arg1);
Ой! А проблема то с безопасностью исключений как-то сама собой ушла!
что делают не так авторы OSG из статьи выше
Без понятия. А что, именно библиотека OSG является классическим усреднением для некоего типичного C++ кода? С каких пор?
Кстати, предлагаемый костыль make_ref ничего хорошего из себя не представляет, так как лишается главной силы make_shared — возможности экономить на аллокации памяти из кучи.
а что насчет shared_ptr?
Насчет make_shared я сказал — это полезный трюк, но это автоматически не означает, что new это вселенское зло и надо лепить уродливые костыли типа make_unique или make_ref. Никакой связи.
А namespace никто не использует, да?
new T() vs make_unique<T>()
Что я еще должен использовать? Может сделать двухбуквенный using, чтобы эта конструкция выглядела не так уродливо??
Что-то каша какая-то у вас
Каша у тех, кто невнимательно читает чужие комментарии.
Мой комментарий был о том, что можно и нужно смело использовать new и не комплексовать по этому поводу.
А вот тех, кто думает, что пишет на C++, и при этом не используется умные указатели нужно гнать из профессии ссаными тряпками.
shared_ptr — это просто удобный инструмент для работы с долгоживущими объектами
Не надо мне продавать shared_ptr я знаю что это и зачем. Я говорю о том, что если вместо него можно использовать unique_ptr это сильно лучше.
Мое мнение, что история про «радиоактивный» new высосана из пальца и не нужно быть семи пядей во лбу, чтобы понять кто и зачем это сделал.
Смотрим на WinRT API, где вообще на каждый чих и пук у вас появляется новый shared_ptr (в виде ^) и очевидно, что Microsoft, было очень соблазнительно приучить всех пользовать make_shared, дабы сократить количество аллокаций из кучи в практически любой WinRT программе вдвое. Игра стоит свеч.
Вне WinRT мирочка картина получается несколько иная.
#1. Реклама про thread-safe безопасность make_xxx функций не более, чем реклама. На практике очень редко приходится писать выражения, в которых несколько new могут реально породить проблему с исключениями.
#2. В типичной программе на C++ на несколько десятков unique_ptr или scoped_ptr едва приходится один shared_ptr. Соответственно, главного профита от записи make_xxx в виде одного выделения из кучи вы, в подавляющем большинстве случаев использования умных указателей, не получаете.
Если в вашей программе доля shared_ptr сильно больше озвученной — это серьезный повод задуматься, вы явно что-то делаете не так.
#3. В типичной программе подавляющее большинство указателей типа unique_ptr/scoped_ptr это поля класса, а не стековые объекты. Соответственно, даже крошечного бонуса от возможности использовать auto вы тоже не получите. Более того, в списке инициализации или просто в методе, сильно проще писать «new T», чем громоздкое «std::make_unique».
Короче, включайте здравый смысл и голову и не видитесь на хайп, который устраивают граждане из Microsoft.
зы. Хотя, если думать, что вся эта история в целом подтолкнет хотя бы некоторое количество ортодоксов и консерваторов (коих, к сожалению, все еще есть огромное количество) просто к использованию умных указателей, то это, несомненно, будет большая польза… Правда, мое мнение, что лучше весь этот сброд «C/C++ професионалов», которые типа знали С и выучили C++ через два новых для себя слова — class и virtual, согнать в зоопарки и показывать там на потеху публике.
Очевидно, что есть некая «физика», которая диктует то, как в компиляторах языка реализуются те или иные его фичи.
Я, как embedded developer, имел дело с большим числом разных архитектур и компиляторов, и ни разу не сталкивался с какими-то особенностями, из-за которых трюки типа макроса offsetof не будут работать.
Мораль — по бумажкам, т.е. формально, это неопределенное поведение, но на практике я не знаю ни одного компилятора, для которого такие фокусы могут привести хоть к каким-то реальным проблемам.
Умные указатели делают код нечитаемым.
А вот если в функции восемь раз написано «delete p» — это, разумеется, способствует повышению читаемости и надежности кода.
Остается только одни ма-а-а-аленький вопрос — зачем Microsoft херит абсолютно современный и широко используемый API в лице .NET. Ради чего?
Если бы Microsoft так вела себя в 80-х мы бы про эту компанию сегодня вообще бы ничего не знали. Там засели вредители, которые вообще ничего не понимают в индустрии, не ценят чужую работу и много миллионные инвестиции, которые были сделаны в их же платформы!
Опять эти сказки про 120 тыщ приложений. Давайте мерить качество, а не количество. Вот когда Rovio будет свои новые игры синхронно и для WP7 запускать — тогда вернемся к разговору. А тыщи эти мы знаем откуда взялись — пионеры в рамках конкурсов налепили. Дело не хитрое.
И насчет запуска калькулятора. Набрав «ca» его можно было запустить еще в Висте. Кому кнопка «пуск» мешала?
Это просто очередная констатация общеизвестного факта — закон Мура окончательно похерил мирок классического олдскульного embedded, порожденного много много лет назад 8051. Мир праху его.
И сегодня даже какой-то «хеловорд» (типа пару PIO подергать) целесообразнее делать на чем-то 32-х разрядном с Linux, чем на каких-то 8-ми битах. С другой стороны, наверное, сегодня многие такие «хеловорды» как-то даже и не представляют себе, без Ethernet на борту.
Было бы круто, если бы вы, как взрослые, выложили бы все презентации на github и добавили бы на них ссылки из видео.
Ну либо есть черный пояс в области написания SQL запросов, а самостоятельное написание алгоритмов хромает на обе ноги.
Asio, например, расшифровывается как «asynchronous I/O» и никакой это не фреймворк и никакой не потоковый.
Доклад сумбурный, беспорядочный поток сознания.
Я против цирка под названием «new есть зло вселенского масштаба», когда на самом деле надо всего лишь сказать, что иногда make_shared может принести ощутимую пользу вашему приложению.
#1. Не надо путать shared_ptr и make_shared. Мой комментарий был именно о последнем в контексте «радиоактивности» new.
#2. GCC тут вообще не при чем, изначально shared_ptr это зверь из boost.
Если мы говорим о старом коде, до make_shared, то ваш пример должен выглядеть примерно так
Не знаю, кто как, но люди, которые моют руки перед едой, так код писать точно не будут. А напишут его, например, так:
Ой! А проблема то с безопасностью исключений как-то сама собой ушла!
Без понятия. А что, именно библиотека OSG является классическим усреднением для некоего типичного C++ кода? С каких пор?
Кстати, предлагаемый костыль make_ref ничего хорошего из себя не представляет, так как лишается главной силы make_shared — возможности экономить на аллокации памяти из кучи.
Насчет make_shared я сказал — это полезный трюк, но это автоматически не означает, что new это вселенское зло и надо лепить уродливые костыли типа make_unique или make_ref. Никакой связи.
Что я еще должен использовать? Может сделать двухбуквенный using, чтобы эта конструкция выглядела не так уродливо??
Каша у тех, кто невнимательно читает чужие комментарии.
Мой комментарий был о том, что можно и нужно смело использовать new и не комплексовать по этому поводу.
А вот тех, кто думает, что пишет на C++, и при этом не используется умные указатели нужно гнать из профессии ссаными тряпками.
Не надо мне продавать shared_ptr я знаю что это и зачем. Я говорю о том, что если вместо него можно использовать unique_ptr это сильно лучше.
Смотрим на WinRT API, где вообще на каждый чих и пук у вас появляется новый shared_ptr (в виде ^) и очевидно, что Microsoft, было очень соблазнительно приучить всех пользовать make_shared, дабы сократить количество аллокаций из кучи в практически любой WinRT программе вдвое. Игра стоит свеч.
Вне WinRT мирочка картина получается несколько иная.
#1. Реклама про thread-safe безопасность make_xxx функций не более, чем реклама. На практике очень редко приходится писать выражения, в которых несколько new могут реально породить проблему с исключениями.
#2. В типичной программе на C++ на несколько десятков unique_ptr или scoped_ptr едва приходится один shared_ptr. Соответственно, главного профита от записи make_xxx в виде одного выделения из кучи вы, в подавляющем большинстве случаев использования умных указателей, не получаете.
Если в вашей программе доля shared_ptr сильно больше озвученной — это серьезный повод задуматься, вы явно что-то делаете не так.
#3. В типичной программе подавляющее большинство указателей типа unique_ptr/scoped_ptr это поля класса, а не стековые объекты. Соответственно, даже крошечного бонуса от возможности использовать auto вы тоже не получите. Более того, в списке инициализации или просто в методе, сильно проще писать «new T», чем громоздкое «std::make_unique».
Короче, включайте здравый смысл и голову и не видитесь на хайп, который устраивают граждане из Microsoft.
зы. Хотя, если думать, что вся эта история в целом подтолкнет хотя бы некоторое количество ортодоксов и консерваторов (коих, к сожалению, все еще есть огромное количество) просто к использованию умных указателей, то это, несомненно, будет большая польза… Правда, мое мнение, что лучше весь этот сброд «C/C++ професионалов», которые типа знали С и выучили C++ через два новых для себя слова — class и virtual, согнать в зоопарки и показывать там на потеху публике.
Я, как embedded developer, имел дело с большим числом разных архитектур и компиляторов, и ни разу не сталкивался с какими-то особенностями, из-за которых трюки типа макроса offsetof не будут работать.
Мораль — по бумажкам, т.е. формально, это неопределенное поведение, но на практике я не знаю ни одного компилятора, для которого такие фокусы могут привести хоть к каким-то реальным проблемам.
Божественная природа шаблонов видится во всем, начиная с простенькой стандартной sort и заканчивая вещами типа boost MultiIndex.
А вот если в функции восемь раз написано «delete p» — это, разумеется, способствует повышению читаемости и надежности кода.
cdriper.blogspot.com/2011/11/blog-post_25.html
Если бы Microsoft так вела себя в 80-х мы бы про эту компанию сегодня вообще бы ничего не знали. Там засели вредители, которые вообще ничего не понимают в индустрии, не ценят чужую работу и много миллионные инвестиции, которые были сделаны в их же платформы!
И насчет запуска калькулятора. Набрав «ca» его можно было запустить еще в Висте. Кому кнопка «пуск» мешала?
Мой комментарий был скорее о динозаврах, которые боятся двинуться дальше своих любимых восьми бит и надеются, что протянут на них до пенсии.
И сегодня даже какой-то «хеловорд» (типа пару PIO подергать) целесообразнее делать на чем-то 32-х разрядном с Linux, чем на каких-то 8-ми битах. С другой стороны, наверное, сегодня многие такие «хеловорды» как-то даже и не представляют себе, без Ethernet на борту.