Вы можете описать, что такое «RAII с умными указателями»?

Это мощная идиома C++ и хорошо известный термин в мире C++. Если вы не знаете, я бы предложил задать вопрос (или поискать, возможно, он уже есть).

Он означает, что если вы строго объектно-ориентированы, вы можете полагаться на то, что delete [] будет вызываться для вашего объекта, когда он выпадает из области видимости или на него больше нет ссылок, что должно освободить () любую память и ресурсы для объект держался.

Вы правы, они не «добавляют сборку мусора». Я неправильно прочитал статью.

«Пара функций» верна, C++ не будет использовать полагаться и не произойдет, если не используется (абстракция с нулевой стоимостью). Страуструп сказал (ссылка со страницы в Википедии) сказал My view can be summarized as "C++ is such a good garbage-collected language because it creates so little garbage that needs to be collected".

Рад, что он был воспринят в том духе, в котором был задуман. Я сам склоняюсь к более ручным методам :-)

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

Если вы правильно используете boost :: weak_ptr, циклы ссылок не будут проблемой.

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

@Head Geek - если вы правильно используете язык ассемблера и т.д. (см. Последний абзац ответа Мэтта Дж.).

@gbjbaanb: «в тот момент, когда они выйдут из поля зрения». И наоборот, сборщики мусора могут собирать и собирают значения до того, как они выйдут за пределы области действия, тогда как интеллектуальные указатели с подсчетом ссылок могут сохранять значения до конца своей области действия.

«Если каждый фрагмент памяти, который вы когда-либо выделяли, находится внутри объекта, и на этот объект ссылаются только интеллектуальные указатели, у вас есть что-то близкое к сборке мусора (потенциально лучше)». На самом деле то, что у вас есть буквально, представляет собой форму сборки мусора, хотя и примерно в 1960 году. Наивный подсчет ссылок на основе области видимости примерно в 10 раз медленнее, чем трассирующий сборщик мусора, но в C++ вы можете вручную отказаться от некоторых вычислительных усилий, чтобы сократить разрыв в производительности . flyingfrogblog.blogspot.co.uk/2011/01/…

Грег, не могли бы вы немного расширить свой последний абзац? Мне казалось, что это задача любого распределителя памяти, даже malloc, а не только сборщиков мусора (которые, по сути, выясняют, когда вызывать free () за вас). Но я не профессионал в этом вопросе, хотелось бы более подробного объяснения.

Одно большое потенциальное преимущество gc в производительности заключается в том, что вы можете выделить / освободить за один проход вместо множества. Это действительно зависит от ситуации: в некоторых средах ручное выделение памяти или RAII с настраиваемыми распределителями может быть проще, чем gc.

Аргумент реального времени в любом случае спорный, потому что malloc / free также не имеют гарантии наихудшего случая.

Я думаю, вы делаете взаимоисключающие предположения. Есть несколько аргументов против современных сборщиков мусора, но они требуют, чтобы скомпилированный код и сборщик мусора работали в идеальной гармонии, что практически невозможно с таким языком, как C++.

Единственное, что я надеюсь, что мы не получим, - это объекты Phoenix (похожие на Java). Если финализатор может снова оживить объект. Но во второй раз, когда выполняется сборка мусора, финализатор не запускается.

Как я понял, C++ 09 будет сборщиком мусора способствовать.

Теперь из Википедии: en.wikipedia.org/wiki/C%2B%2B0x#Transparent_garbage_collecti‌ в: «Полная поддержка сборки мусора была возвращена в более позднюю версию стандарта или Технический отчет». Думаю, ты прав. :-)

RAII C++ ограничен и может быть лучше.

xtofl: Как я понял, новые стандарты C++ потребуют, чтобы C++ облегчал сборку мусора / for_memory_alone / - в C++ практически ничего не меняется, за исключением того, что память для объекта фактически не освобождается.

@Ctrl Alt D-1337: Не могли бы вы привести нам несколько примеров «RAII C++ ограничен и может быть лучше»? Есть ли язык с лучшим RAII?

@paercebal - try / finally иногда бывает полезно (но теперь его можно смоделировать с помощью лямбда-выражений), но кроме этого RAII C++ было бы трудно улучшить.

