А, это я знаю, но не задумывался почему. Просто все столько раз повторили, что само собой как-то.

Там он объясняет что происходит в первом и втором случае

это хорошо что все знают ответ, а то мне сегодня на code review пришлось объяснять человеку разницу)

А разве с кучей Вик принтеров не выгоднее делать 2?

Ну это просто очень частая вещь, на ней как-то акцентируют внимание. Вот с make_unique такого прикола само собой нету. Вот его в 11 и не засунули.

А разве с кучей Вик принтеров не выгоднее делать 2?

good point

да, комбинация make_shared и долгоживущего weak_pointer на него приводит к "утечке" памяти

бонусный вопрос: чем плох код f(shared_ptr<T> (new T(...)), g()), помимо производительности?

бонусный вопрос: чем плох код f(shared_ptr<T> (new T(...)), g()), помимо производительности?

Порядок вызова ?

Это я уже не вижу

Порядок вызова ?

можно подробнее?

я возможно слышал у саттера ответ, но могу чушь спороть сори

можно подробнее?

Ну мы не знаем что будет первым Создание указателя или вызов g()

Ну мы не знаем что будет первым Создание указателя или вызов g()

чем это плохо?

чем это плохо?

Я еще не придумал :D

Я еще не придумал :D

:D

Ну если только ты специально сайд эффекты запилишь

Ну если только ты специально сайд эффекты запилишь

предполагается что код с shared_ptr(new(...)) "хуже" чем f(make_shared<T> (...), g()), плохие сайд-эффекты оба варианта будут портить

то есть вопрос звучит как, чем это f(shared_ptr<T> (new T(...)), g()) хуже, чем это f(make_shared<T> (...), g()) кроме производительности ?

да

предполагается что код с shared_ptr(new(...)) "хуже" чем f(make_shared<T> (...), g()), плохие сайд-эффекты оба варианта будут портить

Там если криво все сделать, веселые вещи полезут

предполагается что код с shared_ptr(new(...)) "хуже" чем f(make_shared<T> (...), g()), плохие сайд-эффекты оба варианта будут портить

фрагментация памяти меньше и меньше вероятность потенциальных утечек из-за исключений на конструкторе

это помимо производительности

то есть например делается первый хип аллокейшн new T(...) потом выполняется g() он кидает исключение до того как shared_pointer<T> выполнился и мы получаем утечку?

фрагментация памяти меньше и меньше вероятность потенциальных утечек из-за исключений на конструкторе

++

то есть например делается первый хип аллокейшн new T(...) потом выполняется g() он кидает исключение до того как shared_pointer<T> выполнился и мы получаем утечку?

да, именно так

а если выкинуть g() например. f(shared_ptr<T> (new T(...)) и ловлю исключение в конструкторе. все плохо?

меня просто поплавило внезапно как новичка по идее A a = new A() не должно давать утечку при исключении в конструкторе?

меня просто поплавило внезапно как новичка по идее A a = new A() не должно давать утечку при исключении в конструкторе?

в таких случаях гарантируется что память освободится

разве что деструктор не будет вызван. если плохо написан конструктор будут проблемы

разве что деструктор не будет вызван. если плохо написан конструктор будут проблемы

в идеале, надо стараться по возможности конструкторы делать noexcept

ну или обрабатывать исключение прямо в конструкторе и передавать выше

или так, да

https://isocpp.org/wiki/faq/exceptions#ctors-can-throw

https://channel9.msdn.com/Events/GoingNative/2013/My-Favorite-Cpp-10-Liner

да, он там cinder пиарил на этой конференции

говорил мол затащим графику в стандарт

говорил мол затащим графику в стандарт

только этого там и не хватало

мне понравился его поинт про то, что на его каком-то старинном копе типа коммадора он мог всякие клевые штуки делать в текстовой консоли. цвета изменять там, размер шрифта, а плюсы этого не умеют из коробки.

зачем что-то поддерживать из коробки, если можно сделать в сторонней либе? Стандарт недостаточно раздутый в текущем виде?

консоль - собственной платформы, а не языка. а плюсы рассчитываются на множество платформ, а не на какую то одну конкретную. отсюда прямо следует, что поддержке всякого платформо-специфичного не место в стандарте

*собственность

и правда, зачем нам работа с файлами в стандарте, да?

файловой системой*

одно дело - фундаментальные концепции, другое - украшательства

то, что имеется по работе с файлами - очень примитивно. с++ не умеет полноценно скопировать файл, например

я о том, что будет в с++17. нормальная работа с файловой системой.

мне понравился его поинт про то, что на его каком-то старинном копе типа коммадора он мог всякие клевые штуки делать в текстовой консоли. цвета изменять там, размер шрифта, а плюсы этого не умеют из коробки.

Так почти никто не умеет из коробки.

Так почти никто не умеет из коробки.

с этим я как раз не спорю. не надо этого. я сагрился на вот это > поддержке всякого платформо-специфичного не место в стандарте

не заблуждайтесь, std::filesystem так же примитивна в плане функциональных возможностей

а работу с сетью в 17ых завезут?

Ваще, тут некоторые упорки предлагали ваще Cairo включить в стандарт.

Привет, Саттер.

Ваще, тут некоторые упорки предлагали ваще Cairo включить в стандарт.

м? https://en.wikipedia.org/wiki/Cairo_(operating_system)

Нет, либу.

https://ru.wikipedia.org/wiki/Cairo

а чего бы тогда туда boost всем скопом не воткнуть?)

