Здравствуйте, Огнеплюх, Вы писали:

N>>* что метод помеченный unsafe можно взывать только тоже из unsafe метода.
О>Может имелось ввиду наоборот ? Что например функции kernel.dll ( unsafe ) можно вызывать только из метода помеченным unsafe ?

Тоже неверно. Чтобы использовать P/Invoke не обязательно объявлять метод unsafe.

N>>* что из статического метода нельзя вызвать экземпляный
О>Дык это вроде верно

Тогда экземплярные методы вообще никогда бы не вызывались, так как программа начинает выполнение со статического метода Main.

N>>* при попытке обратиться из финализатора к другому объекту, того объекта уже может не существовать в памяти
О>Естествено, не факт что объект еще жив и не попал в мусороуборочную машину.

Вот я и говорю, что у Троелсена представления на уровне таких предрассудков.
Если код смог получить ссылку на объект, значит объект еще в памяти.

3.9 Automatic memory management
....
if that object, or any part of it, cannot be accessed by any possible continuation of execution, including the running of destructors, the object is considered inaccessible and the object becomes eligible for collection.

Здравствуйте, Хэлкар, Вы писали:

Х>Извините, но то что на С++ концепция замыканий работает по другому еще не повод ругать концепцию C#.

В C++ нет замыканий.

Здравствуйте, Константин Л., Вы писали:

Ну адже если он и усложняется то что? Microsoft сказала "Надо!", программист ответил "Есть!"

Х>>Извините, но то что на С++ концепция замыканий работает по другому еще не повод ругать концепцию C#.

L>В C++ нет замыканий.

ОК, неправильно сказал — имел в виду лямбды/делегаты.

Здравствуйте, Хэлкар, Вы писали:

Х>Здравствуйте, Константин Л., Вы писали:


КЛ>>было, но очевиден ли этот код?

КЛ>>

КЛ>>delegate int d();
КЛ>>d func = null;
КЛ>>foreach(int a in new int[]{1, 2, 3})
КЛ>>   func = delegate { return a; }

КЛ>>d();

КЛ>>

Х>Извините, но то что на С++ концепция замыканий работает по другому еще не повод ругать концепцию C#.

я не ругаю

КЛ>>>>А learning curve? Размер стандарта?
Х>>>

КЛ>>угу

Х>Стандарт С++ имхо ничуть не проще. А сколько людей на нем пишет!

вот и нафига такой второй?

КЛ>>у меня почему-то совсем другое впечатление. может быть потому что я привык к с++...

Х>Так всегда.

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Хэлкар, Вы писали:

Х>>Извините, но то что на С++ концепция замыканий работает по другому еще не повод ругать концепцию C#.

L>В C++ нет замыканий.

в с++0х есть

Здравствуйте, yumi, Вы писали:

Y>Здравствуйте, Константин Л., Вы писали:

КЛ>>Как вам язычок? Возможности? Lazy eval.? Closures? Правила explicit/implicit conv. (особенно для типов-параметров generics)? А learning curve? Размер стандарта?

Y>Вполне себе язык, разве что мне лично очень не хватает паттерн-матчинга и алгебраических типов данных.

КЛ>>пс: каждый день, когда наталкиваюсь на этюды nikov'а в ветке .net, ощущение того, что растет второй c++, укрепляется в моем мозгу. мне становится отчетливо понятно, что чтобы узнать этот язык хорошо и использовать его полноценно, мне нужно потратить еще кучу времени. c# 1.1 был довольно прост, чтобы не заглядывать в lang spec. не подумайте, что я собираюсь поднять панику, просто интересно, что кто думает по этому поводу.

Y>Я кажется Вас понимаю, тут нужно изучать не в глубину, а в ширину. Много различных концепций объединены в 3й шарп, в основном от мира ФП. Надо лишь немного расширить кругозор, изучить какой-либо простенький ФП язык, а когда поймете суть этих концепций, все встанет на свои места.

да нет, с lisp я знакомился 3м курсе института, и идеи фп для меня не новы и не чужды. я именно про глубину

Здравствуйте, Константин Л., Вы писали:

L>>В C++ нет замыканий.

КЛ>в с++0х есть

Толко вот с++0х нет

Здравствуйте, Хэлкар, Вы писали:

L>>В C++ нет замыканий.

Х>ОК, неправильно сказал — имел в виду лямбды/делегаты.

лямбд там тоже нет.

Здравствуйте, Константин Л., Вы писали:

КЛ>да нет, с lisp я знакомился 3м курсе института, и идеи фп для меня не новы и не чужды. я именно про глубину

Ну тогда лучший способ изучить ЯП это начать на нем писать.

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Хэлкар, Вы писали:

L>>>В C++ нет замыканий.

Х>>ОК, неправильно сказал — имел в виду лямбды/делегаты.

L>лямбд там тоже нет.

Блин, я не конкретно лямбды имею в виду. Я имею в виду реализацию замыканий в лямбдах/делегатах C#!

Здравствуйте, Константин Л., Вы писали:

КЛ>удобоваримее с++ да. но, похоже, это только у меня, но я пока не смогу ответить на 90% этюдов nikov'а буду считать что язык знаю плохо.
Ну, если так подходить, то ты и русский язык знаешь плохо. Словарный запас человека ограничен. Количество применяемых слов — на порядок меньше. Значения некоторых слов понимаются из контекста. Однако это не мешает людям общаться. Язык понимается на уровне интуиции. Вот так и С# более интуитивно понятен чем С++. Главное знать идеомы языка, а смысл понятен из контекста. И конечно упомянутая статическая компиляция. Не нужно знать правила приведения типов. Это вполне понимает компилятор. Он вполне хорошо шарит в спецификации. Этого вполне достаточно, чтобы в большинстве случаев, он дал тебе понять что где и как. И этого вполне достаточно чтобы плодотворно работать на благо себя и родины.
Для того чтобы вызубрить спецификации, нужно быть любителем спецификаций. Для того чтобы работать на этом языке, нужно быть просто умным человеком. Иначе придется признать что мы и на русском не можем разговаривать.

КЛ>мне понадобилась куча времени, чтобы хорошо выучить с++.
Везука. А вот мне все равно он преподносит сюрпризы.

Здравствуйте, nikov, Вы писали:

N>

N>3.9 Automatic memory management
N>....
N>if that object, or any part of it, cannot be accessed by any possible continuation of execution, including the running of destructors, the object is considered inaccessible and the object becomes eligible for collection.

Допустим, были объекты A и B, ссылающиеся друг на друга. На объект A была ссылка в Main. Затем эту ссылку занулили. Объекты A и B должны быть подобранны сборщиком мусора и для них должны быть вызваны финализаторы. Получается, что .NET гарантирует, что сначала будут вызваны финализаторы для A и B, и только после этого они будут уничтожены полностью?

Здравствуйте, eao197, Вы писали:

N>>

N>>3.9 Automatic memory management
N>>....
N>>if that object, or any part of it, cannot be accessed by any possible continuation of execution, including the running of destructors, the object is considered inaccessible and the object becomes eligible for collection.

E>Допустим, были объекты A и B, ссылающиеся друг на друга. На объект A была ссылка в Main. Затем эту ссылку занулили. Объекты A и B должны быть подобранны сборщиком мусора и для них должны быть вызваны финализаторы. Получается, что .NET гарантирует, что сначала будут вызваны финализаторы для A и B, и только после этого они будут уничтожены полностью?

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

Здравствуйте, nikov, Вы писали:

E>>Допустим, были объекты A и B, ссылающиеся друг на друга. На объект A была ссылка в Main. Затем эту ссылку занулили. Объекты A и B должны быть подобранны сборщиком мусора и для них должны быть вызваны финализаторы. Получается, что .NET гарантирует, что сначала будут вызваны финализаторы для A и B, и только после этого они будут уничтожены полностью?

N>Гарантируется, что память, занятая объектом, не будет освобождена, пока к какой-то части объекта могут быть обращения из его финализатора или любого другого финализатора.

Так за счет чего это гарантируется:
1. Финализаторы вызываются до освобождения памяти?
2. Объекты A и B вообще не попадают под сборку мусора?
3. Что-то еще?

Здравствуйте, eao197, Вы писали:

N>>Гарантируется, что память, занятая объектом, не будет освобождена, пока к какой-то части объекта могут быть обращения из его финализатора или любого другого финализатора.

E>Так за счет чего это гарантируется:

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

Здравствуйте, nikov, Вы писали:

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

Пока из ваших объяснений я так и не понял, чтоже именно произойдет с объектами A и B. Такое впечатление, что они либо остануться жить вечно, либо их финализаторы гарантированно вызовутся раньше очистки памяти.

Здравствуйте, eao197, Вы писали:

E>Пока из ваших объяснений я так и не понял, чтоже именно произойдет с объектами A и B. Такое впечатление, что они либо остануться жить вечно, либо их финализаторы гарантированно вызовутся раньше очистки памяти.

Почитайте Рихтера CLR via C#, Вам все станет понятно.

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Константин Л., Вы писали:

L>>>В C++ нет замыканий.

КЛ>>в с++0х есть

L>Толко вот с++0х нет

умно

Здравствуйте, eao197, Вы писали:

E>Пока из ваших объяснений я так и не понял, чтоже именно произойдет с объектами A и B. Такое впечатление, что они либо остануться жить вечно, либо их финализаторы гарантированно вызовутся раньше очистки памяти.

Думаю, что это объясняется здесь.

Автор(ы): Игорь Ткачев
Дата: 06.12.2002
Алгоритм работы сборщика мусора (garbage collector, далее просто GC), являющегося частью CLR, подробно описан в книге Джефри Рихтера (Jeffrey Richter) «Applied Microsoft .NET Framework Programming». Мы не будем приводить здесь столь же подробное описание этого алгоритма, но обязательно остановимся на некоторых ключевых моментах.