Более того, вам нужны как RAII, так и GC. Одно не исключает другого. Большинство языков с встроенным сборщиком мусора с самого начала также имеют идиомы, подобные RAII. И вы можете подумать, что у вас нет необходимость GC, но кто честно откажется от большего удобства и более высокой производительности, если они доступны? Pervasive GC заставляет вас проектировать и кодировать по-другому, и ваша продуктивность повышается. Еще одно преимущество, которое часто игнорируется, заключается в том, что он также работает лучше!

@Earwicker: Основные языки с GC, которые я знаю (т. Е. Не скриптовые, не нишевые языки), - это Java и C#. В Java вообще нет RAII, а RAII в C# далек от удовлетворительного, если исходить из C++. Тем не менее, у нас есть общая точка зрения: если мы можем себе это позволить, работа на языке, в котором выделение памяти выполняется в фоновом режиме, экономит много времени.

@Earwicker: Вы правы насчет try / finally: иногда мы хотим, чтобы код выполнялся независимо от того, как мы выходим из области видимости, и писать локальную структуру только для того, чтобы ее деструктор выполнял очистку, болезненно. Другое решение - использовать Boost.ScopedExit в boost.org/doc/libs/1_39_0/libs/scope_exit/doc/html/index.htm‌ l ...

@paercebal: FWIW, деревья по определению не могут иметь циклов. Возможно, вы имели в виду «граф» над «деревом». В противном случае хороший ответ

@ Томас Эдинг: Нет, я имею в виду Дерево. (XML) DOM - это структура, подобная дереву, но каждый узел имеет (обычно), помимо списка указателей на его дочерние узлы, указатель на его родительский узел (и, возможно, даже указатель на его узел документа). Это означает, что два узла всегда имеют циклическое отношение. С этим можно справиться либо с помощью классов владельцев для каждого корня (документа?), Либо с помощью комбинации shared_ptr / weak_ptr, либо с помощью GC, что означает, что вы можете удерживать часть или всю DOM, не заботясь о том, какая часть должна быть уничтожена или нет, только установив некоторые указатели на ноль ...