наверное, потому что буст - полигон для испытаний. зачем втыкать не проверенные решения? а то что прошло испытание практикой - втыкают только в путь

ну вот тому же mpl'ю уже больше 10 лет и он - вполне проверенное решение

просто далеко не любая либа нужна в стандарте

имхо, почти никакая не нужна

решение должно быть не только полезным, но и практичным. что значит быть простым в изготовлении и эксплуатации (ц)Английская королева

это к слову о mpl

ну вот тому же mpl'ю уже больше 10 лет и он - вполне проверенное решение

Томущ лучше рефлексию(

Да и вон boost.hana лучше, чем mpl

рефлексия анонсирована на с++20

Да и вон boost.hana лучше, чем mpl

++

ERROR: S client not available

https://github.com/fffaraz/awesome-cpp

в догонку: https://github.com/rigtorp/awesome-modern-cpp

я понимаю, что о новичках мы никогда особо не думаем, но вот приходит новый человек в плюсы и хочет удалить файл. начинает гуглить и узнает, что язык такого не умеет, дергай апи системы. хочешь перенести на свой мак с рабочей винды - пили ифдефы и переписывай кусок кода второй раз

это реально демотивирует

remove жеж

ещё из сишного наследния

http://www.cplusplus.com/reference/cstdio/remove/

я понимаю, что о новичках мы никогда особо не думаем, но вот приходит новый человек в плюсы и хочет удалить файл. начинает гуглить и узнает, что язык такого не умеет, дергай апи системы. хочешь перенести на свой мак с рабочей винды - пили ифдефы и переписывай кусок кода второй раз

а правильное решение было бы - подключить boost::filesystem

по такой логике, вообще все либы должны со временем включаться в стандарт

пришел новичок, а json с xml нечем прочитать

демотивирует(

не, стоп

http://www.cplusplus.com/reference/cstdio/remove/

согласен, плохой пример. каким-то образом я умудрился не слышать о ней.

пришел новичок, а json с xml нечем прочитать

а что, не демотивирует?

не все. файловая система нормальная быть должна.

а что, не демотивирует?

нет, мотивирует развивать инфраструктуру для third-party библиотек

Алексей, зоопарк файловых систем, вы хотели сказать)

тащить буст ради нормальной работы с фс кроссплатформенной, ну бесит же

Я думаю, проблема в инфраструктуре.

чтобы ответом на вопрос "как сделать x" было "подключи либо y такой-то командой", а не "подожди стандарта c++42, в котором в стандарт включат еще 10 новых библиотек"

Тянуть буст не так уж и легко, что и демотивирует, собственно.

Алексей, вы не поняли. std::filesystem (ну или boost::filesystem) не способны кроссплатформенно полноценно обслужить все потребности для какого нибудь файлового менеджера

Подключай его просто в настройках проекта + инклуд и всё было бы збс.

Писали бы как в расте/хаскеле и бед не знали бы.

ну или хотя бы какой-нибудь менеджер пакетов

cpp install boost::filesystem

ib4: их 100500, но всё око как-то не оч.

А всё потому что структура проекта нефиксированная.

Алексей, вы не поняли. std::filesystem (ну или boost::filesystem) не способны кроссплатформенно полноценно обслужить все потребности для какого нибудь файлового менеджера

а мне не надо все возможности файлового менеджера. мне нужно хотя бы нормальные манипуляции с файлами. одинаковые везде и гарантированно работающие.

Кто во что горазд, и все юзают свои системы сборки и т.д.

Писали бы как в расте/хаскеле и бед не знали бы.

как в расте/хаскелле/руби/питоне/перле/го/жс/жаве/ц#, ты хотел сказать

поитерировать по каталогу, да

как в расте/хаскелле/руби/питоне/перле/го/жс/жаве/ц#, ты хотел сказать

Да, где инфраструктура не отделена от языка.