А разве старый тип std::basic_string не хранил аллокатор, который был указан в шаблоне?
Плюс с размером там не все так однозначно — в некоторых реализациях делают буфер прямо в самой переменной, чтобы короткие строки не ходили за памятью в кучу.
И вообще всегда можно было взять старый тип и специализировать его типом аллокатора, который как раз и ходит в thread storage, чтобы получить инстанс алокатора для текущего треда.
Есть один важный момент, который делает аналогию с PowerPC малопригодной.
Процессоры Intel были существенно быстрее PowerPC тогда и существенно быстрее ARM процессоров сегодня (как минимум, на целом ряде задач). Поэтому будут области, где мак на ARM'е это будет очень серьезный компромисс и плевать, насколько больше он при этом работает от батареи. Да, это может будет относительно небольшая ниша в 20-30%, но вряд ли Apple ее быстро сможет похоронить.
Хотя мы говорим о товарищах, которые когда-то убрали с клавиатуры клавиши курсора, потому что они придумали к компьютеру подключить мышь… от этих любую глупость ждать можно.
Зависит от объема приложения и сложности бизнес-логики. Начиная с какого-то момента общая плюсамя часть кода начинает окупаться и приносить доход.
Представьте себе, например, проект масштабов Microsoft Office.
Ясное дело, что на хеловорлдах такой подоход не выстрелит.
Можно посмотреть на обратную сторону медали — дети богатых людей.
Как часто, они, имея все, включая хорошее образование, оказываются полностью испорченными, с нулевой мотвацией и жаждой прожигать жизнь получая одни удовольствия? Тоже генетика?
Очень похоже, что стреляли вы из пушек по воробьям. Речь идет об обработке локально сохраненных данных объемом в жалкие пару мегабайт…
Ну либо есть черный пояс в области написания 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-х мы бы про эту компанию сегодня вообще бы ничего не знали. Там засели вредители, которые вообще ничего не понимают в индустрии, не ценят чужую работу и много миллионные инвестиции, которые были сделаны в их же платформы!
Плюс с размером там не все так однозначно — в некоторых реализациях делают буфер прямо в самой переменной, чтобы короткие строки не ходили за памятью в кучу.
И вообще всегда можно было взять старый тип и специализировать его типом аллокатора, который как раз и ходит в thread storage, чтобы получить инстанс алокатора для текущего треда.
Процессоры Intel были существенно быстрее PowerPC тогда и существенно быстрее ARM процессоров сегодня (как минимум, на целом ряде задач). Поэтому будут области, где мак на ARM'е это будет очень серьезный компромисс и плевать, насколько больше он при этом работает от батареи. Да, это может будет относительно небольшая ниша в 20-30%, но вряд ли Apple ее быстро сможет похоронить.
Хотя мы говорим о товарищах, которые когда-то убрали с клавиатуры клавиши курсора, потому что они придумали к компьютеру подключить мышь… от этих любую глупость ждать можно.
Представьте себе, например, проект масштабов Microsoft Office.
Ясное дело, что на хеловорлдах такой подоход не выстрелит.
Как часто, они, имея все, включая хорошее образование, оказываются полностью испорченными, с нулевой мотвацией и жаждой прожигать жизнь получая одни удовольствия? Тоже генетика?
Было бы круто, если бы вы, как взрослые, выложили бы все презентации на 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-х мы бы про эту компанию сегодня вообще бы ничего не знали. Там засели вредители, которые вообще ничего не понимают в индустрии, не ценят чужую работу и много миллионные инвестиции, которые были сделаны в их же платформы!