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

Doc>Получается:

Doc>1) Придумали правило, что не хорошо обращаться к memebers напрямую, а надо писать get_XXX и put_XXX методы.

Doc>2) Теперь придумали properties, которые выглядят как memebers, но реально вызываются get_XXX/put_XXX методы. Т.е. мало того, что это "хак" для правила выше, так еще и визуально путает.

Doc>Итого: получается что сначала придумали себе правило, а после как его обойти.

Все просто. проперти это явно выраженые публичные данные объекта. Не каждое проперти это обязательно мембер, и не каждая функции возвращает данные ассоциируемые с объектом. Простой пример: в объекте DataRow поля удобнее описать именно как properties.

Здравствуйте, <Аноним>, Вы писали:

А>Все просто. проперти это явно выраженые публичные данные объекта. Не каждое проперти это обязательно мембер, и не каждая функции возвращает данные ассоциируемые с объектом. Простой пример: в объекте DataRow поля удобнее описать именно как properties.

Да, но ведь такой полход идет в разрез с идеологией C++. Или я ошибаюсь?

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

Doc>Да, но ведь такой полход идет в разрез с идеологией C++. Или я ошибаюсь?

В чем?

Здравствуйте, <Аноним>, Вы писали:

А>В чем?

Есть утверждение что класс должен скрывать детали своей реализации и общаться с миром только через методы. С этой точки зрения properties это хак (т.е. как бы через методы, но вид как работы с members).

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

Doc>Здравствуйте, <Аноним>, Вы писали:

А>>В чем?

Doc>Есть утверждение что класс должен скрывать детали своей реализации и общаться с миром только через методы. С этой точки зрения properties это хак (т.е. как бы через методы, но вид как работы с members).

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

Здравствуйте, <Аноним>, Вы писали:

А>Где это такие утверждения, что только через методы?

Да сейчас уже и не вспомню. Давно, когда C++ учил, встречал такое в книге. В принципе согласен с данным положением.

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

Это ясно, но я несколько об ином.
Чем такой способ записи (кроме привычки обращаться к полям напрямую) лучше записи в виде метода?
Причем применительно именно к C++. Ведь это только дает накладные расходы.

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

Doc>Здравствуйте, <Аноним>, Вы писали:

А>>Где это такие утверждения, что только через методы?
Doc>Да сейчас уже и не вспомню. Давно, когда C++ учил, встречал такое в книге. В принципе согласен с данным положением.

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

Doc>Чем такой способ записи (кроме привычки обращаться к полям напрямую) лучше записи в виде метода?

Это не способ записи. Это другая логическая сущность. Выбор способа записи это просто очевидное следствие.

Doc>Причем применительно именно к C++. Ведь это только дает накладные расходы.

Какие? Фактически это разновидность метода без параметров.

Здравствуйте, <Аноним>, Вы писали:

Еще раз — я только о обычном С++ говорю. Там где properties были задуманы изначально и есть в языке — другой разговор. Я уже говорил, что есть места (ActiveX, VCL) где они в тему.

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

Нет, friend это отдельная тема (там более что friend не обязательно для members).

Хотя применительно к теме разговора friend как раз IMHO подтверждает данное правило.
Смотри, напрямую обращаться нельзя (а там более в protected), но вдруг очень надо. Тогда можно объявить friend. Это дает классу возможность контролировать доступ до его members и закрытых методов.

Doc>>Чем такой способ записи (кроме привычки обращаться к полям напрямую) лучше записи в виде метода?
А>Это не способ записи. Это другая логическая сущность. Выбор способа записи это просто очевидное следствие.

Вот тут подробнее.

Doc>>Причем применительно именно к C++. Ведь это только дает накладные расходы.
А>Какие? Фактически это разновидность метода без параметров.

Небольшие, но есть. Вызов метода это просто вызов метода. Стандартной реализации properties в С++ нет (MS и прочие specific не в счет). Значит для записи вида
myClass.nValue = 5;
надо писать свою реализацию. Например вот — Свойства в С++

