Версия для печати темы

Автор: JONSON Mar 24 2015, 14:10

del

Автор: JONSON Apr 2 2015, 11:39

del

Автор: JONSON May 8 2015, 15:56

не актуально

Автор: Lonnieduh Jun 23 2015, 17:50

Приветствую

Кто-нибудь сталкивался с разработкой ActiveX компонентов для IE. С чего начать, на чем это все пишется?

Автор: грик Aug 3 2015, 14:39

Такой вопрос: если экземпляры классов хранятся в куче, то я правильно понимаю, что статические классы, для которых не могут создаваться экземпляры, будут хранится в стеке?

Автор: Phaust Aug 3 2015, 17:34

Нет, не будут.

Автор: aidanpraid Aug 3 2015, 20:43

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

Автор: грик Aug 3 2015, 21:33

Понял, спасибо.

Автор: Phaust Aug 4 2015, 19:23

Бред

Автор: грик Aug 6 2015, 15:27

Я правильно понимаю, что единственное место, где на физическом уровне хранится статический класс (не переменные этого класса, а именно сам класс, оболочка, если можно так выразиться) - это метаданные типа?
И ещё такой вопрос на счет явной реализации членов интерфейса: почему к ним в классе нельзя обратиться через this, ведь они по книге Троелсена "неявно закрытые", в чем смысл этого ограничения? (можно обратиться только приведя объект к типу интерфейса)

Автор: Phaust Aug 8 2015, 17:51

По моему, спутано все что можно. Что где в какой момент на каком уровне хранится? Ничего не понял. Вы же не думаете что каждый раз когда вы вызываете метод статического класса происходит обращения к диску?


Собачье сердце - Кто на ком стоял?..

Именно сам класс на физическом уровне храниться в файле .cs на накопителе. Экземпляр храниться в куче в памяти.

Второй вопрос вообще не понял, это типа так?

http://piccy.info/view3/8581709/7af3a11ca8f808264f2f762766fb7643/http://i.piccy.info/a3c/2015-08-08-15-50/i9-8581709/576x628-r

Автор: Carnifex Aug 9 2015, 22:35

Давайте так. Дабы не было путаницы. Ты пишешь код. После того как ты нажимаешь кнопку Run компилятор перегоняет его в так называемый Intermediate Language. Потом в машинный код называемый Executable тоесть, по-простому, *.exe. Это простой случай. Касательно классов, они(точнее их объекты), как ссылочные типы, размещаются в управляемой куче (это кусок оперативной памяти). При этом обычные объекты обычных классов размещаются в куче при вызове их конструктора (с исп. new), а статические поля (или даже статические классы) размещаются в High Frequency Heap (высокочастотная куча) после вызова их статических инициализаторов в текстовом порядке (по очереди короче), в момент их вызова или, при наличии статического конструктора, сразу перед вызовом конструктора. В стек (это тоже кусок оперативной памяти, выделяемый операционкой каждому процессу), кстати, идут ссылки на объекты, размещенные в куче. На жестком всегда находится только код. С метаданными в отдельном файле, преобразованный в машинный или в обычном виде, как угодно, но это всегда код. Может быть создана *.dll - но это тоже код.
По поводу this. На данном этапе, не вдаваясь в подробности реализации индексаторов и методов расширения, я рекомендую рассматривать его как ссылку на ЭКЗЕМПЛЯР (ОБЪЕКТ) текущего типа, в котором вы сейчас пишете Ваш код. Написать в коде this - все равно что вызвать конструктор типа и работать уже с объектом.
Если запутались с интерфейсами, рассмотрите их просто как обещание. Обещание того, что класс, который их наследует, будет иметь такие же поля и методы, только уже с реализацией (тоесть с телом) и не приплетайте туда this.

Автор: Phaust Aug 10 2015, 21:48

Это не корректное объяснение. Компилятор компилирует сборки, после чего runtime их загружает и работает с ними. Если не забираться в дебри как то PE/COFF заголовки - процесс неплохо показан здесь http://www.telerik.com/blogs/understanding-net-just-in-time-compilation



ngen же https://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396



Stack frame в clr выделяет под вызов метода. Если мы лезем в дебри то тут надо бы припомнить что каждый процесс имеет свое VAS(и PFD держим в уме) и что есть такой Memory menager,и вообще что кто его знает где эта память была выделена. И про версию CLR помним...

Итого,я рекомендую не лезть в дебри, а писать код. Для начала.

Автор: Carnifex Aug 11 2015, 19:29

Данке за линки. Почитаемс....

А стек мне все равно легче было представить в виде пула адресов в оперативе, выделяемых процессу. Сразу картинка в голове рисуется - гораздо проще учить было. Это как представить ThreadPool с задачами, адресуемыми ему в виде ворот и стада овец)))

Автор: Phaust Aug 11 2015, 21:07

Отличная книжка: http://download.red-gate.com/ebooks/DotNet/Under_the_Hood_of_.NET_Management.pdf

Если, конечно, держать в уме то, что CLR все таки некий уровень абстракции

Автор: грик Aug 12 2015, 11:49

Я имел ввиду после компиляции. Действительно, лучше пока не буду лезть в такие дебри.

Нет, это вот так:

В чем смысл такого ограничения?

Автор: Carnifex Aug 12 2015, 22:59

Все достаточно просто. Усли учитывать что this - ссылка на объект текущего класса (тоесть на экземпляр считай), то в первом случае не компилится, потому что ты в этом объекте ищешь какой-то экземплярный интерфейс, которого там нет и не может быть. А во втором случае все просто и почти адекватно. Ты обращаешься к экземпляру класса (приводя его к интерфейсу, что, по сути, говорит "тип, экземпляр которого указан ключевым словом this должен реализовывать такой-то интерфейс") и вызываешь из него метод, который в нем реализован. Классический вызов метода. Если не считать порнографии с участием this и интерфейса.

