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

С точки зрения чистого ООП, public переменных быть не должно вообще. Иными словами, "заморачиваться" на тему свойств нужно всегда. Лично я стараюсь "по умолчанию" так и поступать.

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

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

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

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

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

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

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

M>

M>Вопрос собственно в том, в каких случаях имеет смысл заморачиваться на тему свойств (с учетом того, что никакой логики в них не производится), а когда можно обойтись и просто public переменной?

M>С точки зрения чистого ООП, public переменных быть не должно вообще. Иными словами, "заморачиваться" на тему свойств нужно всегда. Лично я стараюсь "по умолчанию" так и поступать.

M>А вообще, это скорее вопрос философии — я, например, очень ценю "чистоту" кода с точки зрения соответствия парадигмам ООП и готов ради этого идти на жертвы (скорость, время разработки и т.п.) — ну естественно в разумных пределах. Моя практика показывает, что такие "заморочки" чаще всего в дальнейшем окупают себя. А кто-то такими мелочами не парится — лишь бы работало. Такой подход тоже имеет право на жизнь.

Я думаю, что подход "лишь бы работало" имеет гораздо больше прав на смерть, чем на жизнь!

Здравствуйте, 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 и взглянуть код вызова подобных свойств из под него.

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

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

MN>Но как я понимаю это правильный подход.

Нет. Более правильный подход для установки переменных использовать методы. Свойство доступное только на запись — это хреновый дизайн.

Но это лучше нежели выставлять на ружу лишние переменные.

MN> И более медленный

Опять же нет. Простые методы и свойства инлайнются джитом. Так что в ассемблере будет прямое обращение к полю. Но ты при этом получишь полноценную инкапсуляцию.

MN>(не говоря уже о том что приходится гораздо больше писать).

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

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

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

Вот только подходить к инкапсуляции нужно в рамках проектирования, а не на уровне переменных и экономии времени на кодировании. Инкапсуляция — это один из основных принципов улучшения повторного использования кода и создания более надежного ПО.

ЗЫ

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

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

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

_>Если нету никакой логики и можно писать/читать (есть get/set) (т.е. как поле структуры) я свойства никогла не испоьзую — смысла никакого,
Разрешите не согласиться. Спасибо А если с Вашим классом работает еще кто-нить и Вам понадобится внести маленькую проверочку, то Вам придется выносить ее в свойство, так не лучше ли сразу сделать, а то получится у Вас свойство с именем, как у поля (если Вы придерживаетесб определенных правил именования).
_>а печатать много.

_>Да и работает медленее, но это незаметно.
С этим опять-таки не соглашусь. Компилятор, если увидит, что вы возвращаете или присваиваете только лишь значение встроит свойство и проигрыша в скорости не будет, по-крайней мере, по заявлениями мелкомягких.

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

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

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

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

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

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

Здравствуйте, Max404.NET, Вы писали:
[skipped]
MN>Вопрос собственно в том, в каких случаях имеет смысл заморачиваться на тему свойств (с учетом того, что никакой логики в них не производится), а когда можно обойтись и просто public переменной?
здесь

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

Если нету никакой логики и можно писать/читать (есть get/set) (т.е. как поле структуры) я свойства никогла не испоьзую — смысла никакого, а печатать много. Да и работает медленее, но это незаметно.

например вместо этого :

private string m_captionString = "";
public string CaptionString
{
    set {m_captionString = value;}
    get {return m_captionString;}
}

у меня будет просто

public string СaptionString;

Если логика есть, тогда я использую классы.
(абстрактный пример):

class Window
{
.....
    private string m_captionString = "";
    public string CaptionString
    {
        set 
        {
            m_captionString = value; 
            UpdateCaption();  //some logic here
        }
        get {return m_captionString;}
    }
.....
}

Еще я думаю, нужно использовать свойства, когда класс вызывается через reflection другим классом.
(ASP.NET data binding?)

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

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

провел небольшое исследование, и вот что получается:
есть класс, читающий XML-файл (конфигурацию) и строящий из него дерево узлов CfgNode. Узел имеет несколько свойств:

