Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> Не выдумывай.
ПК>Твоя самоуверенность меня просто удивляет... Нет, чтобы разобраться, как следует (например, попробовать использовать полученную сборку в соответствующем контексте), продолжаешь упорствовать на ровном месте.
В каком нафиг контексте? Еще раз повторяю, не выдумывай. Верификация процесс описанный.
>> Лучше сообще орлам что компилятор делают. Думаю, они знаю что делать.
ПК>Чтобы убедиться в том, что это сознательно добавленная возможность, а не ошибка, лучше попробуй вернуть в режиме /clr:safe, например, ссылку на локальную переменную, а потом почитай справку о возникшей ошибке:
ПК>
error C4801: Return by reference is not verifiable: gc-lvalue is from an unknown source
ПК>
<...> A reference can only be verifiably returned when it can be tracked by the verifier from creation to return point and when it is a reference to an element of an array, or a member of a class. <...>
Это ничего не доказывает. Еще раз повторяю напиши орлам. Посмотрим что они скажут.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Неверифицируемая стандартным алгоритмом, описанным в спецификации CLI. Но это не означает, что эта операция неверифицируема реализацией Microsoft. В частности, чтобы это проверить, нужно пользоваться не утилитой PEVerify, проверяющей код на верифицируемость стандартным алгоритмом, а попробовать использовать подобную сборку в контексте, где разрешен запуск только верифицируемого кода.
>> и стало быть то, что код с возвратом ссылок компилируется в сэйф-режиме просто на просто баг компилятора.
ПК>Конкретная реализация (например, Microsoft CLR) вполне может
большее количество случаев, как прямо оговарено спецификацией.
Павел, ты совершенно прав. Спецификация говорит совершенно четко о том, что PEVerify реализована с максимальной паранойей, позволенной стандартом. Реализациям фреймворка разрешено быть более либеральными за счет повышения интеллекта. Лазейка оставлена.
Вот только меня настораживают потенциальные проблемы с портируемостью подобного кода. Используя такие решения, ты начинаешь зависеть от реализации фреймворка. Для некоторых приложений это подойдет — например, если мы рассуждаем о встроенном софте для видеокамеры. Там можно не только конкретную реализацию фреймворка, там можно номер билда фиксировать.
Но, опять же, в подобном случае у нас есть полный контроль над софтом, и можно позволить себе аккуратно подписать сборку и попросить при инсталляции выдать ей разрешение на обход верификации. Это будет более надежно, чем надеяться на то, что у верификатора хватит ума понять, что "ничего такого мы в виду не имели".
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Так для фиксированных объектов GC запрещает их перемещение, но при этом есть область этой фиксации, в том числе и передаваемых по ссылке значением.
VD>Ничего он запрещать не должен. Ссылка есть ссылка. Просто если она не на начало объекта, то у ЖЦ прибаляется работы. Он должен хранить информацию, что в таких-то ячейках могут быть ссылки и какого типа эти ссыли, и в придачу, хранить отступ этой самой ссылки от начала объекта. Далее года объекты перемещаются нужно всего лишь корректировать указатели с учетом этих отступов. VD>Отсюда, кстати, и вытекает невозможность размещения ссылок в других объектах. Иначе неясно как и где хранить информацию об отступе.
Рихтер утверждает обратное " ... фиксированные объекты не трогаются GC ". Хотя и в твоем случае я согласен, все зависит от реализации.
Хочется докопаться до истины. Но в твоем случае раз есть привязка к объекту то нет причин делать указатели и ссылки только стековыми.
А привязку например можно сделать ввиде структуры или объекта приведенного мной.
S>> Другая ситуация с возвращаемым по ссылке значениям. В данном случае ссылка сама должна следить за фиксацией объекта а значит и иметь информацию о нем.
VD>Нет там никаких фиксаций. Ну, по крайней мере не должно быть. К тому же ЖЦ четко показывает, что объекты между поколениями перемещаются, а в связи с внутренним устройсвом перемещение объектов между поколением обязано приводить к перемещению объектов в другие области памяти. Таким образом скорее всего врет отладчик. Адрес рельно меняется, но отладчик просто показывает старый ардес.
VD>Короче все это мало чем отличается от работы с указателями в ансэйфе Шарпа.
У меня тоже впечатление, но может ПК доберется до истины.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Рихтер утверждает обратное " ... фиксированные объекты не трогаются GC ". Хотя и в твоем случае я согласен, все зависит от реализации.
Я не знаю откуда это взял Рихтер, да и полную цитату бы хотелось увидеть.
Я говорю об устройстве ЖЦ описанном разработчиками этого самого ЖЦ.
S> Хочется докопаться до истины. Но в твоем случае раз есть привязка к объекту то нет причин делать указатели и ссылки только стековыми. S> А привязку например можно сделать ввиде структуры или объекта приведенного мной.
Я не понял о чем ты говоришь.
VD>>Короче все это мало чем отличается от работы с указателями в ансэйфе Шарпа. S> У меня тоже впечатление, но может ПК доберется до истины.
А чё так зло?
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> например, попробовать использовать полученную сборку в соответствующем контексте
> В каком нафиг контексте?
В контексте, где требуется, чтобы сборка была верифицируемой. Таким образом ты мог бы узнать, как реально работает алгоритм верификации в CLR, а не как он описан в стандарте CLI.
> ПК> Чтобы убедиться в том, что это сознательно добавленная возможность, а не ошибка, лучше попробуй вернуть в режиме /clr:safe, например, ссылку на локальную переменную, а потом почитай справку о возникшей ошибке:
> ПК>
error C4801: Return by reference is not verifiable: gc-lvalue is from an unknown source
> ПК>
<...> A reference can only be verifiably returned when it can be tracked by the verifier from creation to return point and when it is a reference to an element of an array, or a member of a class. <...>
> Это ничего не доказывает. Еще раз повторяю напиши орлам. Посмотрим что они скажут.
Написал. Ответили, что алгоритм верификации в CLR позволяет вызывать функции, возвращающие managed указатели, но удостоверяется, что результат, возвращаемый такой функцией, соответствует определенным требованиям. В общем, как и написано выше по ветке. Дополнительная информация: на эту возможность полагается реализация STL/CLI.
Соответствующие исправления в стандарте CLI ожидаются в некотором будущем. Их обещала подготовить и внести группа, занимающаяся CLR. Изменения, собственно, в стандарт (CLI) попадают небыстро; во всяком случае, значительно медленнее, чем в реализацию (CLR).
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
большее количество случаев, как прямо оговарено спецификацией.
> Павел, ты совершенно прав. Спецификация говорит совершенно четко о том, что PEVerify реализована с максимальной паранойей, позволенной стандартом. Реализациям фреймворка разрешено быть более либеральными за счет повышения интеллекта. Лазейка оставлена.
> Вот только меня настораживают потенциальные проблемы с портируемостью подобного кода. <...>
Да, меня это тоже немного (*) смущало. В скором (**) времени можно ожидать
соответствующие уточнения алгоритма верификации в стандарте CLI.
(*) Я пока скептически отношусь к переносимости .Net приложений (по крайней мере настольных).
(**) "Скором" по меркам процессов стандартизации: подозреваю, что речь шла о следующей версии спецификации.
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> S>Рихтер утверждает обратное " ... фиксированные объекты не трогаются GC ". Хотя и в твоем случае я согласен, все зависит от реализации.
> Я не знаю откуда это взял Рихтер, да и полную цитату бы хотелось увидеть. > Я говорю об устройстве ЖЦ описанном разработчиками этого самого ЖЦ.
Гм... Я смотрю в спецификацию C# (25.3), там написано то же самое:
The address-of operator (§25.5.4) and the fixed statement (§25.6) divide variables into two categories: Fixed variables and moveable variables. Fixed variables reside in storage locations that are unaffected by operation of the garbage collector.
Я туда смотрю?
Насколько я понял fixed в C# == pinned в терминах CLI и pin_ptr в терминах C++/CLI.
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> S>Рихтер утверждает обратное " ... фиксированные объекты не трогаются GC ". Хотя и в твоем случае я согласен, все зависит от реализации.
>> Я не знаю откуда это взял Рихтер, да и полную цитату бы хотелось увидеть. >> Я говорю об устройстве ЖЦ описанном разработчиками этого самого ЖЦ.
ПК>Гм... Я смотрю в спецификацию C# (25.3), там написано то же самое: ПК>
The address-of operator (§25.5.4) and the fixed statement (§25.6) divide variables into two categories: Fixed variables and moveable variables. Fixed variables reside in storage locations that are unaffected by operation of the garbage collector.
ПК>Я туда смотрю?
ПК>Насколько я понял fixed в C# == pinned в терминах CLI и pin_ptr в терминах C++/CLI.
Всё верно. Пиннинг и ввели для того, чтобы можно было на время пришпилить объект, чтобы он не дёргался по хипу, и спокойно ездить по нему указателем, например.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>>Рихтер утверждает обратное " ... фиксированные объекты не трогаются GC ". Хотя и в твоем случае я согласен, все зависит от реализации.
Это в конце статьи по поводу выполнения унманагед кода выделенный для внимания.
VD>>>Короче все это мало чем отличается от работы с указателями в ансэйфе Шарпа. S>> У меня тоже впечатление, но может ПК доберется до истины.
VD>А чё так зло?
Да хочется понять. Плохо что либо делать без понимания.
Кстати хорошо заного прочитывать Рихтера ( а про фиксированные объекты он говорил про унманагед код). Кстати там еще прописал, что если старые объекты не собираются если они еще не преодолели отметку сбора, то при просмотре начиная от корней внутренние поля не просматриваются, а для того чтобы не потнрять эти старые объекты при модификации устанавливается флаг. Поэтому сразу вопросы
1. Уместнее хранить этот флаг в поле SyncBlock а в самом блоке хранить тоже флаг для последующего просмотра ихмененных объектов. Так как старые объекты изменяются нечасто это былобы выгодно. И при этом если объект изменен просто сравнить поле с флагом изменяемости если изменен то не надо прописывать в синкблок иначе прописать.
При сборе мусора пройтись по синкблок таблице и построить дерево достижимых объекто 0 уровня.
При этом подходе не былдо бы такого жуткого write bariera существующего на данном этапе.
2. Указатели в C# можно применять только к структурам не имеющем в своем составе ссылочных типов. А вот что касается ref параметров и ref ссылок тоже вопрос либо если ссылка передается как поле объекта он может сразу помечаться как изменненный при его фиксации либо ссылка сама должна следить за объектом.
Влад если тебе не влом набери этот код. Интересно фиксируются ссылки или нет.
unsafe public class ElementBigArray
{
public byte[] ar;
public int adress;
unsafe public ElementBigArray( int Capacity)
{
ar= new byte[Capacity];
fixed ( byte* p = ar)
{
adress = (int) p;
}
}
}
public class BigArray
{
const int ad = 1;
const int BeginSize = 1 << 10;
public ElementBigArray[] BA;
public BigArray(int Capacity)
{
BA = new ElementBigArray[Capacity];
}
public void Fill(int Begin, int count)
{
for (int i= Begin, j=Begin+count; i<j; i++)
BA[i] = new ElementBigArray(BeginSize+i*ad);
}
public void Прорядить(int Begin, int count)
{
for (int i= Begin, j=Begin+count; i<j; i+=2)
BA[i].ar=null;
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
}
public byte% ПолучитьСсылку(int index)
{
return BA[i].ar[0];
}
unsafe public void CheckAdress(int index)
{
fixed ( byte* p=BA[index].ar)
{
int newadr= (int) p;
if (BA[index].adress == newadr)
throw( new Exception(string.Format(" ?? ????? ?????? {0} <> {1}",BA[i].adress,newadr)));
}
}
}
И соответственно вызов
int sizeBa=1000;
int step = 1000;
BigArray BA = new BigArray(1000);
BA.Fill(0,step);
byte% ссылка= BA .ПолучитьСсылку(step-1);
BA .Прорядить(0,step)
BA.CheckAdress(step-1);
ссылка=1;
При нормальном поведении адреса должны быть разными. Если объек фиксируется мы сразу это поймем
и солнце б утром не вставало, когда бы не было меня
Тогда Поздравляю Всех с Днем Защитников Отечества. Пью не за себя а за Своих Дедов и Прадедов. Как бы там ни было Россияне Великая нация прежде всего своими предками которыми Мы должны соответствовать. Кстати нет смайлика с Водкой. Большое упущение.
Прошу простить меня за излишнюю эмоциональность. Потерял счет ...
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Соответствующие исправления в стандарте CLI ожидаются в некотором будущем. Их обещала подготовить и внести группа, занимающаяся CLR. Изменения, собственно, в стандарт (CLI) попадают небыстро; во всяком случае, значительно медленнее, чем в реализацию (CLR).
Ну, вот когда подобные изменения появятся, то и можно будет говорить о чем-то. А пока есть баг в компиляторе. Опции копиляции не соотвествуют ожиданиям.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
соответствующие уточнения алгоритма верификации в стандарте CLI.
Алгоритым в стандартах никого не интересуют. Есть реальная реализация. И всех интересует присуствие всего что нужно в ней. Это не абстрактый С++ который есть только на бумаге. Это реальная технология.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Гм... Я смотрю в спецификацию C# (25.3), там написано то же самое: ПК>
The address-of operator (§25.5.4) and the fixed statement (§25.6) divide variables into two categories: Fixed variables and moveable variables. Fixed variables reside in storage locations that are unaffected by operation of the garbage collector.
ПК>Я туда смотрю?
ПК>Насколько я понял fixed в C# == pinned в терминах CLI и pin_ptr в терминах C++/CLI.
Интересно про стэк ты не задумывлася?
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
соответствующие уточнения алгоритма верификации в стандарте CLI.
> Алгоритым в стандартах никого не интересуют. Есть реальная реализация. И всех интересует присуствие всего что нужно в ней. Это не абстрактый С++ который есть только на бумаге. Это реальная технология.
Тогда не понимаю, о чем ты вообще говоришь: в конкретной реализации (CLR) верификация допускает вызов функций, возвращающих managed указатели.
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК>Гм... Я смотрю в спецификацию C# (25.3), там написано то же самое: > ПК>
The address-of operator (§25.5.4) and the fixed statement (§25.6) divide variables into two categories: Fixed variables and moveable variables. Fixed variables reside in storage locations that are unaffected by operation of the garbage collector.
> ПК>Я туда смотрю?
> ПК> Насколько я понял fixed в C# == pinned в терминах CLI и pin_ptr в терминах C++/CLI.
> Интересно про стэк ты не задумывлася?
Регулярно. А к чему ты это говоришь в данном случае?
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> Соответствующие исправления в стандарте CLI ожидаются в некотором будущем. Их обещала подготовить и внести группа, занимающаяся CLR. Изменения, собственно, в стандарт (CLI) попадают небыстро; во всяком случае, значительно медленнее, чем в реализацию (CLR).
> Ну, вот когда подобные изменения появятся, то и можно будет говорить о чем-то. А пока есть баг в компиляторе. Опции копиляции не соотвествуют ожиданиям.
Эти изменения уже есть в CLR. Опция компилятора /clr:safe соответствует ожиданиям. А именно: код является верифицируемым с точки зрения CLR. Является ли он верифицируемым с точки зрения упрощенного алгоритма CLI — другой вопрос. Ответ на него дает PEVerify.
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AndrewVK, Вы писали:
AVK>Не все так просто. Ситуация намного хитрее. Команда C# по прежнему уверена что это основной язык для .NET. Команда C++/CLI разумеется считает что основной язык будет C++. Вопрос только в том какая из них победит.
Да. А потом Микрософт, как всегда, всех кинет. И сделает основным языком VB.NET или, что ещё хуже, F#.NET.
Кстати нет смайлика с Водкой. Большое упущение.
