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

MN>Вот имеено! поэтому свойства и должны были инлайнится и производительнось должна была быть примерно одинакова!

Она и есть одинаковая. Разница меньше процента — это погрешности вычисления.


MN>это естественно. Речь то как раз и идел о свойствах, которые
MN>

MN>since all they do is typically initialize private data members

MN>т.е.

MN>

MN>public string Name
MN>{
MN>    get{  return m_name;}
MN>    set{ m_name = value;}
MN>}
MN>

Такие свойства всегда иннайнятся если ты запускашь код в релизе и не из под отладчика.

В общем, забудь эту статью. Если хочешь действительно увидить как инлайнятся свойства, то советую подружиться с CorDbg.exe и взглянуть код вызова подобных свойств из под него.

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

Здравствуйте, VladD2, Вы писали:
VD>Тогда бы и читабельность поднялась, и народу не было бы откровенно в лом писать лишний код.
Кстати, с евентами МС именно так и поступила. С одной стороны — полная гибкость, с другой — есть дефолтная реализация.

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

VD>Такие свойства всегда иннайнятся если ты запускашь код в релизе и не из под отладчика.

Более того, если есть вложенные друг в друга свойства, то они инлайнятся напрямую, так что даже получается ВЫИГРЫШ раза в два!

  obj.field1.field2       = obj.field1.field2 + 1;       // непосредственный доступ к переменным объекта
  obj.Property1.Property2 = obj.Property1.Property2 + 1; // косвенный доступ через get get

Как бы это ни казалось парадоксально, но из-за инлайна в инлайн второй вариант работает не только не медленнее первого, а даже быстрее его в два раза.

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

S>Кстати, с евентами МС именно так и поступила. С одной стороны — полная гибкость, с другой — есть дефолтная реализация.

+1

Если бы еще додумались избавиться от явного созадния делегатов (как это сделано во втором Шарпе), то вообще была бы лафа.

В общем, козлы они что не добавили сахарку для свойств.

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

VD>Кстати, вопрос дейтвительно филосовский. С одной стороны свойства — это путь к инкопсуляции, а она путь к уменьшению багов и повышению повторного исопользования. Но к сожалению свойства в Шарпе имеют слишком пушистый синтаксис, что резко ушудшает чтение кода в случае если свойства всего лишь являются эксесорами к полям.

Вообще если таких свойств, которые всего лишь являются эксесорами к полям, до хрена и больше, то надо бы передумать дизайн. Ибо такие штуки раскрывают часть реализации класса, и программа в момент превращается из Object Oriented в Object Based.

Ну да впрочем Microsoft поощряет такие вещи совершенно сознательно, понимая, что четкого понимания принципов OO у большинства нет все равно. И что многим будет чересчур трудно понять, что вместо того чтобы опрашивать объект об информации, которая у него есть и делать все самому, можно попросить объект выполнить нужную операцию с этой информацией за тебя.

(На Javaworld есть пара интересных, хотя и не бесспорных, статеек на эту тему:
Why getter and setter methods are evil
More on getters and setters)

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


VD>Кстати, особо следует обратить внимание на то что в общем-то скорость вызова не так уж велика, если он не виртуальный. Хотя в данном тесте конечно влияет предсказание ветвления современных процессоров. В реальном приложении разница между заинлайненым и не заинлайненым методом будет более велика. Но все равно в 99.99% случаев она не соизмерима с основными временными затратами приложения. Так что выгадывать такие мелочи стоит только если пишишь числодробильный алгоритм дико критичный к скорости.

VD>Ну, а экономить нужно на применении правильных алгоритмов и избегании особо тормозных случаев вроде создания миллионов объектов в цикле или использования дотнетной сериализации на ровном месте.

А что не так с дотнетовской сериализацией на ровном месте?
Она что тормознутее, чем самописанная?

Буквально недавно сталкнулся с ситуацией. Нужно было в процессе отладки проследить, кто меняет одно поле. Если бы оно ставилось через сеттер, я бы в него бряк поставил и по call-стеку увидел, что происходит. И добавил вы вывод в лог-файл, чтобы проследить, какие там значения бывают. Но это было public-поле, и это была жопа...

> VD>Ну, а экономить нужно на применении правильных алгоритмов и избегании
> особо тормозных случаев вроде создания миллионов объектов в цикле или
> использования дотнетной сериализации на ровном месте.
>
> А что не так с дотнетовской сериализацией на ровном месте?
> Она что тормознутее, чем самописанная?

Сорри, случайно сабж поменял.

" Евгений Коробко " <12408@users.rsdn.ru> сообщил/сообщила в новостях
следующее: news:2038703@news.rsdn.ru...
> Буквально недавно сталкнулся с ситуацией. Нужно было в процессе отладки
> проследить, кто меняет одно поле. Если бы оно ставилось через сеттер, я бы
> в него бряк поставил и по call-стеку увидел, что происходит. И добавил вы
> вывод в лог-файл, чтобы проследить, какие там значения бывают. Но это было
> public-поле, и это была жопа...

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

Евгений Коробко wrote:
> Буквально недавно сталкнулся с ситуацией. Нужно было в процессе отладки
> проследить, кто меняет одно поле. Если бы оно ставилось через сеттер, я
> бы в него бряк поставил и по call-стеку увидел, что происходит. И
> добавил вы вывод в лог-файл, чтобы проследить, какие там значения
> бывают. Но это было public-поле, и это была жопа...
Ну вообще-то многие отладчики позволяют ставить breakpoint'ы на
модификацию данных.

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

MN>прочитал статью здесь и снова возник давно и лениво интересующий меня вопрос. Предположим, в объекте класса есть поля(внутренние переменные) Некоторые из них должны быть доступны только на чтение, некоторые только на запись. Эта проблема решается свойствами. Однако в некоторых случаях например геттер монопенисуален:
MN>

MN>public string CaptionString = "";

MN>//or

MN>private string m_captionString = "";
MN>public string CaptionString
MN>{
MN>    set {m_captionString = value;}
MN>}
MN>

MN>мне в этом случае все равно, сможет ли кто-то прочитать эту строку или нет. Но как я понимаю это правильный подход. И более медленный (не говоря уже о том что приходится гораздо больше писать).
MN>Вопрос собственно в том, в каких случаях имеет смысл заморачиваться на тему свойств (с учетом того, что никакой логики в них не производится), а когда можно обойтись и просто public переменной?

Не знаю как там у вас со студией. А вот в JBuilder 2005 есть очень удобный визард для работы со свойствами. Где мне надо ввести только название, а так же можно менять название. Поэтому длинна кода меня не интересует.

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

SM>Не знаю как там у вас со студией. А вот в JBuilder 2005 есть очень удобный визард для работы со свойствами. Где мне надо ввести только название, а так же можно менять название. Поэтому длинна кода меня не интересует.

И очень плохо, что не интересует. Людям потом твой код читать.

A>А что нельзя было сделать из него проперти с таким же именем, а само поле
A>переименовать?

Это на С++ было...