/// <summary>
/// Класс узла конфигурации
/// </summary>
[Serializable]
public class CfgNode
{
// вариант 1 - приват-поля и свойства
//    CfgNodeCollection m_nodes = new CfgNodeCollection();
//    CfgNode m_parent = null;
//    string m_name = "unnamed";
//    string m_description = "";
//    string m_type = "String";
//    string m_value = "";

//  вариант 2 - публичные переменные
    public CfgNodeCollection Nodes = new CfgNodeCollection();
    public CfgNode Parent = null;
    public string Name = "unnamed";
    public string Description = "";
    public string Type = "String";
    public string Value = "";
    #endregion

    public CfgNode()
    {}

// вариант 1 -----------------
//    public string Name
//    {
//        get{  return m_name;}
//        set{ m_name = value;}
//    }
//
//    public string Description
//    {
//        get{  return m_description;}
//        set{ m_description = value;}
//    }
//
//    public string Type
//    {
//        get{  return m_type;}
//        set{ m_type = value;}
//    }
//
//    public string Value
//    {
//        get{  return m_value;}
//        set{ m_value = value;}
//    }
//
//    public CfgNodeCollection Nodes
//    {
//        get{  return m_nodes;}
//        set{ m_nodes = value;}
//    }
//
//    public CfgNode Parent
//    {
//        get{  return m_parent;}
//        set{ m_parent = value;}
//    }
}

этот класс используется довольно интенсивно в процессе построения дерева, поэтому можно считать что это те самые 80/20 для моего кода. Я не стал усложнять методику тестирования, так что:

XMLConfigurator xc = new XMLConfigurator(@"c:\debase.cfg"); //XML файл, 150КБ    
DateTime timer = DateTime.Now;
for (int j = 0; j<1000; j++)
    xc.Refresh(); //Обновление (файл загружается заново)

DateTime timere = DateTime.Now;
TimeSpan ts = timere.Subtract(timer);
MessageBox.Show(ts.ToString());

Результаты:
— 34.3670 — вариант 1
— 34.0860 — вариант 2 (публичные переменные)
— 34.1288 — вариант 1 с включенной опцией "Optimize Code"
— 34.0234 — вариант 2 с включенной опцией "Optimize Code"

Улучшение при включении оптимизации кода относятся ко всему проекту в целом, поэтому они не показательны. В любом случае улучшение производительности присутствует (0,9% без оптимизации кода и 0,31% с оптимизацией) Учитывая высказывания из статьи http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/highperfmanagedapps.asp

The JIT uses a number of heuristics to decide whether a method should be in-lined. The following is a list of the more significant of those (note that this is not exhaustive):
— Methods that are greater than 32 bytes of IL will not be inlined.
— Virtual functions are not inlined.
— Methods that have complex flow control will not be in-lined. Complex flow control is any flow control other than if/then/else; in this case, switch or while.
— Methods that contain exception-handling blocks are not inlined, though methods that throw exceptions are still candidates for inlining.
— If any of the method's formal arguments are structs, the method will not be inlined.
I would carefully consider explicitly coding for these heuristics because they might change in future versions of the JIT. Don't compromise the correctness of the method to attempt to guarantee that it will be inlined. ...

Property get and set methods are generally good candidates for inlining, since all they do is typically initialize private data members.

хочется сказать, что в JIT-е пока ещё слабые эвристические алгоритмы инлайнинга.

Здравствуйте, Max404.NET, Вы писали:
MN>>>Вопрос собственно в том, в каких случаях имеет смысл заморачиваться на тему свойств (с учетом того, что никакой логики в них не производится), а когда можно обойтись и просто public переменной?
_FR>>здесь
MN>провел небольшое исследование, и вот что получается:
MN>есть класс, читающий XML-файл (конфигурацию) и строящий из него дерево узлов CfgNode. Узел имеет несколько свойств:
[skipped]
MN>этот класс используется довольно интенсивно в процессе построения дерева, поэтому можно считать что это те самые 80/20 для моего кода. Я не стал усложнять методику тестирования, так что:
MN>

MN>XMLConfigurator xc = new XMLConfigurator(@"c:\debase.cfg"); //XML файл, 150КБ    
MN>DateTime timer = DateTime.Now;
MN>for (int j = 0; j<1000; j++)
MN>    xc.Refresh(); //Обновление (файл загружается заново)

MN>DateTime timere = DateTime.Now;
MN>TimeSpan ts = timere.Subtract(timer);
MN>MessageBox.Show(ts.ToString());
MN>

