Оффтопик. Изучаем C#

[Дима_]

Поля - это не понятно!

Windcastle - Вы молодец. Молодец в том, что задались этим вопросом (для меня это показатель, что Вы пытаетесь вникнуть в суть, а не прочитать). Да действительно, с точки зрения абстракции алгоритма разницы между ними нет - и это очень хорошо, что Вы мыслите именно абстрактными категориями - а не классами, полями, байтами и пр.
Проще всего понять что такое поля - это через их физический смысл - это раньше было необходимо для производительности, а сейчас для совместимости (в некоторых диалектах языков как представить член класса - как поле или как свойство решает оптимизатор транслятора). Когда вы создаете класс - компилятор запоминает его методы в одном месте памяти, а при создании каждого экземпляра объекта выделяется только тот необходимый минимум памяти, чтобы сохранить его данные (на которые и указывает ссылка, на объект - теперь Вам наверное более понятно - для чего нужна типизация - чтоб понять что можно делать с этими данными - как их "читать"). Так вот поля - это упрощенно говоря прямые ссылки на часть этих данных - а свойства - это методы (то есть вызываемые функции), которые созданы по определенным правилам - свойство может и не содержать никаких данных, а например, возвращать вычисления черт знает чего от чего, то-же самое при установке свойства - это не прямая запись в память - а запуск функции с определенными параметрами - которые могут например перед запоминанием переданного аргумента "зазиповать" его, а перед возвратом - раззиповать обратно.

з.ы. по остальному - смотрел правда бегло - вроде все верно.

[Александр Ривилис]

Жду критики!

У меня возникло такое ощущение, что ты, еще не дочитав введение в детектив а уже спрашиваешь у того, кто прочитал, кто убийца. При этом вполне возможно, что убийцы нет, а есть вор...
Я понимаю твоё нетерпение, но я бы вернулся к этим вопросам после первого прочтения книги целиком.
На большую часть вопросов ты найдёшь ответы в книге сам. Зато появятся другие вопросы.
Отмечу лишь один вопрос:

4. То есть я пишу приложение *.exe, к нему могу подключать *.dll файлы (извне) или добавить в проект еще один проект библиотеки *.dll, которая будет зависеть от данного приложения *.exe. Но при этом созданная библиотека внутри может быть подключена другими приложениями. Так?

Не *.dll будет зависеть от *.exe, а наоборот. И этот *.dll, если он правильно спроектирован, может использоваться и с другими *.dll и/или *.exe

[Андрей Бушман]

Когда я "вырасту", то я вынуждено выступлю антагонистом Андрею.

"Хороший" полицейский? Ну всё, придётся мне на двг.ру уходить...

Жду критики!

Так обижаться же будешь опять, снова выискивая в замечаниях какой-то своеобразный смысл, который мною в них не вкладывался... Я, пожалуй, не буду комментировать твою "оптимистичную" реакцию, размазанную на целую страницу...

