Здравствуйте, Alxndr, Вы писали:
A>Здравствуйте, StevenIvanov, Вы писали:
SI>>а почему разработчикам компилятора нельзя создать compile-time GC? Неужели (теоретически) компилятор не может определить границ использования тех или иных объектов и сгенерировать код корректного удаления объектов в подходящие моменты?
A>А как будет работать хрестоматийный пример с сериализацией указателей в файл, и последующей десирализацией их оттуда для дальнейшего использования?
на этом хрестоматийном примере упадет система даже с рантайм коллектором.
Здравствуйте, ., Вы писали:
.>StevenIvanov wrote:
>> Ясно. Я правильно понял, что это — NP-полная задача и в принципе >> существующим математическим аппаратом в computer science ее решить >> нельзя? Это уже доказано, я так понимаю? .>Мне кажется, что это вообще алгоритмически неразрешимая задача, типа проблемы останова. .>Скажем .>
.>и что? Компилятор должен уметь доказывать любую теорему?
а вы интересный человек!
вот эта запись "какая_нибудь_сложная_математическая_теорема_верна()" на самом деле или есть алгоритм доказательства этой теоремы...либо бессмыслица.
и потом вы тут же говорите об алгоритмической неразрешимости.
если ваш пример верен, то теорема алгоритмически разрешима.
а если неразрешима, то неверен пример
int* p = new int;
long p1 = reinterpret_cast<long>(*p)&0xFFFFOOOO;
long p2 = reinterpret_cast<long>(*p)&0xOOOOFFFF;
p = 0;
// Alxndr: здесь по вкусу добавляем сериализацию/десериализацию
// #1: no pointer to the int exist here
p = reinterpret_cast<int*>(p1|p2);
// now the int is referenced again.
Здравствуйте, StevenIvanov, Вы писали:
SI>После напряженного рабочего дня возник философский вопрос — а почему разработчикам компилятора нельзя создать compile-time GC?
а чем вот это не compile-time GC?
void foo()
{
vector< shared_ptr<MyObject> > arr;
arr.push_back ( new MyObject() );
arr.push_back ( new MyObject() );
arr.push_back ( new MyObject() );
arr.push_back ( new MyObject() );
// чистить ничего не надо, все деструкторы будут вызваны
}
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, shrecher, Вы писали:
S>>а чем вот это не compile-time GC?
Кё>arr[0].ptr = arr[1] Кё>arr[1].ptr = arr[0]
Кё>и ничего не будет вызвано
Ну да, извесная тема, что циклические ссылки "слабое звено". Нужно внимательно за этим следить.
Здравствуйте, shrecher, Вы писали:
Кё>>и ничего не будет вызвано
S>Ну да, извесная тема, что циклические ссылки "слабое звено". Нужно внимательно за этим следить.
Всё, что требует от программиста дополнительных ненужных ему усилий и необоснованной внимательности — пложое решение.
Вот ты например не заметил, что правильно должно быть Кё>>arr[0]->ptr = arr[1] Кё>>arr[1]->ptr = arr[0]
Так и с циклическими ссылками — рано или поздно упустишь.
Здравствуйте, Кодёнок, Вы писали:
Кё>Всё, что требует от программиста дополнительных ненужных ему усилий и необоснованной внимательности — пложое решение. Кё>Так и с циклическими ссылками — рано или поздно упустишь.
С циклическим ссылками это совсем не напряг, а в C++ нужно быть все время внимательным.
Кё>Вот ты например не заметил, что правильно должно быть
не боись компилятор бы быстро поправил Главное понятно что ты имел ввиду.
изначальный код, тоже не совсем корректный, т.к. обычно конструктор для share_ptr объявляют explicit.
arr.push_back ( new MyObject() ); // ругнется навеное
краткое резюме:
Реализация сборщика мусора времени выполнения тривиальна для ряда случаев, для ряда случаев требует применения механизмов сродни reference-counting'у, для ряда случаев невожможна в принципе.
подробнее:
1) вариант работы в однопоточном окружении.
{
Object * o = ctgc_new Object();
// результат getRandomBoolean считаем случайным булевым значениемif( getRandomBoolean() )
{
handleObject( o );
handleOtherThing();
}
}
здесь в зависимости от устройства handleObject возможны варианты:
— handleObject функция, не сохраняет o, handleOtherThing — "простая, небольшая и быстрая" функция, а о — небольшого размера, тогда можно удалить o после блока if.
— handleObject не сохраняет о, но handleOtherThing — "большая и толстая" функция, и объект о — большого размера (или держит критический системный ресурс, который нужно освободить как можно быстрее). В этом случае нужно удалить объект о как можно быстрее. Компилятору будет необходимо решать оценочную задачу (уровня исскуственного интеллекта) о соотношении характеристик функции handleOtherThing и ресурсов, занимаемых о.
— handleObject функция из внешней библиотеки, поставляемой бабаманей, компилятор "не знает" о том будет или нет внутри удален o. Т.о. решения "статической" сборки мусора нет.
2) Вариант с многопоточностью:
Object * o = new Object();
// второй аргумент функции create_thread предположим передается в качестве параметра в функцию потока,
// передаваемую 1м аргументом
create_thread( thread_func1, o );
create_thread( thread_func2, o );
В этом случае компилятору необходимо либо определить какой поток будет завершен последним, а если он не сможет этого сделать (что очевидно будет происходить в подавляющем большинстве случаев), будет необходимо применение схемы, основанной на, например подсчете ссылок — а в этом случае так же разрешить проблему возможного появления циклических ссылок.
merk wrote:
> а вы интересный человек! > вот эта запись "какая_нибудь_сложная_математическая_теорема_верна()" на > самом деле или есть алгоритм доказательства этой теоремы...либо бессмыслица. > и потом вы тут же говорите об алгоритмической неразрешимости. > если ваш пример верен, то теорема алгоритмически разрешима. > а если неразрешима, то неверен пример
Нет, не нужен алгоритм доказательства. Нужен алгоритм проверки доказательства. Проверить то, что a^n+b^n=c^n выполняется для данных a,b,c,n элементарно, но найти такие a,b,c,n (или доказать, что невозможно найти) для которых выполняется это равенство — называется Великой Теоремой Ферма.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, StevenIvanov, Вы писали:
SI>здесь в зависимости от устройства handleObject возможны варианты:
SI>- handleObject функция, не сохраняет o, handleOtherThing — "простая, небольшая и быстрая" функция, а о — небольшого размера, тогда можно удалить o после блока if.
SI>- handleObject не сохраняет о, но handleOtherThing — "большая и толстая" функция, и объект о — большого размера (или держит критический системный ресурс, который нужно освободить как можно быстрее). В этом случае нужно удалить объект о как можно быстрее. Компилятору будет необходимо решать оценочную задачу (уровня исскуственного интеллекта) о соотношении характеристик функции handleOtherThing и ресурсов, занимаемых о.
Если компилятор сможет определить, что 'o' не сохраняется в handleObject(), то не составит труда просто сгенерировать следующий код. Анализ "сложности" handleOtherThing() видится совершенно излишним.
{
Object * o = ctgc_new Object();
// результат getRandomBoolean считаем случайным булевым значениемif( getRandomBoolean() )
{
handleObject( o );
delete o;
handleOtherThing();
}
else
{
delete o;
}
}
И конечно, понятно, что такая схема релевантна только языков "со сборкой мусора". Например, Java, где такая схема собственно и применяется сейчас. А для С++ не видится путей интергации компайл-тайм удаления.
Единственное, что возможно в С++ в этом плане — это статическая элиминация некоторых операций со счётчиком ссылок на основе move-semantics, и на основе элиминации "лишних" копий объекта (RVO/NRVO).
Здравствуйте, ., Вы писали:
.>merk wrote:
>> а вы интересный человек! >> вот эта запись "какая_нибудь_сложная_математическая_теорема_верна()" на >> самом деле или есть алгоритм доказательства этой теоремы...либо бессмыслица. >> и потом вы тут же говорите об алгоритмической неразрешимости. >> если ваш пример верен, то теорема алгоритмически разрешима. >> а если неразрешима, то неверен пример .>Нет, не нужен алгоритм доказательства. Нужен алгоритм проверки доказательства. Проверить то, что a^n+b^n=c^n выполняется для данных a,b,c,n элементарно, но найти такие a,b,c,n (или доказать, что невозможно найти) для которых выполняется это равенство — называется Великой Теоремой Ферма.
тогда зачем писать — "какая_нибудь_сложная_математическая_теорема_верна()"?
если там просто стоит выражение — f(a,b,c,n);
что очевидно сводимо к f(x).
таким образом вы записали
if (f(x)) ...
else ...
и что мы теперь доказываем и кому при такой эквивалентной записи?
ааа, вы хотите сказать, что не можете делать никаких предположений о множестве состояний state-машины, в случае исполнения некоей формальной функции f(x)...тогда это и нужно сказать, и это будет правильным.
а не привлекать "теорему".
рассуждения большинства авторов тут не очень то и верны.
обобщая нужно говорить примерно так:
программа описывает правила поведения state-машины, число состояний которой если не бесконечно, то может легко превысить число атомов во вселенной в неописуемое количество раз.
очевидно, что вопрос об удалении обьекта заключается в следущем решении-
значим ли данный обьект для вывода всего множества состояний, выводимых из данного состояния stateмашины?
если обьект не значим, его можно удалить в данном состоянии стейтмашины, причем состояние машины не изменится. поскольку обьект незначим.
то есть нужен алгоритм выводящий ВСЕ состояния из данного до финального состояния машины(если оно вообще есть)и показывающий, что при таком выводах обьект X незначим.
при учете что число состояний может превышать... см выше...
очевидно, что такой путь решения не проходит.
обычные сборщики мусора решают эту проблему утверждением во время работы самой машины:
— поскольку в данном состоянии машины на данный обьект нет ссылок, это является досточным, чтобы утверждать — такой обьект не может являться необходимым для будущих состояний state машины в силу недоступности. и обьект удаляется.
Здравствуйте, remark, Вы писали:
R>Если компилятор сможет определить, что 'o' не сохраняется в handleObject(), то не составит труда просто сгенерировать следующий код. Анализ "сложности" handleOtherThing() видится совершенно излишним.
не понятно зачем вообще здесь использовать указатель? Если программист хочет завести очередной указатель он дожен для себя ответить на 2 вопроса:
1. Могу ли вместо указателя использовать ссылку на стековый объект?
2. Если нет в 1 без указателя нельзя, то почему я не могу сделать умный указатель (smart_ptr или auto_ptr)?
Очевидно, что только в очень редких случаях нужны "голые" указатели. К примеру, они создаются библиотечной функцией или требуются в API (CreateThread).
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, remark, Вы писали:
R>>Если компилятор сможет определить, что 'o' не сохраняется в handleObject(), то не составит труда просто сгенерировать следующий код. Анализ "сложности" handleOtherThing() видится совершенно излишним.
S>не понятно зачем вообще здесь использовать указатель? Если программист хочет завести очередной указатель он дожен для себя ответить на 2 вопроса: S>1. Могу ли вместо указателя использовать ссылку на стековый объект? S>2. Если нет в 1 без указателя нельзя, то почему я не могу сделать умный указатель (smart_ptr или auto_ptr)?
S>Очевидно, что только в очень редких случаях нужны "голые" указатели. К примеру, они создаются библиотечной функцией или требуются в API (CreateThread).
Тут разговор не о С++, и не о хороших практиках программирования на С++. А просто абстрактно, о компайл-тайм GC.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, merk, Вы писали:
M>>рассуждения большинства авторов тут не очень то и верны.
R>Ты лучше многопоточную очередь вначале нам покажи
R>http://gzip.rsdn.ru/forum/message/3016916.1.aspx
R>
лучше чем што?
как писать многопоточные очереди, справьтесь товарищ, в инете.
поскольку вам трудно писать даже однопоточные
кстати зачем они вам?
однопоточные очереди говорят о том, что у вас треды связаны в линейную цепь.
отчего становится очевидным, что такие треды сводимы к одному треду, выполняющему общую работу этих тредов.
рефакторизируйте свой софт! а то он чета неэфективен.
и не пишите ненужного кода. :P
Здравствуйте, Alxndr, Вы писали:
A>Здравствуйте, StevenIvanov, Вы писали:
SI>>приведите пожалуйста достаточный пример псевдокода.
A>Ну, как-то примерно так...
A>
int* p = new int;
A>long p1 = reinterpret_cast<long>(*p)&0xFFFFOOOO;
A>long p2 = reinterpret_cast<long>(*p)&0xOOOOFFFF;
A>p = 0;
A>// Alxndr: здесь по вкусу добавляем сериализацию/десериализацию
A>// #1: no pointer to the int exist here
A>p = reinterpret_cast<int*>(p1|p2);
A>// now the int is referenced again.
мда, замечательно. Честно говоря на своей практике ни разу не сталкивался с вот такими "disguised pointers". Ну начнем с того, что технически этот пример не обязательно должен работать всегда, к примеру что будет если размер указателя равен 64 битам?
Здравствуйте, shrecher, Вы писали:
R>>Тут разговор не о С++, и не о хороших практиках программирования на С++. А просто абстрактно, о компайл-тайм GC. S>Так в этом и дело, что создание объекта на стеке или использование умного указателя и есть компайл-тайм GC.
Тут имеется ввиду аналог рантайм GC — гарантированная сборка, не требующая от программиста что-то там отслеживать или избегать. Пусть даже за вычетом искусственно выдуманных случаев с маскировкой указателей. Умные указатели не являются ими потому что не гарантируют сборку.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, remark, Вы писали:
R>>Тут разговор не о С++, и не о хороших практиках программирования на С++. А просто абстрактно, о компайл-тайм GC.
S>Так в этом и дело, что создание объекта на стеке или использование умного указателя и есть компайл-тайм GC.
Создание объекта на стеке *НЕ* есть компайл-тайм GC, это частный случай ручного управления памятью. Рассмотри следующий пример:
int& f()
{
int x = 37;
return x;
}
int main()
{
std::cout << f();
}
C GC этот код должен работать по-определению.
Умный указатель вообще никакого отношения к компайл-тайм не имеет, т.к. он полагается на вычисления в ран-тайм.
Ну и есть языки, где вообще нет "объектов на стеке" и RAII.