MN>Результаты:
MN>- 34.3670 — вариант 1
MN>- 34.0860 — вариант 2 (публичные переменные)
MN>- 34.1288 — вариант 1 с включенной опцией "Optimize Code"
MN>- 34.0234 — вариант 2 с включенной опцией "Optimize Code"

MN>Улучшение при включении оптимизации кода относятся ко всему проекту в целом, поэтому они не показательны. В любом случае улучшение производительности присутствует (0,9% без оптимизации кода и 0,31% с оптимизацией)

Одна десятка на тысячу итераций — этого мало?

MN>Учитывая высказывания из статьи http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/highperfmanagedapps.asp
MN>

MN>The JIT uses a number of heuristics to decide whether a method should be in-lined. The following is a list of the more significant of those (note that this is not exhaustive):
MN>- Methods that are greater than 32 bytes of IL will not be inlined.
MN>- Virtual functions are not inlined.
MN>- Methods that have complex flow control will not be in-lined. Complex flow control is any flow control other than if/then/else; in this case, switch or while.
MN>- Methods that contain exception-handling blocks are not inlined, though methods that throw exceptions are still candidates for inlining.
MN>- If any of the method's formal arguments are structs, the method will not be inlined.
MN>I would carefully consider explicitly coding for these heuristics because they might change in future versions of the JIT. Don't compromise the correctness of the method to attempt to guarantee that it will be inlined. ...

Ничего из этого в твоём коде не присутствует.

MN>

Property get and set methods are generally good candidates for inlining, since all they do is typically initialize private data members.

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

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

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

_>>>а печатать много.
MN>конечно это мелочи, но есть классы определенного типа, в которых довольно много полей, та к что и писть придется гораздо больше...
Много это сколько? Если у класса 50 полей и это не визуальный компонент то это не класс а мусорка.

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

M>С точки зрения чистого ООП, public переменных быть не должно вообще. Иными словами, "заморачиваться" на тему свойств нужно всегда. Лично я стараюсь "по умолчанию" так и поступать.

M>А вообще, это скорее вопрос философии — я, например, очень ценю "чистоту" кода с точки зрения соответствия парадигмам ООП и готов ради этого идти на жертвы (скорость, время разработки и т.п.) — ну естественно в разумных пределах. Моя практика показывает, что такие "заморочки" чаще всего в дальнейшем окупают себя. А кто-то такими мелочами не парится — лишь бы работало. Такой подход тоже имеет право на жизнь.

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

property int MyProperty;

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

Декларативность как всегда рулит!

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

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

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

public string CaptionString = "";

//or

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

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

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

PropertyGrid pg = new PropertyGrid();
pg.SelectedObject = new Test();
pg.Parent = this;

public class Test
{
// Доступно для редактирования в PropertyGrid
public string CaptionStringProp
{
get { return m_captionString; }
set { m_captionString = value; }
}
private string m_captionString = "";

// Недоступно для редактирования в PropertyGrid.
public string CaptionStringField = "";
}

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

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

MN>>Улучшение при включении оптимизации кода относятся ко всему проекту в целом, поэтому они не показательны. В любом случае улучшение производительности присутствует (0,9% без оптимизации кода и 0,31% с оптимизацией)

_FR>Одна десятка на тысячу итераций — этого мало?
в реальном коде эта конфигурация загрузится/обновится от 3 до 10 раз...

MN>>Учитывая высказывания из статьи http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/highperfmanagedapps.asp

_FR>Ничего из этого в твоём коде не присутствует.
Вот имеено! поэтому свойства и должны были инлайнится и производительнось должна была быть примерно одинакова!

MN>>

Property get and set methods are generally good candidates for inlining, since all they do is typically initialize private data members.

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

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

since all they do is typically initialize private data members

т.е.

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

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

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

_>>Если нету никакой логики и можно писать/читать (есть get/set) (т.е. как поле структуры) я свойства никогла не испоьзую — смысла никакого,
AL>Разрешите не согласиться. Спасибо А если с Вашим классом работает еще кто-нить и Вам понадобится внести маленькую проверочку, то Вам придется выносить ее в свойство, так не лучше ли сразу сделать, а то получится у Вас свойство с именем, как у поля (если Вы придерживаетесб определенных правил именования).
дело втом, что как уже сказал ilya_ny
_>>а печатать много.
конечно это мелочи, но есть классы определенного типа, в которых довольно много полей, та к что и писть придется гораздо больше...
А насчет именования — Вы в коде класса используете свойство или внутреннюю переменную?

