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

ssm>обект класса А не получает вообше никаких уведомлений о измемении агрегата, поэтому приведенное тобой сравнениe

не совсем так
реально запись а.х++; (где х — свойство) должна разворачиваться в int х = а.get_х(); х++; а.set_х(х); , а в set_x объект обо всем узнает

You will always get what you always got
  If you always do  what you always did

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


J>>2. А как насчет:
J>>

J>>++a.x;
J>>--a.x;
J>>a.x--;
J>>a.x += 5;
J>>c.x = a.x++ + ++b.x;
J>>

А>Ну а что мешает возвратить из метода get ссылку на переременную-член класса?
То, что по этой ссылке переменная будет изменена, а объект об этом ни сном, ни духом

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

см. выше

You will always get what you always got
  If you always do  what you always did

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

DV>и красивее и понятней и вызовов меньше...

DV>согласен кода меньше... а внутри? :) вызовы методов...
DV>Сейчас мне конечно скажут, что то аля : "В то время когда производительность процессоров ..." :)

DV>Простота не всегда достигается просто...

Все эти доводы верны и непосредственно приложимы к перегрузке операторов, например.
Далеко ходить не надо:

std::string a,b,c,d;
d.reserve(1024);
d  = a;
d += b;
d += c;

//либо
d = a + b + c;

программировать всегда надо головой :)

You will always get what you always got
  If you always do  what you always did

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

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

J>>Здравствуйте, Glоbus, Вы писали:

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


J>>Очень просто.

J>>сравни:

J>>

J>>a.x++;//вот читаю я код и задаюсь вопросом - это открытое поле класса или свойство
J>>

J>>и

а я вот задаюсь другим вопросом: "Почему ты задаешься этим вопросом? Что тебе дает эта информация?"

J>>

J>>int x = a.get_x();
J>>x++;
J>>a.set_x(x);
J>>

G>То есть не хочу разводить войну насчет пропертей, но саттер писал, что выбор надо делать в пользу прозрачности и понятности кода, и я лично с ним согласен. По моему субъективному мнению единственный недостаток пропертей — это именно неоднозначость при чтении кода.

и где здесь неоднозначность?
есть сомнения в том, что делает этот код?
По-моему, инкрементирует, и вариантов тут нету никаких :)

You will always get what you always got
  If you always do  what you always did

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

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

ssm>>обект класса А не получает вообше никаких уведомлений о измемении агрегата, поэтому приведенное тобой сравнениe

J>не совсем так
J>реально запись а.х++; (где х — свойство) должна разворачиваться в int х = а.get_х(); х++; а.set_х(х); , а в set_x объект обо всем узнает

ну тогда понадобится еше proxy обект, который этим будет занимацья...

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


J>>>

J>>>a.x++;//вот читаю я код и задаюсь вопросом - это открытое поле класса или свойство
J>>>

J>>>и

J>а я вот задаюсь другим вопросом: "Почему ты задаешься этим вопросом? Что тебе дает эта информация?"

ну например я могу составит ьсебе представление о дизигне класса. и во тя думаю — это товарищ поля как паблик объявил или это свойства. а если он по слабоумию делает и то и другое — то как сам понимаешь читабельность кода резко снижается (в это в том числе ответ на вопрос ниже где здесь неоднозначность).

J>>>

J>>>int x = a.get_x();
J>>>x++;
J>>>a.set_x(x);
J>>>

J>По-моему, инкрементирует, и вариантов тут нету никаких

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

J>программировать всегда надо головой :)

Согласен :)

Вы — уверен — ошибок подобных допускать не будете...
Но...
Если дать молодому программисту в руки эти пропертайсы — он такого наворотит :) а потом будет руками разводить — и почему же не всё так быстро :)
Думаю, когда ему захочется их себе сделать (допустим посредством перегрузки тех же операторов) он будет уже достаточно квалифицирован и мудр :)
Ведь смотря на Set и Get методы всё явно просматривается, чем c пропертайсом.
Почему то меня пугают веяния с Делфи, где (не обижайтесь) многие горе — программисты основную часть логики программы пишут в обработчиках...
Ничего в вашем предложении кроме сомнительной наглядности и простоты я не вижу...
Но я не сторонник того чтобы с++ упрощать...
Существует достаточно языков проще для ускоренной разработки... Менее мощные правда. Но простота всегда уменшает возможности...

