GC может быть реализован с указателями сырых данных C++?
Intellij имеет гораздо лучший плагин SVN, чем Subversive или Subclipse, и он работает! Количество времени, которое мы потратили на слияние исходных файлов с использованием Eclipse, не имеет значения. Это не проблема с IntelliJ, потому что плагин поможет вам гораздо больше.
Также плагин Subclipse ненадежен - у нас регулярно бывают случаи, когда плагин не думает, что какой-либо код был зарегистрирован в SVN другими разработчиками, но есть - сервер CI обработал их!
9 ответов
Арифметика указателя не является основной проблемой. Сборщикам мусора приходится постоянно иметь дело с переназначением указателей, и арифметика указателей - еще один пример этого. (Конечно, если бы была разрешена арифметика указателей между указателями, указывающими на разные буферы, это вызвало бы проблемы, но это не так. Единственная арифметика, которую вам разрешено выполнять с указателем, указывающим на массив A, - это те, которые перемещают его в этом массиве.
Настоящая проблема заключается в отсутствии метаданных. Сборщик мусора должен знать, что такое указатель, а что нет.
Если он встречает значение 0x27a2c230 , он должен быть в состоянии определить, является ли он
- указателем (в этом случае он должен следовать за указателем, чтобы пометить адресат как «используемый» рекурсивно)
- Целое число (То же значение является совершенно допустимым целым числом. Возможно, это вовсе не указатель)
- или что-то еще, скажем, бит строки.
Он также должен иметь возможность определить размер структуры. Предполагая, что значение является указателем и указывает на другую структуру, сборщик мусора должен иметь возможность определять размер и размер этой структуры, чтобы он знал, какой диапазон адресов следует сканировать для поиска дополнительных указателей.
У языков с GC есть много инфраструктуры, чтобы справиться с этим. C ++ этого не делает.
Сборщик мусора Бемов наиболее близок к тому, что вы обычно можете получить, и он консервативен в том смысле, что если что-то может быть указателем, сборщик мусора предполагает, что это так, что означает некоторые данные напрасно сохраняется в живых. Таким образом, он, скорее всего, сохранит данные, которые следует собирать в сборку мусора.
В качестве альтернативы, конечно, вся эта инфраструктура , в принципе, может быть добавлена к компилятору C ++. В стандарте нет правила, запрещающего его существование. Проблема в том, что это сильно снизит производительность и исключит множество возможностей оптимизации.
Yes. There was a system at NeXT back in the 1990s that worked like this: they keep track of every C/C++ memory block that has been allocated. Periodically they scan memory to see if the 4-byte (or 8-byte) value associated with that memory address is present. If it isn't, they assume there are no references, and they free the memory. It's neat and easy! But sometimes it screws up.
Here are some other approaches: http://www.hpl.hp.com/personal/Hans_Boehm/gc/
Я пробовал другие сценарии: "makeBricks (8, 1, 13 ) "makeBricks (1, 2, 6)", где либо у вас недостаточно, либо слишком много больших кирпичей, но вам нужны некоторые. Чтобы учесть обе возможности, вам понадобится что-то вроде:
It's written in C not C++, and is not a perfect match for C++ because it does not invoke destructors, but probably fits the bill more or less.
Sure why not? Pointer arithmetic from a garbage collector's perspective is no different than indexing into an array. It's things like the xor doubly linked list that screw up GC, but that's not pointer arithmetic, and undefined behavior besides. Also, Boehm exists, which is sort of empirical evidence, it's a garbage collector that works for C++. Heck for a while there they were threatening to include GC as an optional part of C++0x.
Вопрос в том, зачем вам это? В 90% случаев, когда вы думаете, что сборка мусора была бы хорошей, будет достаточно вектора умного указателя (как в векторе / карте, которая удаляет объект при его удалении). Большая часть остальных 10% может быть обработана с помощью интерфейсов с подсчетом ссылок.
C++ pointer arithmetic allows you to construct N+1 pointers to a T[N], &T[0]...&T[N-1] and a sentinel &T[N-1]+1. These are all pointers to the T[N] array object. In that sense, they are similar to other "interior" pointers such as &foo.bar (address of object member).
Other pointer arithmetic is undefined behavior, and one obvious example of UB could be the unintentional deletion of the array by the GC.
Да, сборщик мусора может быть реализован независимо от безопасности типов, чего C ++ не имеет в значительной степени; но возможности оптимизации, доступные для сборщика мусора, будут ограничены степенью свободы типов, допускаемой языком.
Если кто-то желает жить с операциями с указателями, проверяемыми во время выполнения, тем самым вновь достигая безопасности типов там, где язык отказался, тогда GC может быть намного более агрессивным. Как бы то ни было, сборщик мусора C ++ обычно ограничивается консервативными сборщиками, такими как Boehm-Demers-Weiser GC .
Я не являюсь экспертом по реализации сборщика мусора, но если вы разрешите использование арифметики указателей, вы никогда не сможете быть уверены, что на данный адрес в памяти больше нельзя ссылаться.
как на example
int *crazy_pointer;
srand ( time(NULL) );
while(true) {
crazy_pointer = (int *) rand() % MAX_SIZE_OF_MEMORY:
printf("$d",*crazy_pointer);
}
По сути, я использовал арифметику с указателями самым простым способом, чтобы распечатать содержимое случайных мест в памяти. Это означает, что вся память на машине практически доступна. И если он доступен, он не может быть GCed.
Да, вышеупомянутое, вероятно, вызовет сбой в современных операционных системах, но этот код является совершенно допустимым для C / C ++. Невозможно реализовать сборщик мусора, который мог бы защитить от такого рода злоупотреблений, если вы разрешите арифметику указателей :)