C# для новичков, вопросы и ответы Опции

[Tyomniy]

Тут я предлагаю все новичкам программирования на C# выкладывать свои вопросы. По возможности, я думаю, все кто в этом что-то шарит будут стараться отвечать !

Тема для обговорення мови програмування C#, всі сторонні коментарі будуть видалятися, а їх автори отримувати %

Сообщение отредактировал BoyKot - Jun 11 2008, 20:40

[JONSON]

del

Сообщение отредактировал JONSON - Aug 14 2015, 10:38

[JONSON]

del

Сообщение отредактировал JONSON - Aug 14 2015, 10:38

[JONSON]

не актуально

Сообщение отредактировал JONSON - May 18 2015, 11:46

[Lonnieduh]

Приветствую

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

[грик]

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

Сообщение отредактировал грик - Aug 3 2015, 15:04

[Phaust]

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

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

[aidanpraid]

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

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

[грик]

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

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

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

[Phaust]

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

Бред

[грик]

Бред

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

Сообщение отредактировал грик - Aug 6 2015, 16:20

[Phaust]

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

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


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

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

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



Сообщение отредактировал Phaust - Aug 8 2015, 17:58

[Carnifex]

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

Сообщение отредактировал Carnifex - Aug 9 2015, 22:44

[Phaust]

После того как ты нажимаешь кнопку Run компилятор перегоняет его в так называемый Intermediate Language. Потом в машинный код называемый Executable тоесть, по-простому, *.exe.

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

На жестком всегда находится только код. С метаданными в отдельном файле, преобразованный в машинный или в обычном виде, как угодно, но это всегда код. Может быть создана *.dll - но это тоже код.

ngen же https://msdn.microsoft.com/en-us/library/6t...ror=-2147217396

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

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

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

[Carnifex]

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

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

Сообщение отредактировал Carnifex - Aug 11 2015, 19:47

[Phaust]

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

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

[грик]

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

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

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

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

» Нажмите, чтобы показать спойлер - нажмите опять, чтобы скрыть... «

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

Сообщение отредактировал грик - Aug 12 2015, 11:59

[Carnifex]

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

[грик]

Если не считать порнографии с участием this и интерфейса.

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

[Carnifex]

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

Сообщение отредактировал Carnifex - Aug 13 2015, 10:30

[грик]

Я до сих пор не очень понимаю зачем создавать два интерфейса с одинаковыми сигнатурами внутри, но ладно.

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

Безо всякого this.

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

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

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

Сообщение отредактировал грик - Aug 13 2015, 11:49