Автор: грик Aug 12 2015, 23:07

Это мне и не нравится. Есть какой-то способ обратиться к каждому из методов Do(), не используя приведения к интерфейсу?

Автор: Carnifex Aug 13 2015, 10:23

Я до сих пор не очень понимаю зачем создавать два интерфейса с одинаковыми сигнатурами внутри, но ладно. Обратиться к методам класса внутри класса можно просто по имени метода. Безо всякого this.
this внутри класса мог бы применяться для спецификации полей с одинаковыми именами (в самом простом виде) но зачем его было писать для спецификации методов с и так неодинаковыми именами я особо не понимаю. Да и с одинаковыми именами, но разными сигнатурами тоже его не используют, методы, ведь, допускают полиморфное поведение (перегрузки).
В конечном счете, рассуждая логически, если метод и так виден внутри класса, то, стало быть, зачем явно указывать что это экземплярный метод этого же класса?

Автор: грик Aug 13 2015, 11:48

В базовых библиотеках .NET есть интерфейсы, в которых одинаковые названия методов. Да и пример, когда это логично, можно придумать.

Действительно, не знаю, почему так писал.

Не понял. Все равно вот так не работает:
1) Do(); (понятное дело, он не понимает, какой из методов нужно вызывать)
2) ISmth2.Do();

Автор: Carnifex Aug 13 2015, 13:12

Вы нашли в базовых библиотеках два идентичных интерфейса с разными названиями?

А... Ну так да. Туплю. Чтоб понять в чем тут вопрос, унаследуйте Ваш класс только от одного интерфейса, удалите реализацию методов в класе и снова нажмите правую клавишу и Implement interface (Вы же этим пользовались?). Далее, в методе Foo напишите:
Do();
ISmth1.Do(); ( или если унаследовали от второго ISmth2.Do(); )

И поймете в чем проблема.

Автор: грик Aug 13 2015, 13:31

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

Не понял. Я хочу, чтобы класс реализовывал именно 2 интерфейса. С одним и так понятно.

Автор: Phaust Aug 13 2015, 14:04

Это синтаксис бро, так в стандарте написано. http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf

Автор: грик Aug 13 2015, 14:09

Т.е. нужно смириться и приводить к интерфейсу?

Автор: Phaust Aug 13 2015, 14:29

Нет, нужно не создавать таких интерфейсов с такими именами методов. Это говнокод в чистом виде. Если уж вдруг так случилось, что эти интерфейсы не твои и ты вынужден их реализовывать ты всегда можешь сделать свою обертку надо одним из них

Автор: грик Aug 13 2015, 14:52

Как?

Автор: Carnifex Aug 13 2015, 15:13

2) ISmth2.Do(); - эта запись пытается вытянуть метод из интерфейса. Компилятор не воспринимает это как указание абсолютного имени метода внутри класса. И подобные вещи, как верно сказал Фауст, нужно не допускать, а не холить и лелеять такой подход ища выход из подобных ситуаций.

На счет обертки - ну, я бы сделал так (в студии не проверял).
ISmth1 ismth1 = this as ISmth1;
ISmth2 ismth2 = this as ISmth2;

ismth1.Do();
ismth2.Do();

Правда, я такого еще ни разу не писал))

Автор: грик Aug 13 2015, 16:02

Мне самому не понравилось, в Троелсене был такой пример, потому я и спросить решил.

Работает, но это тоже приведение к типу интерфейса, более громоздкое. Не думаю, что под оберткой имелось ввиду это.

Автор: Carnifex Aug 13 2015, 17:51

Это и не обертка была, просто спецификация методов.
Можно сделать очередное извращение.
public interface ISmth2 : ISmth1
{
Do(); -Этот метод скроет такой же метод родительского интерфейса. А если бы в родительском были другие методы, класс - consumer должен был бы реализовать и методы ISmth1
}

Потом просто унаследовать класс от ISmth2

Автор: Phaust Aug 13 2015, 19:19

Что то типа

если ISmth2.Do() используется в коде класса(!). Хотя тоже, как бы попахивает... Самый правильный подход избегать такого нейминга. Если не удалось-"жизнь это боль и страдания".
Тем не менее, за всю свою практику с подобной необходимостью не сталкивался, что наталкивает меня на мысль что если она у вас возникла-вы что-то делаете не так.

Автор: грик Aug 14 2015, 11:55

Это не подходит, потому реализация методов из разных интерфейсов должна быть разной. Чтобы реализация была одинаковой не обязательно так делать, можно просто не делать явной реализации интерфейса, а просто реализовать один метод в классе под названием Do().

Понял, спасибо.

Автор: Carnifex Aug 14 2015, 12:21

You've got it! )) Конечно это все не подходит! Ровно как и не подходит изначальная задача ни к одному из принципов и паттернов проектирования. Но если мы имеем извращение изначально. Да, к тому же, извращение которое менять нельзя (начальные условия задачи же) - почему бы не извратиться самому

Автор: Corey656 Feb 3 2017, 0:14

Тема мертва?

Видеокурс C# 5.0. От простого к сложному - начал проходить его, очень нравится подача. Что можете посоветовтать ещё почитать, так сказать для закрепления?

Автор: KOCMOHABT Apr 18 2019, 8:04

CLR via C#

Автор: vitallydion Mar 31 2020, 19:51

Уважаемые софорумцы, решил почитать Шидлта С# 4.0.
Читаю одну главу ну никак не могу вехать о чем идет речь, помогите направить мысль в нужное русло.

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

В первой части не изменяется во второй части изменяется, растолкуйте плиз. Вторая часть понятная но первая противоречит второй.