ИМХО однако :)

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


DV>std::sqrt(ИМХО) однако

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

ssm>>>обект класса А не получает вообше никаких уведомлений о измемении агрегата, поэтому приведенное тобой сравнениe

J>>не совсем так
J>>реально запись а.х++; (где х — свойство) должна разворачиваться в int х = а.get_х(); х++; а.set_х(х); , а в set_x объект обо всем узнает

ssm>ну тогда понадобится еше proxy обект, который этим будет занимацья...

И нафиг такое счастье? Концепция свойств удобна, если поддерживаться непосредственно компилятором, иначе гиммор один.

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

Ш>Можно, но не отлично. Встроенная в язык реализация и синтаксически выразительнее, и не потребует ненужных накладных расходов.

Так в том-то и дело — не встраваются проперти в С++. Говорю как пописавший на билдере. Начиная с проблем конкретной реализации (не работают некоторые вполне типичные плюсовые конструкции) и заканчивая маразмом типа дублирования для существующих пропертей соответствующих геттеров/сеттеров, чтобы можно было их использовать в STL'ых функторах. Кому такое надо?

LVV>>Нефиг в транслятор засовывать.
Ш>Не могу согласиться. Очень не малое количество людей это бы оценило.

Я не оценил совершенно. Не надо оно в С++. Если только не собираетесь "писать на С++ как на дельфи".

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

J>2. А как насчет:
J>

J>++a.x;
J>--a.x;
J>a.x--;
J>a.x += 5;
J>c.x = a.x++ + ++b.x;
J>

В этом случае ошибка проектирования, IMHO.

Если сказано что так не делать, то зачем выделываться.
В таком случае завести нужно дополнительную функцию для выполнения действий.

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

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

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

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

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

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

__>>>>>>Мне кажется вызов функции более нагляден чем свойство.
J>>>>>я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так".
J>>>>>Вроде, ответил...

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

J>>>совершенно верно.
J>>>а отслеживать вообще ничего не надо, независимо от выбора между свойствами и функциями.
J>>>эта внутренняя переменная просто не нужна, все должно делаться через MoveWindow и GetWidth (или как там соответствующая функция API называется)
__>>Так ведь внутри есть какая-то переменная, которая меняется, так что переменная нужна
J>А откуда она взялась?
J>Имхо, в данном случае свойство должно реализовываться непосредственно через АПИ, без промежуточных переменных

Что-то я не понимаю.

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

P.S.
Не понял при чем здесь API.

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

AJD>И нафиг такое счастье? Концепция свойств удобна, если поддерживаться непосредственно компилятором, иначе гиммор один.


recursive jump

Автор: jazzer
Дата: 14.07.04

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

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

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

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

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

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

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

__>>>>>>>Мне кажется вызов функции более нагляден чем свойство.
J>>>>>>я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так".
J>>>>>>Вроде, ответил...

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

J>>>>совершенно верно.
J>>>>а отслеживать вообще ничего не надо, независимо от выбора между свойствами и функциями.
J>>>>эта внутренняя переменная просто не нужна, все должно делаться через MoveWindow и GetWidth (или как там соответствующая функция API называется)
__>>>Так ведь внутри есть какая-то переменная, которая меняется, так что переменная нужна :)
J>>А откуда она взялась?
J>>Имхо, в данном случае свойство должно реализовываться непосредственно через АПИ, без промежуточных переменных

__>Что-то я не понимаю.

__>Свойство же контроллирует что-то, а это что-то и есть переменная.
__>Как без нее ?

__>P.S.
__>Не понял при чем здесь API.

Ширина окна меняется через вызов MoveWindow, а получается через вызов GetWidth.
Никаких дополнительных переменных не нужно, get/set должны непосредственно превращаться в вызовы GetWidth/MoveWindow.
В этом сила свойств.
Точно так же ты можешь иметь член типа структура, а предоставлять доступ к его членам через соответствующие свойства так, что это бует выглядеть простым обращением.
Например, в ордере есть член типа Money, который держит внутри себя сумму ордера и валюту ордера.
Так вот никто тебе не мешает обявить у ордера свойства "сумма" и "валюта", которые на самом деле будут обращаться к твоему члену типа Money.

You will always get what you always got
  If you always do  what you always did

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