Автор: Денис Майдыковский
Дата: 20.11.01

.
Там же (в конце статьи) есть и расходах данного примера.

PS: Возможно это дело привычки, но например мне не нравится код, где вместо двух строк ::SendMessage() тянется какой-нибудь CButton. Так и тут — просто ради иной формы записи делается накрутка лишнего кода.

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

Doc>Здравствуйте, <Аноним>, Вы писали:

Doc>Еще раз — я только о обычном С++ говорю. Там где properties были задуманы изначально и есть в языке — другой разговор. Я уже говорил, что есть места (ActiveX, VCL) где они в тему.

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

Doc>Нет, friend это отдельная тема (там более что friend не обязательно для members).

Какая разница отдельная тема или нет? Есть еще операторы, которые не методы но доступ вполне себе имеют. Слишком много исколючений что бы "только через методы" оставалось верной.

Doc>Вот тут подробнее.

См. первое сообщение. Есть реализация объекта и его представление. Взять тот же DataRow для примера. Как отпределить какие методы есть суть ячейки, а какие работа с ними? Суффиксами и префиксами? А если я получаю сериализованый объект? Парсить названия функуий? Вот для того что бы избежать этого неудобства и используют свойства.

Doc>>>Причем применительно именно к C++. Ведь это только дает накладные расходы.
А>>Какие? Фактически это разновидность метода без параметров.

Doc>Небольшие, но есть. Вызов метода это просто вызов метода. Стандартной реализации properties в С++ нет (MS и прочие specific не в счет). Значит для записи вида

12 байт в одтельной взятой реализации конечно жуткие расходы.

Здравствуйте, <Аноним>, Вы писали:

А>Из темы это никак не следует.