@Thomas Eding: ... Проблема, которая возникает с GC, конечно, заключается в том, что вы держите один крошечный узел DOM, не осознавая, что к нему прикреплено все дерево. Это своего рода утечка. И затем, если по какой-то причине какая-то скрытая часть вашего кода содержит указатель на этот крошечный узел (например, какой-то прослушиватель событий, такой как делегат в C# или анонимный внутренний класс в Java), тогда у вас действительно есть утечка, независимо от GC ... В общем, у всех видов обработки памяти есть свои проблемы ... Хорошая вещь в наличии GC в C++ была бы иметь выбор обработки памяти ... :-)

D - это язык, на котором у вас есть RAII и GC.

Python имеет GC и RAII. Python реализует RAII с диспетчерами контекста, который представляет собой профессиональный протокол, обеспечивающий детерминированное выполнение кода настройки и teardon.

Более простой пример «плавающих» данных - строка. В .NET или Java передача строки не дороже, чем передача целого числа или числа с плавающей запятой, и не требует ни копирования данных, ни синхронизации памяти. Есть ли способ разработать строковый класс на C++, который был бы настолько же эффективным в многопоточных сценариях?

@supercat: используя "const std :: string &"? Если вы не изменяете std :: string, передача константной ссылки в порядке, не требует ни копирования, ни синхронизации ... И если вы хотите изменить ее значение, вы генерируете другую строку на всех языках (с разными затратами) . И если вы хотите его изменить (добавить данные, изменить символ), то версия C++ будет более эффективной. В конце концов, я не уверен, что неизменяемые данные - хороший повод для оправдания сборки мусора. Я что-то пропустил?

@paercebal: Рассмотрим класс class moof { String cache; public String q(int a, String st) { if (trickyFunction(a) cache = b; else b=cache; return b;}. На языке GC этому методу никогда не нужно копировать (или делать что-либо с) содержимое какой-либо строки, и его можно использовать для строк, которые также используются в других потоках, без необходимости синхронизации памяти. Можно ли написать версию на C++ с обоими этими чертами?

@paercebal: неизменяемые ссылочные типы «работают» медленнее, чем изменяемые типы, поскольку каждая операция требует создания нового объекта. С другой стороны, неизменяемые типы в системе сборки мусора могут передаваться так же дешево, как и примитивы. Во многих случаях, когда объект, однажды созданный, будет передаваться много без изменений, эффективным шаблоном является использование изменяемого объекта для создания состояния объекта, а затем создание неизменяемого объекта, инкапсулирующего это состояние. Этот шаблон заканчивается "выигрышем", если объект передается три или более раз, и может быть огромным выигрышем ...

... если часто передают большой объект. Я думаю, что этот шаблон редко встречается в C++, потому что C++ не может эффективно справиться с ним, но я думаю, что в языках GC он иногда может работать намного эффективнее, чем все, что можно было бы сделать без GC.

@paercebal: Я только что добавил ответ с более реалистичным примером использования.

Проблема в том, что одноразовая выкройка спасет не во всех случаях. В C# шаблон «одноразового использования» сложно реализовать правильно (поскольку финализатор может вызываться несколько раз из разных потоков и т. д.), А в Java шаблон «одноразового использования» - это шутка.

И снова, правильное использование интеллектуальных указателей устраняет обе упомянутые вами проблемы.

Правильное использование Boost :: weak_ptr также может устранить проблемы с циклическими структурами данных. Это требует полного понимания того, как работает ваш код, но вы действительно должны иметь такое понимание в любом случае.

@Head Geek: Иногда вы просто не хотите заботиться о какой-то части вашего кода, точно так же, как вы просто не хотите заботиться о том, как std :: string выделяет / освобождает свою внутреннюю строку. Вы хотите, чтобы данные оставались там, пока вы их используете, как бы то ни было, и очищались, когда больше не используются.

Наконец, разработчик класса должен решить, как его освободить, а не попросить пользователя проверить реализацию / документацию класса.

@HeadGeek "правильное использование умных указателей". Не существует такой вещи, как «правильное использование» интеллектуальных указателей. Рассмотрим проблему представления изменяемого графа как структуры данных и автоматического восстановления недостижимых подграфов. Не существует «правильного» способа решить эту проблему с помощью интеллектуальных указателей.

Умные указатели полностью избавляют от необходимости решать, кому принадлежит объект.

@Head Geek: Не совсем так. Если у вас есть 2 объекта, A и B, на которые указывают умные указатели, вы правы. Теперь, если A указывает также на B, и если B указывает также на A, тогда у вас есть проблема, и вы должны решить, кому принадлежит объект, с помощью weak_ptr и / или shared_ptr.

-1 Вы увековечиваете миф о том, что объекты становятся недоступными после того, как выходят из поля зрения.

@JonHarrop: Я C++, с семантикой значений, они являются недоступны, когда находятся вне области видимости. Я должен был упомянуть об этом.

Это верно, но обратное (они достижимы, если они находятся в области видимости) в целом неверно.

«gc видит весь ваш процесс» - 99,99 из которых НЕ являются указателем на ресурс X. Вот почему RAII хорош; он статически ограничивает количество мест, где могут скрываться соответствующие указатели. RAII также позволяет вам напрямую управлять управлением памятью - просто назначьте NULL интеллектуальному указателю.

Вы неправильно понимаете, что я имею в виду: тот факт, что gc может просматривать всю память процесса и не ограничен по объему, означает, что он может освобождать память асинхронно и освобождать несколько объектов «одновременно» (за один проход). Тот факт, что RAII статически ограничивает объем ресурсов, является не только функцией, но и проблемой.

Ближе к правде сказать, что во многих случаях RAII может справиться с тем, что не может выполнить сборка мусора. GC концентрируется на памяти; RAII обрабатывает любые ресурсы. И, насколько я могу судить, умные указатели устраняют ваш аргумент о «хрупкости».

Если вы оберните свои ресурсы в объекты, которые можно собирать, тогда GC также сможет управлять ресурсами. Если вы подкрепите это одноразовым шаблоном, вы сможете освободить ресурсы, с которыми, как вы знаете, закончили.

@Head geek: например, как умный указатель обрабатывает сигналы? Что касается памяти, в большинстве случаев gc намного лучше, чем RAII. Почти каждый язык высокого уровня использует gc, я думаю, это о чем-то говорит.

@Quinane: в зависимости от ресурсов вам нужно детерминированное освобождение. Как правило, для файлов (или блокировок; хотя я думаю, что RAII плохо работает и для потоков), вы хотите точно контролировать, когда вы освобождаете ресурс.

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

@cournape: Мне очень жаль, но этот пример кажется довольно надуманным. Вызов exit () в обработчике сигнала также не позволит сборщику мусора что-либо очистить.

И RAII довольно хорошо работает с резьбовыми замками. Я использую его по этой причине регулярно; Фактически, именно эта ситуация познакомила меня с RAII как концепцией.

@head geek: пример показывает, что RAII может дать сбой, и это его единственная цель. Конечно, вы никогда не стали бы использовать это в реальном коде. Но не возвращаться к вызываемому после того, как sigint происходит в реальном коде: подумайте о том, что ваш код вызывается другим кодом, который вы вообще не можете контролировать и который сам обрабатывает sigint

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

У RAII, без сомнения, есть свои недостатки. Но я не считаю, что сборщик мусора решает их, он просто меняет один набор недостатков на другой.

Да, у них есть разные недостатки, это называется компромиссом :) Но gc решает проблемы, которые RAII не может решить (сохраняемость вне области видимости, как в моем примере, предполагая, что он сразу делает что-то еще, кроме захватывающего), это очень полезный инструмент. Я не уверен, что это было бы так полезно для C++.

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

Утечки ресурсов просто не может произойти, если вы настаиваете на том, чтобы все использовали RAII и интеллектуальные указатели.

Но установление и соблюдение этих правил имеет свою цену, и наличие их в качестве руководящих принципов не означает, что они всегда будут соблюдаться.

И в любом случае утечка памяти при использовании RAII и интеллектуального указателя довольно легко. Например, обработчик сигнала, который изменяет путь кода и никогда не возвращается вызываемому: ни RAII, ни интеллектуальный указатель вам в этом случае не помогут.

Приобретение ресурсов - инициализация: en.wikipedia.org/wiki/Resource_acquisition_is_initialization

Как бы то ни было, даже такой умный сборщик мусора, как .NET, не может предотвратить все утечки ресурсов.

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

Другими словами, это просто костыль для неопытных программистов? :-)

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

+1 за первый правильный ответ, который я видел до сих пор. Технический термин, который вы ищете, - это «проблема восходящего потока», появившийся почти полвека назад. dl.acm.org/citation.cfm?id=1093411

Да, я видел несколько дополнительных библиотек для сборки мусора. Я просто не понимаю, почему они необходимы или желательны в большинстве случаев. Ответы на этот вопрос дали мне (очень) несколько случаев, когда это было бы желательно, поэтому я и спросил.

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

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

На самом деле, множество структур данных и алгоритмов без блокировок и без ожидания намного проще реализовать с помощью автоматического управления памятью. Но, возможно, это бессмысленно, если распределитель не заблокирован или не ожидает, что всегда не так ...

@JonHarrop: только если вы предполагаете, что один распределитель используется для всех потоков, что становится узким местом. Большинство высокопроизводительных схем распределения, хотя и могут иметь блокировку, используют детализированную блокировку. И до тех пор, пока на горячем пути вашего алгоритма без блокировки / ожидания нет распределения, это в любом случае не имеет большого значения.

Я не думаю, что (3) проблема. Что касается цикла: да, область видимости заканчивается в конце цикла, поэтому хранилище переменных, объявленных внутри цикла, не накапливается. На практике я считаю, что управление сроком службы на основе области видимости в высшей степени практично и прекрасно работает в большинстве контекстов. И да, в некоторых случаях (восходящие сообщения, сложный многопоточный обмен данными…).

Никакого рассмотрения unique_ptr -> сбой. Ваш пример vcalls в конце области видимости - это специфическая вещь boost :: shared_ptr, это совсем не обязательно. Кроме того, сборщики мусора хранят мусор намного больше, а не RAII. Не говоря уже о том, что GC имеет некоторые очень серьезные недостатки, такие как недетерминированное разрушение ресурсов, невозможность использования с памятью / ресурсами, отличными от GC, и т. д. Кроме того, ваш пост вводит в заблуждение, потому что он подразумевает, что пользователи RAII сталкиваются с висячими указателями , утечки памяти и двойные удаления, чего не происходит. Короче, ты плохой и неправ.

@DeadMG: "особенная вещь boost :: shared_ptr". Нет, это относится к виртуальным деструкторам. «Сборщики мусора хранят намного больше мусора, чем RAII». Я измерил требования к памяти для движка векторной графики, написанного на C++ и OCaml, и обнаружил, что C++ требует в 5 раз больше памяти, чем OCaml, собирающий мусор, из-за этой проблемы со сборкой на основе области видимости. «Пользователи RAII сталкиваются с висячими указателями, утечками памяти и двойными удалениями, чего у них нет». Использование unique_ptr, когда должно быть два владельца, может оставить висячие указатели. Ссылка подсчета утечек. Нить небезопасного shared_ptr можно дважды удалить.

@JonHarrop: shared_ptr не подразумевает и не требует виртуального деструктора. Использование стирания типа - выбор пользователя. Анекдот из вашей памяти - это логическая ошибка (как ни странно, анекдот). Тривиально очевидно, что у сборщика мусора всегда будет больше мусора, чем у системы, которая освобождает его в тот момент, когда на него нельзя ссылаться. Нет никаких значимых реализаций shared_ptr, не ориентированных на многопоточность, интерфейс unique_ptr не допускает двойного владения, если вы не очень стараетесь, и, честно говоря, циклы ref никогда не возникают.

«Тривиально очевидно, что у сборщика мусора всегда будет больше мусора, чем у системы, которая освобождает его в тот момент, когда на него нельзя ссылаться». Вы увековечиваете распространенный миф об управлении памятью. Подсчет ссылок на основе области действия не освобождает на самом раннем этапе. «Нет никаких значимых реализаций shared_ptr, не поддерживающих потоки». См. BOOST_SP_DISABLE_THREADS. "циклы реф. никогда не появляются". Потому что вы приносите жертвы, чтобы приспособиться к плохим стратегиям управления памятью. Циклы повсеместны на JVM и .NET.

Мне нравится пример. Кстати, вы уверены, что присвоение ссылок атомарно? (Примечание: после небольшого исследования это кажется таким же в C#, и я предполагаю, что это также и в Java: чтобы ваш пример работал на C++, нужно было бы также сделать присвоение указателей атомарным, либо на языке - Я так не думаю - или с помощью std :: atomic)

@paercebal: Назначение ссылок в Java и .NET так же атомарно, как и назначение int [т.е. a=b выполняет атомарное чтение a и атомарную запись b, хотя операция в целом может не быть атомарной]. Ключевое требование, которому указатели C++ не могут удовлетворить, заключается в том, что сборщик мусора должен знать о регистре, в который считывается b во время присваивания (если поток, выполняющий присваивание, отключается на некоторое время, в течение которого b перезаписывается и становится необходим цикл сборщика мусора. , регистр этого потока может быть единственной ссылкой на b где-нибудь во вселенной).

@paercebal: Единственный способ увидеть, что код, подобный приведенному выше, практичен и эффективен в C++ с объектами, слишком большими для эффективного копирования, - это если у класса GCreference было бы некоторое хранилище с быстрым доступом для каждого потока; в этом сценарии a=b может транслироваться в currentThreadTempRef=b.data; a.data=currentThreadTempRef; currentThreadTempRef=null;, и если сборщик мусора сработает в любой точке этого процесса, он сможет просмотреть currentThreadTempRef каждого потока и узнать, что идентифицированные таким образом объекты должны быть закреплены.

Это предполагает, что само присваивание является атомарным. Например, предположим, что один поток выполняет b = c ;, а другой одновременно выполняет a = b ;, причем b является необработанным указателем, совместно используемым двумя потоками. В этот момент b мог быть наполовину записан потоком 1, полностью прочитан потоком 2, а последний наполовину записан потоком 1 (я не предполагаю, что у нас автоматически есть атомарное присвоение указателям в стандартном переносимом C++). Это означает, что поток 2 имеет неверное значение указателя. Я прав?

@paercebal: Вы правы, что помимо предоставления формы локального хранилища потока, платформа должна также гарантировать, что запись указателя, за которой следует чтение, всегда будет видеть либо старое, либо новое значение; кроме того, если кто-то хочет использовать «обычные» хранилища, он должен иметь средство, с помощью которого GC мог бы заставить другие потоки очищать свои кеши и добавить проверку if (gcBusy) gcWait(); в процесс присвоения ссылок. Если предположить, что GC имеет эти полномочия, требование назначения указателя без разделения на сегменты является незначительным по сравнению.

@paercebal: В любом случае, моя основная мысль заключается в том, что приведенный выше метод представляет собой шаблон, который является обычным, эффективным и на 100% безопасным для памяти в Java и .NET, но который было бы очень сложно поддерживать безопасным для памяти способом в C++, даже если реализация имеет доступное эффективное локальное хранилище потока [концепция, которую я хотел бы, широко поддерживалась достаточно эффективно, чтобы критичный по времени код не мог ее избежать].