По поводу свойств хорошо разжёвывает материал Рихтер (CLR via C#). Почитай - очень доходчиво объясняет как и что работает. Применительно к свойствам и полям: никаких свойств в CIL на самом деле не существует. На самом деле это ни что иное как "синтаксический сахар" в языке C#. То, чем в коде ты оперируешь как "свойство", при компиляции в CIL будет преобразовано в пару методов, что-то вроде get_YourPropertyName() и set_YourPropertyName(). Если в свойстве только блок get будет объявлен как public, то public будет лишь первый из обозначенный методов (т.е. можно будет только получать значение свойства, но не править).

Назначение свойств (т.е. их get_*\set_* методов) в том, чтобы дать тебе полный контроль над доступом к скрытым полям. В коде свойств ты выполняешь нужные тебе предварительные проверки и принимаешь решение о том, предоставлять ли доступ к запрошенному полю или же, к примеру, генерировать исключение, или генерировать событие, сообщающее об изменении свойства (в коде set_* метода). Там же выполняешь проверку значения, прежде чем вернуть его (в get_* методе). Если же ты предоставляешь доступ к полю напрямую, через public, то не можешь контролировать этот доступ.

Кроме того, свойства позволяют инкапсулировать логику контроля доступа к полям и, в случае необходимости, править её, без необходимости править сторонний код, использующий эти свойства.

Думаю, что целесообразней тебе было бы изучать c# по Троелсену, а не по справочнику Шильдта.

[Андрей Бушман]

Для чего используется поле?

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

Манифест - это как общий перечень деталей автомобиля с описанием того, какая деталь от какой зависит. Правильно понимаю?

Всё тот же Рихтер, всё в той же книге и этот вопрос разжёвывает.

Что-то типа, когда молодой человек рассматривает девушку и определяет ее параметры, свойства и ее методы (ее возможности). Приблизительно так?
...
То есть это как если были бы хоккейное и футбольное поле, но вратари в обоих случаях были бы разными. На футбольном поле это легко одетый человек, а на хоккейном поле тепло и защищенный от ударов шайбы. И потому у каждого из этих вратарей будут соответственно разные: свойства, методы, события и т.д. Верно понимаю? Значит использовать вратаря из хоккейного поля ни в коем случае использовать в футбольном поле нельзя, только если его имя и фамилию, к примеру. Так?

Какие-то мутные у тебя аналогии...

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

А что, этот текст был чем-то не понятным?

[Дима_]

никаких свойств в CIL на самом деле не существует. На самом деле это ни что иное как "синтаксический сахар" в языке C#.

Опс - граф - тут сразу несколько ошибочных утверждений, во первых не в языке C#, а во всем .Net. Во вторых это не "сахар" а конкретный механизм. Да создавая свойство XXX автоматически создадутся методы get_XXX и если и на запись,  то и set_XXX, через которые и будет обращение, но не наоборот - создав метод get_Abc() - свойство Abc не появится - и в "рефлекшине" соотв. записи не будет. Такая картина впрочем не только в .Net (в смысле автоматическое создание методов для доступа - чтоб не городить отдельный механизм).

[Андрей Бушман]

тут сразу несколько ошибочных утверждений, во первых не в языке C#, а во всем .Net. Во вторых это не "сахар" а конкретный механизм.

Я писал:

никаких свойств в CIL на самом деле не существует.

Во первых, CIL - это не C#. Если нет в CIL, то нет и в языках более высокого уровня, т.к. их код компилируется именно в CIL.
Во вторых, термин "синтаксический сахар" не является моим, и часто используется в книжках, в частности в той теме, где как раз таки свойства и объясняются.

но не наоборот - создав метод get_Abc() - свойство Abc не появится - и в "рефлекшине" соотв. записи не будет.

Я и не писал этого. когда я писал о get и set, то имел соответствующие блоки кода в определении свойства.

Такая картина впрочем не только в .Net (в смысле автоматическое создание методов для доступа - чтоб не городить отдельный механизм).

Я в курсе. Это и называется "синтаксическим сахаром". Тот же Рихтер его так и называет.

[Дима_]

А я пишу, что в CIL они существуют и это не сахар см. в рефлексе, либо попробуй создать свойство созданием метода.

[Андрей Бушман]

А я пишу, что в CIL они существуют и это не сахар см. в рефлексе, либо попробуй создать свойство созданием метода.

Поддержка свойств встроена в C#. Обнаружив код, пытающийся получить или задать свойство, компилятор генерирует вызов соответствующего метода. Если используемый язык не поддерживает свойства напрямую, к ним все равно можно обратиться посредством вызова нужного метода доступа. Эффект тот же, только исходный текст выглядит менее элегантно.

Помимо методов доступа, для каждого из свойств, определенных в исходном тексте, компиляторы генерируют в метаданных управляемого модуля запись с определением свойства. Такая запись содержит несколько флагов и тип свойства, а также ссылки на методы доступа get и set. Эта информация существует лишь затем, чтобы связать абстрактное понятие «свойства» с его методами доступа. Компиляторы и другие инструменты могут использовать эти метаданные через класс System.Reflection.PropertyInfo. И все же CLR не использует эти метаданные, требуя при выполнении только методы доступа.

[Дима_]

Ну так и с какого перепуга стандартная процедура CLI является синтаксическим сахаром языка С#. Я кстати в данной цитате нигде не увидел, что это он (сахар).

[Андрей Бушман]

Ну так и с какого перепуга стандартная процедура CLI является синтаксическим сахаром языка С#. Я кстати в данной цитате нигде не увидел, что это он (сахар).

In addition, .NET 3.0 shipped with C# 2.0 and so no changes were made to the C# language/compiler either. Of course, .NET 3.5 does ship with C# 3.0 which does offer many new features (automatically-implemented properties, implicitly typed local variables, extension methods, lambda expressions, object initializers, anonymous types, implicitly typed arrays, partial methods, query expressions, and expression tress). However, all of these features are just compiler syntactic sugar to make syntax easier for programmers.

Поправляюсь - синтаксическим сахаром он называл автоматические свойства.

[Дима_]

Это уже другой разговор - для Топикстартера (а может и не только его) поясню - автоматические свойства - это метод создания свойства при котором в неявном для программиста виде создаются закрытое поле в котором содержится значение, которое и возвращает/задает данное свойство - это безусловно синтаксический сахар.
з.ы. Цитата выше, кстати, хорошо объясняет почему меня раздражает c# - практически все перечисленное в ней - в чистом виде "функциональщина" - которую натягивают на не предназначенный для этого язык из другой парадигмы (ну он вроде как потомок с и с++) - ИХМО получается как седло на корове.
з.з.ы - То А. Ривилис - флудить Вы сами разрешили.

[Андрей Бушман]

почему меня раздражает c# - практически все перечисленное в ней - в чистом виде "функциональщина" - которую натягивают на не предназначенный для этого язык из другой парадигмы

я ничего подобного не вижу.

(ну он вроде как потомок с и с++) - ИХМО получается как седло на корове.

Смотря что имеется в виду под "потомком". Да, синтаксис весьма похож, но это не то же самое, что С или C++. Код С89 можно компилировать в Visual C++, поэтому С++ - полноценный потомок С (у Стровструпа, кстати, есть хорошая книга по истории С++). Однако ни код C, ни код С++ откомпилировать в C# не удастся, поэтому родства подобного C\C++ у C# с этими языками всё же нет.

Программировать в С++ можно как в объектно-ориентированном, так и в функциональном стиле (решение за программистом) - эту возможность Стровструп оставил умышленно, т.к. считает, что не существует единственно верного способа программировать и все люди уникальны (каждый может найти своё хорошее решение задачи). В то же время C# - объектно-ориентированный язык. Функциональное программирование в нём невозможно. В то же время и С не является чисто-функциональным (тем более C++). Серебрянной пули не существует - нет языка, который идеально подходит под все сферы программирования. Это признаёт и Стровструп (создатель С++).

C#, на мой взгляд, достаточно прост в изучении (гораздо проще, чем С++). Когда я принял решение уходить с VBA, то выбирал между VB.NET и C#. Изначально хотел взять VB.NET, но посмотрев его синтаксис понял, что мне он понятней не более, чем синтаксис C#, т.к. общего у него с VBA не больше, чем у кошки и собаки. Выбрал C#, т.к. по нему больше материала и его вместо VB.NET в интернете рекомендовали авторитетные забугорные специалисты. Как показала практика - с выбором я не ошибся. Кроме того, в то время VB.NET уступал по функционалу языку C#. Это сейчас майкрософтом принято решение постоянно подтягивать VB.NET к возможностям C#, как жгут резиновый. Но это означает, что VB.NET всегда будет как минимум на шаг позади C# (имхо). Я не знаю, как у VB.NET дела обстоят сейчас, да и не интересно мне это.

Мне нравятся все три языка(C\C++\C#). Идеальных языков нет, у каждого есть свои преимущества и недостатки. Отторжение у меня вызывает разве что язык гоблинов (VB) и его аналоги: VBA, VB.NET, VBScript. Не знаю, вот коробит меня от него и всё, хотя когда-то сам же активно писал код на VBA в MS Access 2003 и выше (сейчас уже и забыл его).

[Александр Ривилис]

з.з.ы - То А. Ривилис - флудить Вы сами разрешили.

А я от своих слов и не отказываюсь.

[Дима_]

То Андрей - цитату мою Вы не с начала вырвали - "перечисленное в ней" - это не про c# а про цитату из Вашего поста.

В то же время C# - объектно-ориентированный язык. Функциональное программирование в нём невозможно.

    Это с какого перепугу - а LINQ и анонимные функции - это что - да в чистейшем виде функциональщина - неудобно и криво сделано - да - о чем я и пишу (что понятно ибо это как скрестить ужа с ежом) - но она там гораздо более возможней, чем в тех же c и c++ - где даже сборка мусора отсутствует (ну в с++ там по моему какая-то затычка в этом роде была).
    ИХМО - большая часть всех "нововведений" C# (оно-же как и версии .Net) последних лет - имеют функциональную природу (кстати объектно-ориентированный язык  - это совсем не значит, что он императивный - он в равной степени может быть и функциональным - просто объекты у него по "умолчанию" не изменяются, а пересоздаются), готов обосновать на перечне нововведений любой из "последних" версий, а вся структура "родителей" (с,с++) - ну скажем так, не очень заточена под функциональное программирование - поэтому смотреть на ту реализацию нового - забытого старого без слез нельзя - хотя надо признать - делают, это самое скрещевание, на удивление качественно - иногда я бы даже сказал шедеврально - особенно с учетом "груза поддержки" всей предыдущей парадигмы языка.

[Андрей Бушман]

Я очень даже в курсе, что многое из добавленного в C# взято из функциональных языков. Однако, на мой взгляд, реализовано это в нём достаточно удобно и не вызывает у меня отторжения. Перенимать положительный опыт других языков - в этом нет ничего зазорного. Главное, чтобы реализовано это было так, чтобы программисту было удобно этим пользоваться. То, как в C# реализованы методы расширения и LINQ, работающий на основе этого механизма, меня вполне устраивает. Работать с анонимными функциями мне так же удобно и мне не важно, откуда эти возможности были переняты.

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

Я знаю. Тогда это получается чисто-фунциональный язык.

вся структура "родителей" (с,с++) - ну скажем так, не очень заточена под функциональное программирование

Да, в них отсутствуют ленивые вычисления и они не являются чисто-функциональными. Но у них есть свои плюсы и основной из них - скорость работы. У меня нет желания вести религиозные войны.