а если мне закрыть надо, а ресурс освобождать нет?
То вероятно это должны быть два разных уровня абстракции.
Никто ж не строит графов обьектов и не проверяет ссылки на них; вызвал кто reset, и все. А если на указатель внутрях еще один unique ссылается?
unique_ptr называется unique не просто так, два unique_ptr не могут ссылаться на один объект. Для таких случаев существует shared_ptr, который ведёт счётчик ссылок и удаляет объект только вместе с последней ссылкой.
Ну и вроде все равно надо явно вызывать что-то типа unique_ptr.reset(nullptr), нет?
Нет, обычно полагаются на вызов деструктора при выходе из скоупа. Вызов unique_ptr::reset() практически полностью аналогичен delete и существует для тех ситуаций, когда вам всё-таки необходимо ручное управление ресурсами.
Статья о сравнении концепций, которые принято применять в C и C++. Да, часть из них реализуется с помощью абстракций, которые не входят в сам язык, но 1) от программиста на C++ обычно ожидается хотя бы поверхностное знакомство с STL 2) другие фреймворки в большинстве своём всё равно либо опираются на STL, либо предлагают аналогичные абстракции — использовать сишные строки или вручную управлять памятью вы наверняка не будете, независимо от фреймворка.
При этом, взять хотя бы вот это обсуждение — тут 80% дискуссии о том, как правильно использовать фишки языка. Не как правильно определить бизнес логику/архитектуру/алгоритмы, а как правилно использовать язык.
А что ещё вы ожидали от комментариев к статье, поднимающей вопрос идеоматичного кода на C++?
я уже давно живу в мире, где есть garbage collectors. Могу много рассказать про преимущества ручного управления памятью в частных случаях
GC и smart pointers — очень разные концепции, и последние покрывают большинство сценариев, где GC уступает ручному управлению.
Имхо, не-пользование unique_ptr это скорее про незнание отдельных аспектов стандартной библиотеки, а не про понимание принципов ооп
Это действительно не имеет никакого отношения к ООП. Это про RAII — гораздо более важную и центральную особенность C++. Не понимать и не использовать RAII == не знать плюсы.
без virtual при delete вызовется только деструктор парента, но не производного, и вы можете получить утечку ресурсов.
Здесь на самом деле всё ещё хуже, такой delete вообще является UB, и, например, в моей практике приводил к memory corruption, после чего любая аллокация могла с некоторым шансом вызвать дедлок.
Насколько я знаю, в США считается, что преступления, совершённые против граждан США должны судиться по американским законам независимо от места действия и гражданства преступника. А там уже разные страны в разной степени с этим соглашаются и иногда экстрадируют, иногда отказывают.
Я конечно извиняюсь, но new&delete с самого начала были именно что с++ фишки
Однако, в современных плюсах их использование есть моветон, а сишникам наверняка проще привыкнуть писать new/delete вместо malloc/free, чем освоить концепцию RAII.
А у вас постоянно встречается ромбовидное наследование, что ли? Это же фу-фу
Причём здесь ромбовидное наследование? Отсутствие виртуального деструктора в любом интерфейсном (абстрактном) классе — это выстрел себе в ногу.
Ну впрочем я пишу в основном что-то алгоритмическое — из файла данные взяли, посчитали, запихнули обратно в файл
Забавное описание. Я вот тем же самым занимаюсь, разве что в «боевой» конфигурации обычно чтение идёт потоком с камер, и результаты передаются какой-нибудь управляющей системе по какому-нибудь специальному интерфейсу. Но этот ввод-вывод совсем незначительную часть кода занимает.
Но если Вы сами по своей воле заходите в холиварное обсуждение и начинаете возмущаться мнениями, отличающимися от Вашего, то это не публикация этих мнений мешает Вам разбираться в своих инструментах или работать с ними, а что-то совсем-совсем другое. :)
Вот я зашёл сюда в надежде почитать об интересных плагинах и о настройке Neovim. Если бы тут была адекватная критика vi*, тоже было бы интересно.
Но нет, большинство комментариев здесь — просто бесполезные высказывания в духе «не пробовал, но осуждаю». От хабра хотелось бы чего-то большего ожидать.
Я тоже не очень люблю отладчики, но определённый класс багов в сколько-нибудь большом проекте без них практически невозможно отловить.
Раньше даже запускал CLion специально чтобы поотлаживать, но потом осознал, что это полная дичь и освоил-таки CLI gdb :)
Наверное, да, был не совсем прав, при грамотно составленном ToS могут что угодно выпиливать, но всё равно не уверен, что риски только репутационные были, наверняка же и у антимонопольных регуляторов могли бы вопросы возникнуть, почему это они без обоснований удаляют со своего хостинга конкурирующий с VS продукт.
Интересно другое. Как в принципе можно изъять код из open source?
Никак. Они просто выкатили апдейт, убирающий эту функцию.
Ну и Гитхаб показал свой звериный оскал.
А гитхаб-то что сделал? Многочисленные форки, восстанавливающие функционал, не удалял, вся дичь происходила исключительно внутри майкросовтовских репозиториев.
Что значит не под открытой лицензией?
Этот код был опубликован под открытой лицензией? Был. А значит его можно использовать в соответствии с условиями этой лицензии.
Да и прямо на гитхабе никто не запретит форк вести, необязательно даже другой хостинг искать.
Мы вобщем-то и не искали, запросили у Huawei, они ответили "обходитесь без HDR". Может быть, просто какие-то сложности взаимоотношений разных подразделений, но с нашей стороны это довольно странно выглядело.
Интересно, что даже когда я работал по контракту на Huawei, то нам не давали доступа к приватным API камеры. Когда мы предложили использовать в нашем приложении HDR снимки (доступные в стандартном приложении камеры), то нам ответили, что готовы обсуждать реализацию HDR нами (через несколько снимков с ручной экспозицией) в рамках следующего контракта, хотя казалось бы, это им уж точно экономически нецелесообразно, зачем им две параллельные реализации HDR?
То вероятно это должны быть два разных уровня абстракции.
unique_ptrназывается unique не просто так, дваunique_ptrне могут ссылаться на один объект. Для таких случаев существуетshared_ptr, который ведёт счётчик ссылок и удаляет объект только вместе с последней ссылкой.Нет, обычно полагаются на вызов деструктора при выходе из скоупа. Вызов
unique_ptr::reset()практически полностью аналогиченdeleteи существует для тех ситуаций, когда вам всё-таки необходимо ручное управление ресурсами.Статья о сравнении концепций, которые принято применять в C и C++. Да, часть из них реализуется с помощью абстракций, которые не входят в сам язык, но 1) от программиста на C++ обычно ожидается хотя бы поверхностное знакомство с STL 2) другие фреймворки в большинстве своём всё равно либо опираются на STL, либо предлагают аналогичные абстракции — использовать сишные строки или вручную управлять памятью вы наверняка не будете, независимо от фреймворка.
А что ещё вы ожидали от комментариев к статье, поднимающей вопрос идеоматичного кода на C++?
Почему? Если вас устраивает подождать своего QR-кода тысячелетие-другое, то вполне рабочий вариант.
Это всё-таки только в огромном QR version 40, да ещё и с минимальным уровнем коррекции ошибок.
Не уверен, что он будет стабильно читаться.
Я просто через compose key все умлауты/акуты набираю. Наверное, это чуть менее удобно, зато для всех языков одна привычная раскладка.
GC и smart pointers — очень разные концепции, и последние покрывают большинство сценариев, где GC уступает ручному управлению.
Это действительно не имеет никакого отношения к ООП. Это про RAII — гораздо более важную и центральную особенность C++. Не понимать и не использовать RAII == не знать плюсы.
Здесь на самом деле всё ещё хуже, такой delete вообще является UB, и, например, в моей практике приводил к memory corruption, после чего любая аллокация могла с некоторым шансом вызвать дедлок.
Насколько я знаю, в США считается, что преступления, совершённые против граждан США должны судиться по американским законам независимо от места действия и гражданства преступника. А там уже разные страны в разной степени с этим соглашаются и иногда экстрадируют, иногда отказывают.
Однако, в современных плюсах их использование есть моветон, а сишникам наверняка проще привыкнуть писать new/delete вместо malloc/free, чем освоить концепцию RAII.
Причём здесь ромбовидное наследование? Отсутствие виртуального деструктора в любом интерфейсном (абстрактном) классе — это выстрел себе в ногу.
Забавное описание. Я вот тем же самым занимаюсь, разве что в «боевой» конфигурации обычно чтение идёт потоком с камер, и результаты передаются какой-нибудь управляющей системе по какому-нибудь специальному интерфейсу. Но этот ввод-вывод совсем незначительную часть кода занимает.
Вот я зашёл сюда в надежде почитать об интересных плагинах и о настройке Neovim. Если бы тут была адекватная критика vi*, тоже было бы интересно.
Но нет, большинство комментариев здесь — просто бесполезные высказывания в духе «не пробовал, но осуждаю». От хабра хотелось бы чего-то большего ожидать.
Когда уже начнут указывать отдельно ошибки первого и второго рода? Вот эта просто «точность» же практически никакой информационной ценности не несёт.
Извиняюсь, а вы и на гей-форумы регулярно заходите и пишете там, что они неправильно всё делают, от такого секса никакого удовольствия нет?
Я тоже не очень люблю отладчики, но определённый класс багов в сколько-нибудь большом проекте без них практически невозможно отловить.
Раньше даже запускал CLion специально чтобы поотлаживать, но потом осознал, что это полная дичь и освоил-таки CLI gdb :)
Наверное, да, был не совсем прав, при грамотно составленном ToS могут что угодно выпиливать, но всё равно не уверен, что риски только репутационные были, наверняка же и у антимонопольных регуляторов могли бы вопросы возникнуть, почему это они без обоснований удаляют со своего хостинга конкурирующий с VS продукт.
Никак. Они просто выкатили апдейт, убирающий эту функцию.
А гитхаб-то что сделал? Многочисленные форки, восстанавливающие функционал, не удалял, вся дичь происходила исключительно внутри майкросовтовских репозиториев.
На мой непросвещённый взгляд, у них нет никаких юридических прав даже со своего же GitHub'а такие форки удалять.
Что значит не под открытой лицензией?
Этот код был опубликован под открытой лицензией? Был. А значит его можно использовать в соответствии с условиями этой лицензии.
Да и прямо на гитхабе никто не запретит форк вести, необязательно даже другой хостинг искать.
Мы вобщем-то и не искали, запросили у Huawei, они ответили "обходитесь без HDR". Может быть, просто какие-то сложности взаимоотношений разных подразделений, но с нашей стороны это довольно странно выглядело.
Интересно, что даже когда я работал по контракту на Huawei, то нам не давали доступа к приватным API камеры. Когда мы предложили использовать в нашем приложении HDR снимки (доступные в стандартном приложении камеры), то нам ответили, что готовы обсуждать реализацию HDR нами (через несколько снимков с ручной экспозицией) в рамках следующего контракта, хотя казалось бы, это им уж точно экономически нецелесообразно, зачем им две параллельные реализации HDR?