J>>программировать всегда надо головой :)

DV>Согласен :)

DV>Вы — уверен — ошибок подобных допускать не будете...
Все мы — люди ;)
DV>Но...
DV>Если дать молодому программисту в руки эти пропертайсы — он такого наворотит :) а потом будет руками разводить — и почему же не всё так быстро :)
Так и учатся, на своих ошибках.
Тот же программист будет радостно складывать строки или кидать вектора по значению, пока ему профайлер по голове не даст.

DV>Думаю, когда ему захочется их себе сделать (допустим посредством перегрузки тех же операторов) он будет уже достаточно квалифицирован и мудр :)
DV>Ведь смотря на Set и Get методы всё явно просматривается, чем c пропертайсом.
Те же аргументы выдвигаются явистами по поводу перегрузки операторов в С++.

DV>Почему то меня пугают веяния с Делфи, где (не обижайтесь) многие горе — программисты основную часть логики программы пишут в обработчиках...
никогда не писал на Дельфи :)

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

DV>Но я не сторонник того чтобы с++ упрощать...
а я — за :)
чем меньше пишется кода, тем меньше вероятность ошибки.
И вообще, все, что делается, делается для того, чтобы было проще. С++ — гигантское упрощение по сравнению с асмом.

DV>Существует достаточно языков проще для ускоренной разработки... Менее мощные правда. Но простота всегда уменшает возможности...
По-моему, пользоваться std::sort и std::string проще, чем qsort и char*. С приходом std возможностей стало меньше?

You will always get what you always got
  If you always do  what you always did

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

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

J>>2. А как насчет:
J>>

J>>++a.x;
J>>--a.x;
J>>a.x--;
J>>a.x += 5;
J>>c.x = a.x++ + ++b.x;
J>>

__>В этом случае ошибка проектирования, IMHO.

__>Если сказано что так не делать, то зачем выделываться.

Где сказано? ;)

You will always get what you always got
  If you always do  what you always did

Почитал я тут дискуссию по поводу "Свойств" на С++ и вот что скажу — для С++ затея плохо реализуемая.

Простой пример: что я получу указав "свойство" при вызове функции требующей ссылку? В С++ ссылки используются довольно часто. А в случае "свойства" какое значение должна принимать ссылка? Очевидно: ссылка не переменную не подходит, теряется "удобства" свойства, А ссылка на функцию set/get, это совсем не то что ожидается.
Конечно можно ругаться что ожидается lvalue, но тогда смысл всей этой дребедени? Удобства оно не прибавит, а вот путаницы... более чем.

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

J>По-моему, пользоваться std::sort и std::string проще, чем qsort и char*. С приходом std возможностей стало меньше?
Не стоит путать core language и билиотеку.

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

R>Почитал я тут дискуссию по поводу "Свойств" на С++ и вот что скажу — для С++ затея плохо реализуемая.
А еще придется вводить новое ключевое слово, еще придется вводить новый встроеный тип "указатель на свойство"...
И еще что касается геттеров/сеттеров то не забываем что в С++ есть перегрузка функций

struct some_type
{
    int some_prop()
    {
        return ...;
    }
    void some_prop(int value)
    {
        ...;
    }
};

и никаких префиксов/постфиксов get/set не надо.

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

__>>P.S.
__>>Не понял при чем здесь API.

J>Ширина окна меняется через вызов MoveWindow, а получается через вызов GetWidth.
J>Никаких дополнительных переменных не нужно, get/set должны непосредственно превращаться в вызовы GetWidth/MoveWindow.
J>В этом сила свойств.
Точно таким образом можно сделать в дополнение к GetWidth SetWidth, которая будет вызывать MoveWindow.
J>Точно так же ты можешь иметь член типа структура, а предоставлять доступ к его членам через соответствующие свойства так, что это бует выглядеть простым обращением.
Я бы предпочел если бы это выглядело как функция.
J>Например, в ордере есть член типа Money, который держит внутри себя сумму ордера и валюту ордера.
J>Так вот никто тебе не мешает обявить у ордера свойства "сумма" и "валюта", которые на самом деле будут обращаться к твоему члену типа Money.
Точно так же никто не мешает добавить функции : GetSumma и GetValuta, которые будут обращатся и к Money и к Kurs_Valuti и к Kurs_Valuti_na_Chernom_Rinke.