См.
— первое сообщение темы (там ссылка на обсуждение статьи. собственно именно по этому и вопрос).
— название раздела форума (было бы странно тот говорить про C# или даже про C++ Builder)

A> а оказывается у тебя претензии к отдельным ее реализациям, это совсем другое.

Именно. Хочу понять в чем сахар прикручивания properties к C++.

Doc>>Нет, friend это отдельная тема (там более что friend не обязательно для members).
А>Какая разница отдельная тема или нет?

Странный вопрос. Повторю — объявление friend подразумевает что обе стороны знают что делают и куда лезут. А вот вынос member в public только добавляет гимороя в дальнейшем развитии класса.

А>12 байт в одтельной взятой реализации конечно жуткие расходы.

А если у вас 50 properties и все это еще в N копиях
Хотя я и не утвеждал что жуткие. Но я уже писал, что не понимю людей которые вместо ::SendMessage () создают классы.

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

Doc>- название раздела форума (было бы странно тот говорить про C# или даже про C++ Builder)

Зато вполне можно говорить о c++/cli

A>> а оказывается у тебя претензии к отдельным ее реализациям, это совсем другое.

Doc>Именно. Хочу понять в чем сахар прикручивания properties к C++.

В пятый раз. В явном отделении даннах которые представляет объект от фунукций. Имхо ты не понять хочешь, а доказать, что без низ можно обойтись. Можно. Как и без классов, только зачем? Это ж интсрумент, а не набор догматов, если у молотка более удобная ручка, то почему бы им не пользоваться?

Doc>>>Нет, friend это отдельная тема (там более что friend не обязательно для members).
А>>Какая разница отдельная тема или нет?

Doc>Странный вопрос. Повторю — объявление friend подразумевает что обе стороны знают что делают и куда лезут. А вот вынос member в public только добавляет гимороя в дальнейшем развитии класса.

А при чем тут мемберы? Публичные члены и доступ к членам "только через функции" утверждения разные.
Не говоря уж о том, что речь идет о свойствах, которые могут быть не связаны ни с одним из членом, публичные они там или нет. members это для объекта, properties для пользователя объекта. Так что мухи отдельно, котлеты отдельно.

А>>12 байт в одтельной взятой реализации конечно жуткие расходы.

Doc>А если у вас 50 properties и все это еще в N копиях
Doc>Хотя я и не утвеждал что жуткие. Но я уже писал, что не понимю людей которые вместо ::SendMessage () создают классы.

Все зависит от задачи. Если надо запомнить состояние, то лучше создать класс, чем плодить дурацкие переменные для глобальной ::SendMessage(). Гибче надо быть...

Здравствуйте, <Аноним>, Вы писали:

А>Зато вполне можно говорить о c++/cli

Подловил

А>В пятый раз. В явном отделении даннах которые представляет объект от фунукций. Имхо ты не понять хочешь, а доказать, что без низ можно обойтись.

Как раз нельзя. Пример тому тот же VCL и опять же ActiveX. Ну такова его изначальная природа, что properties сами простяся для работы с design-time редактором. В этом случае такая огранизация вполне оправдана. А вот ради чего городить городушки как в приведенной статье... ?

А>А при чем тут мемберы? Публичные члены и доступ к членам "только через функции" утверждения разные.

Ты сбился. Погляди разговор с своего сообщения. Это к вопросу об утверждении "доступ к членам только через функции". К этой части текста properties ни каким боком (разьве только что их стиль записи как раз похож на этот неправильный подход).

А>Все зависит от задачи. Если надо запомнить состояние, то лучше создать класс, чем плодить дурацкие переменные для глобальной ::SendMessage(). Гибче надо быть...

Не думаю что открою Америку, но сей класс как раз и сделать переменную и запишет туда состояние.

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

Doc>Как раз нельзя. Пример тому тот же VCL и опять же ActiveX. Ну такова его изначальная природа, что properties сами простяся для работы с design-time редактором. В этом случае такая огранизация вполне оправдана. А вот ради чего городить городушки как в приведенной статье... ?

Обойтись можно.
Я так понимаю претензии именно к реализации? Ну так ее тебя никто силком не заставляет использовать.

Doc>Ты сбился. Погляди разговор с своего сообщения. Это к вопросу об утверждении "доступ к членам только через функции". К этой части текста properties ни каким боком (разьве только что их стиль записи как раз похож на этот неправильный подход).

Это ты сбился, я сомневаюсь, что где либо декларирован принцип, что доступ к членам должен быть только через функции. Не больше не меньше. Соотвественно и объявлять что либо корректным/некорректным на основании неверного утверждения тоже не верно.

Doc>Не думаю что открою Америку, но сей класс как раз и сделать переменную и запишет туда состояние.

классу нет нужды делать внешнуюю переменную. в результате будет одна необходимая сущность вместо двух, к тому же не связанных.

Здравствуйте, <Аноним>, Вы писали:

А>Обойтись можно.
А>Я так понимаю претензии именно к реализации? Ну так ее тебя никто силком не заставляет использовать.

В первую очередь, я не доказываю что их не надо использовать, а наоборот спрашиваю в чем сахар. Может я туплю Пока явного выйгрыша использования в "обычном" С++ не увидел.

Ладно, я понимаю. Пятница вечер ... все устали давай завяжем.

А>Это ты сбился, я сомневаюсь, что где либо декларирован принцип, что доступ к членам должен быть только через функции. Не больше не меньше. Соотвественно и объявлять что либо корректным/некорректным на основании неверного утверждения тоже не верно.

Хорошо, давай пойдет методом "от противного". Приведи пример, когда использования прямого доступа будет благом сейчас и в дальнейшем. Причем речь не о firend сущности (т.е. класс и обращающийся к нему объет неичего не знают о особенносиях внутренностей друг-друга).

Doc>>Не думаю что открою Америку, но сей класс как раз и сделать переменную и запишет туда состояние.
А>классу нет нужды делать внешнуюю переменную. в результате будет одна необходимая сущность вместо двух, к тому же не связанных.

Зачем классу внешняя переменная? Он заведет внутреннюю. Итого имеем:
1) просто переменную + 2 строки кода
2) ту же переменную внутри класса, но уже сам класс в довесок и как минимум еще вызовы конструктора и деструктора. Огород на пустом месте.