_>>Да и работает медленее, но это незаметно.
AL>С этим опять-таки не соглашусь. Компилятор, если увидит, что вы возвращаете или присваиваете только лишь значение встроит свойство и проигрыша в скорости не будет, по-крайней мере, по заявлениями мелкомягких.
как показывают мои тесты это не так.

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

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

_>>>>а печатать много.
MN>>конечно это мелочи, но есть классы определенного типа, в которых довольно много полей, та к что и писть придется гораздо больше...
paz>Много это сколько? Если у класса 50 полей и это не визуальный компонент то это не класс а мусорка.

Бизнес-сущность

Hello, paz!

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

p> _>>>а печатать много.
MN>> конечно это мелочи, но есть классы определенного типа, в которых
MN>> довольно много полей, та к что и писть придется гораздо больше...

РеШарпер позволяет создавать тривиальные сеттеры и геттеры за пару секунд в любом количестве.

p> Много это сколько? Если у класса 50 полей и это не визуальный компонент
p> то это не класс а мусорка.

А что за привилегия такая у визуальных компонентов?

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

_>Если нету никакой логики и можно писать/читать (есть get/set) (т.е. как поле структуры) я свойства никогла не испоьзую — смысла никакого, а печатать много.

А как на счет инкапсуляции? Ну, там возьмет у тебя кто-то адрес у свойства и будет менять значение где попало.

_> Да и работает медленее, но это незаметно.

Проверял?

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

AL>>С этим опять-таки не соглашусь. Компилятор, если увидит, что вы возвращаете или присваиваете только лишь значение встроит свойство и проигрыша в скорости не будет, по-крайней мере, по заявлениями мелкомягких.
MN>как показывают мои тесты это не так.

Тесты в студию.

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

MN>Бизнес-сущность

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

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

_FR>Ничего из этого в твоём коде не присутствует.

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

А увидить есть ли вообще выигрыш от инлайнинга можно очень просто. К каждому свойству нужно добавить атрибут

MN>>хочется сказать, что в JIT-е пока ещё слабые эвристические алгоритмы инлайнинга.
_FR>Ну, не знаю, не видел

Джит действительно не так умен как оптимизатор VC7+. Однако в случае вырожденных свойств он всегда инлайнит свойства. Главное чтобы программа была скомпилирована в релизе и запускалась бы не из под отладчика (иначе оптимизации выключаются).

Чтобы покочить с этими инсинуациями приведу примитивный теститк наборосанный на коленке за 5 минут:

using System;
using System.Runtime.CompilerServices;

class A
{
    public int _i;
    public int IntProperty
    {
        get { return _i; }
        set { _i = value; }
    }

    public int IntPropertyNoInline
    {
        [MethodImpl(MethodImplOptions.NoInlining)]
        get { return _i; }
        [MethodImpl(MethodImplOptions.NoInlining)]
        set { _i = value; }
    }
}
class Program
{
    private static A _a = new A();

    static void Main(string[] args)
    {
        const int count = 100000000;
        _a.IntProperty++; // JIT-компиляция
        _a.IntPropertyNoInline++;
        int start;

        _a.IntProperty = 0;
        start = Environment.TickCount;
        for (int i = 0; i < count; i++)
            _a.IntProperty++;
        Console.WriteLine("IntProperty access time is "
            + (Environment.TickCount - start));

        _a.IntProperty = 0;
        start = Environment.TickCount;
        for (int i = 0; i < count; i++)
            _a.IntPropertyNoInline++;
        Console.WriteLine("IntPropertyNoInline access time is "
            + (Environment.TickCount - start));

        _a.IntProperty = 0;
        start = Environment.TickCount;
        for (int i = 0; i < count; i++)
            _a._i++;
        Console.WriteLine("Field access time is "
            + (Environment.TickCount - start));

    }
}

А вот его результаты при запуске не из под отладчика в релизе:

IntProperty access time is 235
IntPropertyNoInline access time is 562
Field access time is 297

ЗЫ

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

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

ЗЗЫ

По секрету скажу, что мы (в www.optim.ru/cs) перевели несколько очень увлекательных статей по этой теме и в скором времени они появятся на РСДН.

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

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

+1

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

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

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


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

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

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

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

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

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

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

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

Здравствуйте, 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>переименовать?

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