. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
В том, что при чтении/записи значения можно выполнить произвольные действия (помимо собственно обращения к полю). Например, класс "окно" может иметь свойство "ширина", при назначении значения которого вызывается ::MoveWindow(). ИМХО — красота подобного решения это дело вкуса.
Здравствуйте, LaptevVV, Вы писали:
LVV>В чем отличие от простых полей? Я на дельфях не писал.
Может в том, что можно при чтении/записи выполнять валидацию данных, какие-нить дополнительные действия по изменению состояния объекта ну и т.п. И в конце концов сами данные остаются скрытыми и могут быть изменены тока через паблик интерфейс. Хотя чем не угодили гетеры/сетеры — не понятно.
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
maq>Да в общем ни в чем. Это синтаксический сахар
Вот и мне так показалось. Тем более, что средствами С++, как у Дениса написано, можно это все отлично реализовать. Нефиг в транслятор засовывать.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
maq>>Да в общем ни в чем. Это синтаксический сахар LVV>Вот и мне так показалось. Тем более, что средствами С++, как у Дениса написано, можно это все отлично реализовать. Нефиг в транслятор засовывать.
В том виде, в каком свойства можно реализовать исключительно на с++, они нафиг никому не нужны. Если бы они были как в шарпе, в дельфях или хотя бы в VC — было бы круто.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал. > > В том, что при чтении/записи значения можно выполнить произвольные действия (помимо собственно обращения к полю). Например, класс "окно" может иметь свойство "ширина", при назначении значения которого вызывается ::MoveWindow(). ИМХО — красота подобного решения это дело вкуса.
Вот это как раз не прелесть, а ужас.
Концептуально, у объекта есть состояние и поведение (еще identity, но здесь это нас не интересует). Состоянием рекоммендуется манипулировать только через методы объекта (инкапсуляция). Когда мы начинаем манипулировать состоянием объекта напрямую (нарушение инкапсуляции) — это уже создает бардак в коде, так как нет гарантий, что инвариант класса не нарушен. Но когда изменение состояния вызывает еще какое-то поведение — это полный кошмар, т.к. из такого кода неясно, где просто изменяется переменная объекта, а где изменение состояния влечет за собой цепочку вызовов — поведение.
Здравствуйте, MaximE, Вы писали:
ME>Вот это как раз не прелесть, а ужас.
ME>Концептуально, у объекта есть состояние и поведение (еще identity, но здесь это нас не интересует). Состоянием рекоммендуется манипулировать только через методы объекта (инкапсуляция). Когда мы начинаем манипулировать состоянием объекта напрямую (нарушение инкапсуляции) — это уже создает бардак в коде, так как нет гарантий, что инвариант класса не нарушен.
Свойства нарушают инкапсуляцию? Каким образом
ME>Но когда изменение состояния вызывает еще какое-то поведение — это полный кошмар, т.к. из такого кода неясно, где просто изменяется переменная объекта, а где изменение состояния влечет за собой цепочку вызовов — поведение.
Перегруженные операторы присваивания в C++ делают тоже самое и никого это не пугает
"For every complex problem, there is a solution that is simple, neat,
and wrong."
AndrewJD wrote:
> Здравствуйте, MaximE, Вы писали: > > ME>Вот это как раз не прелесть, а ужас. > > ME>Концептуально, у объекта есть состояние и поведение (еще identity, но здесь это нас не интересует). Состоянием рекоммендуется манипулировать только через методы объекта (инкапсуляция). Когда мы начинаем манипулировать состоянием объекта напрямую (нарушение инкапсуляции) — это уже создает бардак в коде, так как нет гарантий, что инвариант класса не нарушен. > > Свойства нарушают инкапсуляцию? Каким образом
(хотя статья про Java, все верно)
> ME>Но когда изменение состояния вызывает еще какое-то поведение — это полный кошмар, т.к. из такого кода неясно, где просто изменяется переменная объекта, а где изменение состояния влечет за собой цепочку вызовов — поведение. > > Перегруженные операторы присваивания в C++ делают тоже самое и никого это не пугает
Не понял, что "то же самое" делают операторы присваивания?
ME>Не понял, что "то же самое" делают операторы присваивания?
когда изменение состояния вызывает еще какое-то поведение — это полный кошмар, т.к. из такого кода неясно, где просто изменяется переменная объекта, а где изменение состояния влечет за собой цепочку вызовов — поведение.
Т.е. операторы с таким же успехом могут повлечь за собой цепочку вызовов. Это проблема дизайна, а не свойств
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>В том, что при чтении/записи значения можно выполнить произвольные действия (помимо собственно обращения к полю). Например, класс "окно" может иметь свойство "ширина", при назначении значения которого вызывается ::MoveWindow(). ИМХО — красота подобного решения это дело вкуса.
Imho, изящнее сделать метод-модификатор: set....(..) и в нем устанавливать поле и выполнять прозвольные действия
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
maq>>>Да в общем ни в чем. Это синтаксический сахар LVV>>Вот и мне так показалось. Тем более, что средствами С++, как у Дениса написано, можно это все отлично реализовать. Нефиг в транслятор засовывать.
AJD>В том виде, в каком свойства можно реализовать исключительно на с++, они нафиг никому не нужны. Если бы они были как в шарпе, в дельфях или хотя бы в VC — было бы круто.
Был бы крутой бардак и не более. Приходилось как то с прогой возиться где проперти на каждом шагу, если бы не ВизуалАссист, который показывает ху есть ху, то повеситься можно просто.
Every choice has a good and bad side, and you make your choice in the context of overall criteria defined by necessity. Good and bad are not absolutes, however. A good decision in one context might be bad in another.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Denwer, Вы писали:
D>Был бы крутой бардак и не более. Приходилось как то с прогой возиться где проперти на каждом шагу, если бы не ВизуалАссист, который показывает ху есть ху, то повеситься можно просто.
И причем тут свойства? Можно все было с таким же успехом все слить в одну функцию с кучей goto. А по пооводу ху есть ху то перегрузка операторов ничем не лучше
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>И причем тут свойства? Можно все было с таким же успехом все слить в одну функцию с кучей goto. А по пооводу ху есть ху то перегрузка операторов ничем не лучше
Просто к перегрузке привыкли с самого начала, а к свойствам — нет. Тем более, что они поддерживаются только в диалекте VC (может быть, ещё в билдере? — не знаю).
И, как и другие MS-овские штучки, были прикручены туда не из любви к искусству, а под конкретную задачу. А именно, для автоматизации программирования COM-овских свойств.
Поскольку у COM-интерфейса нет публичных переменных, а есть только свойства — то любое обращение к состоянию (чтение или запись) вызывает поведение. Признав этот факт, можно в дальнейшем более не комплексовать на этот счёт.
Насколько поведение соответствует ожиданиям — это вопрос. Но вопрос не свойств как конструкции языка, а данного конкретного компонента. Если функция YourClass::getSomething()const модифицирует объект, скрытый за фасадом YourClass — идите к автору...
IMHO, основная прелесть свойств в том, что они позволяют красиво заткунь места, в которых кто-то поленился сделать setter/getter
Можно, конечно, громко кричать фии, но, IMHO, на практике вещь довольно полезная.
Они позволяют внести исправления в одном месте, а не перелопачивать весь код, заменяя прасваивания на вызов функции.
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
Сравнение :
public поля:
class A
{
public:
int x; // если x 0 то возвратить нужно 1
};
// использование
A a;
a.x=10;
int x=a.x;
// преимущества
// нет вызовов промежуточных функций - можно расмотреть как и недостаток
// проблемы
// невозможно отследить момент изменения поля
a.x=0; // не будет написана ошибка
// невозможно отследить момент получения поляint x=a.x; // x==0
свойства :
class A
{
public:
// синтакстис не важен
property(get_x,set_x) int x; // если x 0 то возвратить нужно 1private:
// реализация скрытаvoid set_x(int newx)
{
if(newx)
x=newx;
}
int get_x(void)
{
return x?x:1;
}
};
// использование
A a;
a.x=10;
int x=a.x;
// преимущества
// конроль над изменением переменной
a.x=0; // a.x не будет измененint x=a.x; // если x был 0 то возвратит 1
// действие задается неявно
функции :
class A
{
private:
// закрытое полецint x; // если x 0 то возвратить нужно 1public:
void set_x(int newx)
{
if(newx)
x=newx;
}
int get_x(void)
{
return x?x:1;
}
};
// использование
A a;
a.set_x(10);
int x=a.get_x();
// преимущества
// конроль над изменением переменной
a.set_x(0); // a.x не будет измененint x=a.get_x(); // если x был 0 то возвратит 1
// действие задается явно
Если посмотреть различие между доступом через функцию и доступом через свойство то разница в том что в случае свойства не видны реальные действия, а с доступом через поле действия задаются явно.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, maq, Вы писали:
maq>>Здравствуйте, LaptevVV, Вы писали:
LVV>>>Прочитал я тут статью Дениса Майдыковского
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
maq>>Да в общем ни в чем. Это синтаксический сахар LVV>Вот и мне так показалось. Тем более, что средствами С++, как у Дениса написано, можно это все отлично реализовать.
Можно, но не отлично. Встроенная в язык реализация и синтаксически выразительнее, и не потребует ненужных накладных расходов.
LVV>Нефиг в транслятор засовывать.
Не могу согласиться. Очень не малое количество людей это бы оценило. Мне кажется, что лучше ориентироваться на потребности программистов, а не на ревнителей чистоты языка и прочих "экспертов".
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
ME>Вот здесь разжевано, чем плохи свойства: C++ Properties -- a Library Solution
ME>-- ME>Maxim Yegorushkin
Нет ни одного аргумента. Только ссылка на мнение неких безымянных "экспертов".
Шахтер wrote:
> ME>Вот здесь разжевано, чем плохи свойства: C++ Properties -- a Library Solution > > Нет ни одного аргумента. Только ссылка на мнение неких безымянных "экспертов".
Лично для меня мнение эксперта — аргумент.
Вообще, я не вижу как property могут сделать мой код более элегантным, понятным, кратким и эффективным.
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
SDB>В том, что при чтении/записи значения можно выполнить произвольные действия (помимо собственно обращения к полю). Например, класс "окно" может иметь свойство "ширина", при назначении значения которого вызывается ::MoveWindow(). ИМХО — красота подобного решения это дело вкуса.
Чем хуже будет так :
class Window
{
int _width;
public:
int get_width() { return _width; }
void set_width(int width) { _width=width; MoveWindow(...); }
};
Здравствуйте, Glоbus, Вы писали:
G>Здравствуйте, LaptevVV, Вы писали:
LVV>>В чем отличие от простых полей? Я на дельфях не писал.
G>Может в том, что можно при чтении/записи выполнять валидацию данных, какие-нить дополнительные действия по изменению состояния объекта ну и т.п. И в конце концов сами данные остаются скрытыми и могут быть изменены тока через паблик интерфейс. Хотя чем не угодили гетеры/сетеры — не понятно.
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
Простые публичные поля нарушают инкапсуляцию.
Свойства позволяют работать с инкапсулированными данными как с обычными полями (с синтаксической точки зрения), но при этом инкапсуляция полностью сохранена, так как все происходит через операции get/set.
Здравствуйте, _nn_, Вы писали:
__>Здравствуйте, SchweinDeBurg, Вы писали:
SDB>>Здравствуйте, LaptevVV, Вы писали:
LVV>>>Прочитал я тут статью Дениса Майдыковского
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
SDB>>В том, что при чтении/записи значения можно выполнить произвольные действия (помимо собственно обращения к полю). Например, класс "окно" может иметь свойство "ширина", при назначении значения которого вызывается ::MoveWindow(). ИМХО — красота подобного решения это дело вкуса. :)
__>Чем хуже будет так : __>
Здравствуйте, _nn_, Вы писали:
__>Мне кажется вызов функции более нагляден чем свойство.
я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так".
Вроде, ответил...
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, _nn_, Вы писали:
__>>Мне кажется вызов функции более нагляден чем свойство. J>я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так". J>Вроде, ответил...
Я просто хочу сказать, что и в случае свойства и в случае функции нужно будет все отслеживать, следовательно разница только в работе извне, точнее как это выглядит.
Здравствуйте, ssm, Вы писали:
ssm>Здравствуйте, jazzer, Вы писали:
J>>сравни:
J>>
J>>a.x++;
J>>
J>>и
J>>
J>>int x = a.get_x();
J>>x++;
J>>a.set_x(x);
J>>
ssm>сравни:
ssm>
ssm>a.incAltitude();
ssm>and
ssm>a.x++;
ssm>
1. Altitude — это какое-то новое слово (в смысле, легко можно скатить в обсуждение смысловой составляющей кода, хотя изначально речь не об этом)
2. А как насчет:
Здравствуйте, _nn_, Вы писали:
__>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, _nn_, Вы писали:
__>>>Мне кажется вызов функции более нагляден чем свойство. J>>я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так". J>>Вроде, ответил...
__>Я просто хочу сказать, что и в случае свойства и в случае функции нужно будет все отслеживать, следовательно разница только в работе извне, точнее как это выглядит.
совершенно верно.
а отслеживать вообще ничего не надо, независимо от выбора между свойствами и функциями.
эта внутренняя переменная просто не нужна, все должно делаться через MoveWindow и GetWidth (или как там соответствующая функция API называется)
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, _nn_, Вы писали:
__>>Здравствуйте, jazzer, Вы писали:
J>>>Здравствуйте, _nn_, Вы писали:
__>>>>Мне кажется вызов функции более нагляден чем свойство. J>>>я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так". J>>>Вроде, ответил...
__>>Я просто хочу сказать, что и в случае свойства и в случае функции нужно будет все отслеживать, следовательно разница только в работе извне, точнее как это выглядит.
J>совершенно верно. J>а отслеживать вообще ничего не надо, независимо от выбора между свойствами и функциями. J>эта внутренняя переменная просто не нужна, все должно делаться через MoveWindow и GetWidth (или как там соответствующая функция API называется)
Так ведь внутри есть какая-то переменная, которая меняется, так что переменная нужна
если дело только в инкременте :)
а вообще дело я так понимаю не в одном инкременте и полезность этих проперти вылазит на ваш взгляд когда часто используешь их...
Тут я согласен...
:) Но разве что в том почему вам так кажется...
На самом деле если копнуть... То если вам часто требуется использовать этот проперти, то элегантней создать кеширующую переменную :) и с ней играться:
и красивее и понятней и вызовов меньше...
чем если:
a.x++;
a.x = a.y + b.x;
...
согласен кода меньше... а внутри? :) вызовы методов...
Сейчас мне конечно скажут, что то аля : "В то время когда производительность процессоров ..." :)
Простота не всегда достигается просто...
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
class X
{
public:
operator++()...
...
}
class A
{
public:
property x(type "X" get="getX" set="setX")
}
я немного не то хотел показать, сут в том,
что оператор инкремента и т.д. обрабатываются в обектах класса Х, а только после этого
происходит установка для агригируемого обекта в екземпляре класса А. При заведении метода
выражаюшего действия над обектом класса А будет суть операции понятней. В твоем примере:
++а.х;
--а.х;
а.х--;
обект класса А не получает вообше никаких уведомлений о измемении агрегата, поэтому приведенное тобой сравнениe
а.х++;
и
int х = а.get_х();
х++;
а.set_х(х);
совершенно не равназначны, в первом случае мы просто нарашиваем значение агрегата, а во втором мы даем обекту а
информазию о изменении агрегата
Ну а что мешает возвратить из метода get ссылку на переременную-член класса? Кроме того, логичнее и правильнее было бы реализовать два метода: один возвращает ссылку, а другой константную ссылку или копию переменной. Тогда в коде программы было бы видно зачем данная переменная член используется в данном месте и позволяло избежать глупых ошибок когда переменная-член в каком-то сложном выражении неожиданно изменяет свое значение.
А>Ну а что мешает возвратить из метода get ссылку на переременную-член класса? Кроме того, логичнее и правильнее было бы реализовать два метода: один возвращает ссылку, а другой константную ссылку или копию переменной. Тогда в коде программы было бы видно зачем данная переменная член используется в данном месте и позволяло избежать глупых ошибок когда переменная-член в каком-то сложном выражении неожиданно изменяет свое значение.
А как отслеживать изменения ?
class X
{
int x;
public:
int& get_x() { return x; }
};
X a;
a.get_x()=3; // как узнаем что x изменился ?
Здравствуйте, 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>
То есть не хочу разводить войну насчет пропертей, но саттер писал, что выбор надо делать в пользу прозрачности и понятности кода, и я лично с ним согласен. По моему субъективному мнению единственный недостаток пропертей — это именно неоднозначость при чтении кода.
Здравствуйте, _nn_, Вы писали:
__>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, _nn_, Вы писали:
__>>>Здравствуйте, jazzer, Вы писали:
J>>>>Здравствуйте, _nn_, Вы писали:
__>>>>>Мне кажется вызов функции более нагляден чем свойство. J>>>>я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так". J>>>>Вроде, ответил...
__>>>Я просто хочу сказать, что и в случае свойства и в случае функции нужно будет все отслеживать, следовательно разница только в работе извне, точнее как это выглядит.
J>>совершенно верно. J>>а отслеживать вообще ничего не надо, независимо от выбора между свойствами и функциями. J>>эта внутренняя переменная просто не нужна, все должно делаться через MoveWindow и GetWidth (или как там соответствующая функция API называется) __>Так ведь внутри есть какая-то переменная, которая меняется, так что переменная нужна :)
А откуда она взялась?
Имхо, в данном случае свойство должно реализовываться непосредственно через АПИ, без промежуточных переменных
А>Ну а что мешает возвратить из метода get ссылку на переременную-член класса?
То, что по этой ссылке переменная будет изменена, а объект об этом ни сном, ни духом
A>Кроме того, логичнее и правильнее было бы реализовать два метода: один возвращает ссылку, а другой константную ссылку или копию переменной. Тогда в коде программы было бы видно зачем данная переменная член используется в данном месте и позволяло избежать глупых ошибок когда переменная-член в каком-то сложном выражении неожиданно изменяет свое значение.
Здравствуйте, 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;
Здравствуйте, 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>То есть не хочу разводить войну насчет пропертей, но саттер писал, что выбор надо делать в пользу прозрачности и понятности кода, и я лично с ним согласен. По моему субъективному мнению единственный недостаток пропертей — это именно неоднозначость при чтении кода.
и где здесь неоднозначность?
есть сомнения в том, что делает этот код?
По-моему, инкрементирует, и вариантов тут нету никаких :)
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, ssm, Вы писали:
ssm>>обект класса А не получает вообше никаких уведомлений о измемении агрегата, поэтому приведенное тобой сравнениe
J>не совсем так J>реально запись а.х++; (где х — свойство) должна разворачиваться в int х = а.get_х(); х++; а.set_х(х); , а в set_x объект обо всем узнает
ну тогда понадобится еше proxy обект, который этим будет занимацья...
J>>>a.x++;//вот читаю я код и задаюсь вопросом - это открытое поле класса или свойство
J>>> J>>>и
J>а я вот задаюсь другим вопросом: "Почему ты задаешься этим вопросом? Что тебе дает эта информация?"
ну например я могу составит ьсебе представление о дизигне класса. и во тя думаю — это товарищ поля как паблик объявил или это свойства. а если он по слабоумию делает и то и другое — то как сам понимаешь читабельность кода резко снижается (в это в том числе ответ на вопрос ниже где здесь неоднозначность).
J>>>
J>>>int x = a.get_x();
J>>>x++;
J>>>a.set_x(x);
J>>>
J>По-моему, инкрементирует, и вариантов тут нету никаких
не факт. мож еще чего делает ( внутри геттера если это свойство ), а мож ничего не делает если это поле.
просто не нравится синтаксис, сходный с обращением к полю структуры — в этом на мой взгляд вся бедаю. хтя по большому счету это вопрос чисто эстетический и я бы на нем не заострялся.
Вы — уверен — ошибок подобных допускать не будете...
Но...
Если дать молодому программисту в руки эти пропертайсы — он такого наворотит :) а потом будет руками разводить — и почему же не всё так быстро :)
Думаю, когда ему захочется их себе сделать (допустим посредством перегрузки тех же операторов) он будет уже достаточно квалифицирован и мудр :)
Ведь смотря на Set и Get методы всё явно просматривается, чем c пропертайсом.
Почему то меня пугают веяния с Делфи, где (не обижайтесь) многие горе — программисты основную часть логики программы пишут в обработчиках...
Ничего в вашем предложении кроме сомнительной наглядности и простоты я не вижу...
Но я не сторонник того чтобы с++ упрощать...
Существует достаточно языков проще для ускоренной разработки... Менее мощные правда. Но простота всегда уменшает возможности...
ИМХО однако :)
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, ssm, Вы писали:
ssm>>>обект класса А не получает вообше никаких уведомлений о измемении агрегата, поэтому приведенное тобой сравнениe
J>>не совсем так J>>реально запись а.х++; (где х — свойство) должна разворачиваться в int х = а.get_х(); х++; а.set_х(х); , а в set_x объект обо всем узнает
ssm>ну тогда понадобится еше proxy обект, который этим будет занимацья...
И нафиг такое счастье? Концепция свойств удобна, если поддерживаться непосредственно компилятором, иначе гиммор один.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Шахтер, Вы писали:
Ш>Можно, но не отлично. Встроенная в язык реализация и синтаксически выразительнее, и не потребует ненужных накладных расходов.
Так в том-то и дело — не встраваются проперти в С++. Говорю как пописавший на билдере. Начиная с проблем конкретной реализации (не работают некоторые вполне типичные плюсовые конструкции) и заканчивая маразмом типа дублирования для существующих пропертей соответствующих геттеров/сеттеров, чтобы можно было их использовать в STL'ых функторах. Кому такое надо?
LVV>>Нефиг в транслятор засовывать. Ш>Не могу согласиться. Очень не малое количество людей это бы оценило.
Я не оценил совершенно. Не надо оно в С++. Если только не собираетесь "писать на С++ как на дельфи".
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, _nn_, Вы писали:
__>>Здравствуйте, jazzer, Вы писали:
J>>>Здравствуйте, _nn_, Вы писали:
__>>>>Здравствуйте, jazzer, Вы писали:
J>>>>>Здравствуйте, _nn_, Вы писали:
__>>>>>>Мне кажется вызов функции более нагляден чем свойство. J>>>>>я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так". J>>>>>Вроде, ответил...
__>>>>Я просто хочу сказать, что и в случае свойства и в случае функции нужно будет все отслеживать, следовательно разница только в работе извне, точнее как это выглядит.
J>>>совершенно верно. J>>>а отслеживать вообще ничего не надо, независимо от выбора между свойствами и функциями. J>>>эта внутренняя переменная просто не нужна, все должно делаться через MoveWindow и GetWidth (или как там соответствующая функция API называется) __>>Так ведь внутри есть какая-то переменная, которая меняется, так что переменная нужна J>А откуда она взялась? J>Имхо, в данном случае свойство должно реализовываться непосредственно через АПИ, без промежуточных переменных
Что-то я не понимаю.
Свойство же контроллирует что-то, а это что-то и есть переменная.
Как без нее ?
Здравствуйте, AndrewJD, Вы писали:
AJD>И нафиг такое счастье? Концепция свойств удобна, если поддерживаться непосредственно компилятором, иначе гиммор один.
Здравствуйте, _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.
Здравствуйте, Dj.ValDen, Вы писали:
J>>программировать всегда надо головой :)
DV>Согласен :)
DV>Вы — уверен — ошибок подобных допускать не будете...
Все мы — люди ;) DV>Но... DV>Если дать молодому программисту в руки эти пропертайсы — он такого наворотит :) а потом будет руками разводить — и почему же не всё так быстро :)
Так и учатся, на своих ошибках.
Тот же программист будет радостно складывать строки или кидать вектора по значению, пока ему профайлер по голове не даст.
DV>Думаю, когда ему захочется их себе сделать (допустим посредством перегрузки тех же операторов) он будет уже достаточно квалифицирован и мудр :) DV>Ведь смотря на Set и Get методы всё явно просматривается, чем c пропертайсом.
Те же аргументы выдвигаются явистами по поводу перегрузки операторов в С++.
DV>Почему то меня пугают веяния с Делфи, где (не обижайтесь) многие горе — программисты основную часть логики программы пишут в обработчиках...
никогда не писал на Дельфи :)
DV>Ничего в вашем предложении кроме сомнительной наглядности и простоты я не вижу...
А где было мое предложение?
Я ничего не предлагаю.
Я лишь показываю, в каких случаях свойства могут делать код элегантнее и проще. Не более того.
В своих собственных программах я свойства не использую.
DV>Но я не сторонник того чтобы с++ упрощать...
а я — за :)
чем меньше пишется кода, тем меньше вероятность ошибки.
И вообще, все, что делается, делается для того, чтобы было проще. С++ — гигантское упрощение по сравнению с асмом.
DV>Существует достаточно языков проще для ускоренной разработки... Менее мощные правда. Но простота всегда уменшает возможности...
По-моему, пользоваться std::sort и std::string проще, чем qsort и char*. С приходом std возможностей стало меньше?
Почитал я тут дискуссию по поводу "Свойств" на С++ и вот что скажу — для С++ затея плохо реализуемая.
Простой пример: что я получу указав "свойство" при вызове функции требующей ссылку? В С++ ссылки используются довольно часто. А в случае "свойства" какое значение должна принимать ссылка? Очевидно: ссылка не переменную не подходит, теряется "удобства" свойства, А ссылка на функцию set/get, это совсем не то что ожидается.
Конечно можно ругаться что ожидается lvalue, но тогда смысл всей этой дребедени? Удобства оно не прибавит, а вот путаницы... более чем.
Здравствуйте, jazzer, Вы писали:
J>По-моему, пользоваться std::sort и std::string проще, чем qsort и char*. С приходом std возможностей стало меньше?
Не стоит путать core language и билиотеку.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, rancorous, Вы писали:
R>Почитал я тут дискуссию по поводу "Свойств" на С++ и вот что скажу — для С++ затея плохо реализуемая.
А еще придется вводить новое ключевое слово, еще придется вводить новый встроеный тип "указатель на свойство"...
И еще что касается геттеров/сеттеров то не забываем что в С++ есть перегрузка функций
Здравствуйте, 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.
Здравствуйте, MaximE, Вы писали:
ME>Шахтер wrote:
>> ME>Вот здесь разжевано, чем плохи свойства: C++ Properties -- a Library Solution >> >> Нет ни одного аргумента. Только ссылка на мнение неких безымянных "экспертов".
ME>Лично для меня мнение эксперта — аргумент.
Ладно, не будем об экспертах. Мы и сами тут все с усами.
ME>Вообще, я не вижу как property могут сделать мой код более элегантным, понятным, кратким и эффективным.
ME>-- ME>Maxim Yegorushkin
А так?
class Vect
{
int *vect;
size_t vect_size;
public:
size_t size { get { return vect_size; } }
int * begin { get { return vect; } }
int * end { get { return vect+vect_size; } }
};
Не знаю. Если я пишу на C#, то я нахожу свойства и удобными, и полезными. Не вижу, что мешает включить их в С++.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, rancorous, Вы писали:
R>>Почитал я тут дискуссию по поводу "Свойств" на С++ и вот что скажу — для С++ затея плохо реализуемая. WH>А еще придется вводить новое ключевое слово, еще придется вводить новый встроеный тип "указатель на свойство"... WH>И еще что касается геттеров/сеттеров то не забываем что в С++ есть перегрузка функций WH>
J>>a.x++;//вот читаю я код и задаюсь вопросом - это открытое поле класса или свойство
J>>
f(x);//вот читаю я код и задаюсь вопросом - это функция, или указатель на функцию, или функтор?
//И у него(нее) один параметр? Или пять, из которых 4 по умолчанию?
//А может, это вообще шаблон неизвестно чего, инстанцированный неизвестно чем?
//А может, это объявление переменной х типа f, где f - это неизвестно где затерявшийся typedef?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, jazzer, Вы писали:
J>>По-моему, пользоваться std::sort и std::string проще, чем qsort и char*. С приходом std возможностей стало меньше? WH>Не стоит путать core language и билиотеку.
Сорри, не совсем понял, о чем ты.
qsort и куча функций strxxxx для работы с char* — это же библиотека.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Glоbus, Вы писали:
J>>>
J>>>a.x++;//вот читаю я код и задаюсь вопросом - это открытое поле класса или свойство
J>J>>
J>
J>f(x);//вот читаю я код и задаюсь вопросом - это функция, или указатель на функцию, или функтор?
J> //И у него(нее) один параметр? Или пять, из которых 4 по умолчанию?
J> //А может, это вообще шаблон неизвестно чего, инстанцированный неизвестно чем?
J> //А может, это объявление переменной х типа f, где f - это неизвестно где затерявшийся typedef?
J>
вишь как ты все правильно подметил . так зачем еще неоднозначности добавлять
Удачи тебе, браток!
Re[7]: Свойства в С++
От:
Аноним
Дата:
15.07.04 07:45
Оценка:
А>>Ну а что мешает возвратить из метода get ссылку на переременную-член класса? J>То, что по этой ссылке переменная будет изменена, а объект об этом ни сном, ни духом
Ну вот для этого и придумали ООП. Чтобы все изменения состояния объекта делались в одном месте — методе данного объекта. Тогда не нужно будет мучительно искать по коду в 100 тысяч строк где устанавливается неверная величина. Использование переменной-члена класса в выражениях плохой стиль с этим ведь ты спорить не будешь? Значит, использование свойств, поощряющее подобный стиль программирования, также является плохим стилем, ведущим к ошибкам в программе.
Re[7]: Свойства в С++
От:
Аноним
Дата:
15.07.04 07:53
Оценка:
Здравствуйте, _nn_, Вы писали:
__>А как отслеживать изменения ? __>
__>class X
__>{
__>int x;
__>public:
__>int& get_x() { return x; }
__>};
__>X a;
__>a.get_x()=3; // как узнаем что x изменился ?
__>
Легко завести промежуточный объект с перегруженными операциями, в которых и будет проверятся корректность изменения значения переменной и возвращать его. Этот способ имеет еще и то преимущество, что будут перегружены только те операции, которые с переменной-членом планируется произвести. Но, все это — следствие неверного подхода. Принцип ООП: состояние объекта можно менять только через методы данного объекта иначе мы снова скатываемся к процедурному программированию, что для больших программ приводит к большим же проблемам, чтобы избежать их и был ООП придуман.
Здравствуйте, Glоbus, Вы писали:
G>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, Glоbus, Вы писали:
J>>>>
J>>>>a.x++;//вот читаю я код и задаюсь вопросом - это открытое поле класса или свойство
J>> J>>>>
J>>
J>>f(x);//вот читаю я код и задаюсь вопросом - это функция, или указатель на функцию, или функтор?
J>> //И у него(нее) один параметр? Или пять, из которых 4 по умолчанию?
J>> //А может, это вообще шаблон неизвестно чего, инстанцированный неизвестно чем?
J>> //А может, это объявление переменной х типа f, где f - это неизвестно где затерявшийся typedef?
J>>
G>вишь как ты все правильно подметил :)) . так зачем еще неоднозначности добавлять
потому что лишняя маленькая неоднозначность на фоне огромного количества имеющихся никакой погоды не сделает :)
Главное в данном случае — естественный синтаксис, как в случае со скобками, когда не важно, с чем ты работаешь — с функцией или функтором и т.п., так и в случае с операцией доступа к полю (точка или стрелка), когда не важно, обращаешься ты к обычному полю или к свойству.
Если свойства ввести в язык, то это можно сделать корректно и гибко, в отличие от любой библиотечной реализации.
А это приятное свойство синтаксической идентичности с прямым доступом к члену очень играет на руку при написании шаблонов.
Твое "вот читаю я код и задаюсь вопросом" непосредственно приложимо к шаблонам в стиле той же STL с их использованием предикатов, куда можно засунуть как обычную функцию, так и функтор с какой угодно сложной логикой.
Опять же, как видишь, тут на форуме народ постоянно задается вопросом, что же такое iterator у vector или string — указатель или какой-то класс с хитрым поведением. В этом, конечно, есть определенная проблема, но это — плата за гибкость.
Или когда ты видишь запись типа a->x, ты ведь не можешь сказать, что такое а — указатель или класс с переопределенным operator->.
Важно, что код, который выглядит осмысленно, делает то, что написано, а как он это делает — через использование сотни промежуточных классов или напрямую — это уже не важно.
В этом — суть обобщенного программирования.
А настоящая мощь шаблонов, позволяющая им быть инструментов действительно обобщенного программирования, проявляется как раз при использовании подобного "синтаксического сахара" типа свойств, переопределенных операторов, автоматических разворачиваний цепочек вызовов operator->, автоматического выведения параметров шаблонных функций из типов аргуметов, и т.д. и т.п.
А>>>Ну а что мешает возвратить из метода get ссылку на переременную-член класса? J>>То, что по этой ссылке переменная будет изменена, а объект об этом ни сном, ни духом
А>Ну вот для этого и придумали ООП. Чтобы все изменения состояния объекта делались в одном месте — методе данного объекта. Тогда не нужно будет мучительно искать по коду в 100 тысяч строк где устанавливается неверная величина.
Со свойствами таких проблем не возникнет — у тебя ведь есть функция-сеттер. Поставь точку останова в нее и наслаждайся :)
A>Использование переменной-члена класса в выражениях плохой стиль с этим ведь ты спорить не будешь?
Буду :)
ООП — не священная корова. Все средства хороши к месту.
У меня нет никакого желания превращать свои программы в "огромное количество идиотских круглых скобок" :)
я считаю, что
a.x = b.x*(c.y + d.y);
выглядит гораздо лучше, чем
a.set_x(b.get_x()*(c.get_y() + d.get_y()));
A>Значит, использование свойств, поощряющее подобный стиль программирования, также является плохим стилем, ведущим к ошибкам в программе.
Если не секрет, зачем может понадобится производить такие манипуляции с членами класса? Если необходимо каким-то сложным образом изменить состояние объекта, то для этого вполне подойдет специальная функция-член объекта. ООП и был придуман затем чтобы избежать таких вот конструкций, которые, при раздувании кода, вызывают различные side-эффекты. То, что написано, не является написанием кода в стиле ООП, а известный процедурный стиль программирования. Конечно, программировать можно и, в некоторых случаях, необходимо, и с помощью этого стиля, но тогда зачем вообще классы использовать? Можно просто объявить четыре переменных a, b, c и d и дальше оперировать с ними подобным образом. Я не считаю ООП священной коровой, но, если используются понятие класс, то надо использовать парадигмы написания кода, соответствующие этому онятию. Т.е. если сказал А, надо говорить Б. Я не буду говорить здесь о том, что такой код нехорош уже тем, что непонятно зачем такое преобразование вообще делается. Неужели не проще и яснее завести метод типа CalcPolinom где произвести те же манипуляции?
Конечно, каждый человек имеет право на свое мнение и свою программу может писать в таком стиле как ему удобно, пусть если удобство это достигается путем проникновения через задний проход, но в промышленность такой код конечно, никто не допустит, да и вообще не ясно, дойдет ли программа, написанная таким стилем, до конечного пользователя.
Re[5]: Свойства в С++
От:
Аноним
Дата:
15.07.04 09:24
Оценка:
J>>>
J>>>a.x++;//вот читаю я код и задаюсь вопросом - это открытое поле класса или свойство
J>J>>
J>
J>f(x);//вот читаю я код и задаюсь вопросом - это функция, или указатель на функцию, или функтор?
J> //И у него(нее) один параметр? Или пять, из которых 4 по умолчанию?
J> //А может, это вообще шаблон неизвестно чего, инстанцированный неизвестно чем?
J> //А может, это объявление переменной х типа f, где f - это неизвестно где затерявшийся typedef?
J>
Ну зачем же так сразу f(x)? не лучше ли назвать этот метод Increment_x и убрать все эти проблемы с неоднозначностью? А что такое Increment_x, шаблон или неизвестно чего, проще всего выяснить по его типу, как это компилятор делает. Если же в данном методе хочется еще и избежать проблем с параметрами по умолчанию, то выход прост как все гениальное: не ставь эти параметры! В данной случае вообще параметров не нужно что есть хорошо, как сказал Создатель на шестой день творения. Не надо усложнять вещи там где нет в этом необходимости. На языке си++это звучит как: не плоди объекты без нужды .
J>>a.x = b.x*(c.y + d.y);
А>Если не секрет, зачем может понадобится производить такие манипуляции с членами класса? Если необходимо каким-то сложным образом изменить состояние объекта, то для этого вполне подойдет специальная функция-член объекта. ООП и был придуман затем чтобы избежать таких вот конструкций, которые, при раздувании кода, вызывают различные side-эффекты. То, что написано, не является написанием кода в стиле ООП, а известный процедурный стиль программирования. Конечно, программировать можно и, в некоторых случаях, необходимо, и с помощью этого стиля, но тогда зачем вообще классы использовать? Можно просто объявить четыре переменных a, b, c и d и дальше оперировать с ними подобным образом. Я не считаю ООП священной коровой, но, если используются понятие класс, то надо использовать парадигмы написания кода, соответствующие этому онятию. Т.е. если сказал А, надо говорить Б. Я не буду говорить здесь о том, что такой код нехорош уже тем, что непонятно зачем такое преобразование вообще делается. Неужели не проще и яснее завести метод типа CalcPolinom где произвести те же манипуляции?
А>Конечно, каждый человек имеет право на свое мнение и свою программу может писать в таком стиле как ему удобно, пусть если удобство это достигается путем проникновения через задний проход, но в промышленность такой код конечно, никто не допустит, да и вообще не ясно, дойдет ли программа, написанная таким стилем, до конечного пользователя.
Если честно, не вижу тут заднепроходных способов, скорее, таковым я склонен считать лозунг "все через геттеры/сеттеры" (в общем-то, как и любой другой лозунг). Потому что все средства хороши к месту.
В конце концов, очень многие парадигмы не дружат друг с другом, например, спецификации исключений и наследование. Или они же и шаблоны.
А другие парадигмы — очень даже дружат, например, ООП и структурное программирование.
Потому что ООП — это то, как общаются объекты и классы между собой, а внутри этих классов — старое доброе СП, хоть и сдобренное всякими наследованиями и прочими виртуальностями.
Почему, если я написал слово class, я немедленно должен все делать синтаксически через геттеры-сеттеры?
9/10 кода, использующего геттеры и сеттеры, используют их тривиальные реализации, которые абсолютно ничем не отличаются от прямого доступа к члену класса, за исключением очень большого неудобства использования.
И я считаю естественным желание людей писать простой и понятный код, который будет выглядеть так, как он должен выглядеть.
И если есть средство успокоить и наших, и ваших, предоставив естественный синтаксис, упрятав при этом под ним вызовы геттеров-сеттеров — я обеими руками за это средство.
P.S. Раз уж мы коснулись этой темы, смею уверить, мои программы доходили до конечного пользователя, и эти пользователи оставались очень довольными как кодом, так и работой программы.
You will always get what you always got
If you always do what you always did
Re[11]: Свойства в С++
От:
Аноним
Дата:
15.07.04 10:33
Оценка:
J>Если честно, не вижу тут заднепроходных способов, скорее, таковым я склонен считать лозунг "все через геттеры/сеттеры" (в общем-то, как и любой другой лозунг). Потому что все средства хороши к месту.
Таковой лозунг я не декларировал. Я говорил о принципе ООП: состояние объекта должно меняться ТОЛЬКО в методах самого объекта. Этот простой принцип был придуман не просто так, а после длинных бессонных ночей перед выпуском програмных продуктов, когда, в программе из более чем 100 тысяч строк, что-то не работает и непонятно прежде всего ГДЕ произошло нежелательное изменение состояния программы. Следуя же принципу выше очень просто решить первую задачу исправления дефекта программы: локализацию ошибки. Ради этого, в общем, все и было задумано.
Не хотел никого оскорбить и обидеть когда писал про заднепроходный стиль, но неужели ты всерьез полагаешь, что все эти горы документации по стилю, люди, которые специально нанимаются для того, чтобы контролировать стиль написания и черт знает еще какая уйма денег которая тратится, все это было сделано просто так, ради любви к красоте? Мне кажется, совсем наооборот; люди были к этому вынуждены. Я понимаю, что это не аргумент, как вообще оценка человечеством каких-то идей для многих людей не является аргументом, но таки стоит задуматься, что может все это не зря делается раз столько людей этим занимается?
Вообще, путь отрицания авторитетов ведет прямо в маргинальную группу. Есть маргиналы физики, ученые, которые не признают например, теории относительности Эйнштейна, есть просто маргиналы — люди, не признающие правил, установленных в социуме, в котором они проживают, а есть маргиналы — программисты, не признающие очевидных истин, опыта, выработанного человечеством за 40 лет существования данного вида деятельности.
В общем, спорить здесь бесполезно, все аргументы были высказаны и не услышаны, но все таки, прислушиваться к чужому мнению хоть иногда, но следует.
Спасибо за лекцию, конечно :)
Только она не имеет никакого отношения к свойствам, ибо свойства работают через геттеры и сеттеры, и никто не мешает поставить точку останова или отладочную печать в сеттер и проследить, где что изменилось.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, jazzer, Вы писали:
WH>Блин как все просто у тебя получается... тогда напиши спецификацию свойств, а мы посмотрим так ли это просто как тебе кажется.
простым должно быть использование свойств, а реализация — уж как получится.
если честно, я бы рад внести свой вклад :) да времени нет.
Да и не уверен я, что свойства корректно реализуемы в полном объеме (т.е. с поддержкой указателей на свойства и т.п.)
J>>>По-моему, пользоваться std::sort и std::string проще, чем qsort и char*. С приходом std J>>>возможностей стало меньше?
WH>>Не стоит путать core language и билиотеку.
j> Сорри, не совсем понял, о чем ты. j> qsort и куча функций strxxxx для работы с char* — это же библиотека.
А проперти пойдут в core language, вот в этом и разница.
Здравствуйте, Андрей Галюзин, Вы писали:
АГ>Жаль, что анонимно: оценку ставить бессмысленно.
твоя оценка помогла бы другим, тем, кто предпочитает читать сообщения с оценками, подсознательно считая их потенциально более интерестными(корректными).
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, _nn_, Вы писали:
__>>А как отслеживать изменения ? __>>
__>>class X
__>>{
__>>int x;
__>>public:
__>>int& get_x() { return x; }
__>>};
__>>X a;
__>>a.get_x()=3; // как узнаем что x изменился ?
__>>
А>Легко завести промежуточный объект с перегруженными операциями, в которых и будет проверятся корректность изменения значения переменной и возвращать его. Этот способ имеет еще и то преимущество, что будут перегружены только те операции, которые с переменной-членом планируется произвести. Но, все это — следствие неверного подхода. Принцип ООП: состояние объекта можно менять только через методы данного объекта иначе мы снова скатываемся к процедурному программированию, что для больших программ приводит к большим же проблемам, чтобы избежать их и был ООП придуман.
А теперь посмотрим на это с другой стороны :
class A
{
int u;
int v;
int w;
int x;
int y;
int z;
};
И так для каждого нужно заводить класс для отслеживания изменений, а как класс A узнает об изменениях ? Нужно ему сообщить -> еще накладные расходы.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, jazzer, Вы писали:
WH>Блин как все просто у тебя получается... тогда напиши спецификацию свойств, а мы посмотрим так ли это просто как тебе кажется.
А чего их писать -- заимствуем синтаксис из шарпа. Всё уже придумано давно.
Здравствуйте, Шахтер, Вы писали:
WH>>Блин как все просто у тебя получается... тогда напиши спецификацию свойств, а мы посмотрим так ли это просто как тебе кажется.
Ш>А чего их писать -- заимствуем синтаксис из шарпа. Всё уже придумано давно.
Или из VC:
class C
{
public:
__declspec(property(get=getx,set=setx)) int x;
public:
int getx() const { ..... };
private:
int getx() { ..... };
public:
void setx(int) { ..... };
protected:
virtual void setx(string) { ..... };
};
Отчасти так даже лучше: можно вовсю использовать overload и override, можно указывать доступ к каждой сигнатуре (private/protected/public) наконец, не стоит вопрос об указателях.
Шарповый стиль предположит иное:
class C
{
public:
int x
{
// эквивалент вышенаписанному
get() const;
get();
set(int);
set(string);
// или попросту, буквально
get;
set;
}
};
Ключевое слово set войдёт в конфликт с std::set.
Как выносить определения из объявления класса?
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
Я, как упомянутый в начале этой самой статьи, просто не могу пройти мимо
Первое.
У меня в то далекое время была конкретная проблема. А именно, был довольно сложный математический код, представляющий "геометрические" объекты, состоящие просто из некоторого числа вершин, в многомерном пространстве. Модификацией с помощью довольно хитрых DCM алгоритмов этих объектов в пространстве очень эффективно искался экстремум функций, зависящей от 2 — 15 параметров, в более многомерных случаях алгоритм начинал тормозить (тут cкорее подойдут вариации обычного случайного поиска, рекламно именуемые "генетическими алгоритмами").
Так вот, написано это все было на Дельфи. Был класс точки, который кэшировал значение целевой функции в этой точке, заодно подсичитывая всякую интересную статистику. Был класс многомерной фигуры, который кэшировал разные критерии качества для этой фигуры.
Ну и вычисления записывалмсь доволно просто.
Бессмысленный пример от балды:
Тут я уже видел возражение, что для таких вещей надо заводить специальную функцию, а то ООП нарушается, side-эффекты всякие-разные возникают. Так вот, суть всей программы состояла в большом количестве таких вот функций. И все эти функции ровно в таком виде (только с нижними индексами ) были изложены в научных статьях, так что можно было просто взять формулу и набить так, как она есть.
Попробуйте себе представить, как бы это выглядело, если бы вместо индексных свойств здесь использовались get_Point set_Point get_Axis set_Axis итд.
У меня встала задача переписать это все на С++. Так как в то время я плоховато знал C++, то для меня было откровением, что перегружая operator=, operator[] и возвращая references на proxy-объекты можно добиться нужного эффекта и в С++, в котором, как заявлялось, свойств нет. Ну и случайно попалась дискуссия на тему "в С++ нет свойств" в фидошной эхе...
Второе. К свойствам вообще.
Споры на тему необходимости свойств это скорее вопрос психологии.
Для меня, программиста с коммерческим стажем С++ в 4 года, абсолютно понятно, что запись Form1.Width = 20; воспринимается натуральнее и интуитивно понятнее, чем вызов SetWindowPos, в который надо передавать хитрые константы, указывающие, какие параметры использовать, а какие нет. И это при том, что в 1 и 2 Дельфи было плохо с подсказкой, и приходилоь часто заглядывать в help. Я так ненавистный английский выучил . И понятно, что нормальный человек после выполения такой строчки ожидает увидеть, что ширина окна на экране тоже изменилась. И только богатый опыт убивает это, заставляя человека думать вопреки тому, что он видит. Это как левшей переучивать.
Если кому-то вызов set_something и get_something кажется понятнее, то это не из-за его генетических особенностей, а из-за привычки, в том числе из-за дурной привычки к структурам из неинкапсулированных POD типов.
Когда же любой член класса всегда является на самом деле свойством, то тогда становится непонятно, зачем везде писать get_ и set_, засоряя не самую мощную систему распознавания человеческого мозга ненужным мусором. Потому что и так понятно — если вы вызываете что-то через (), то это функция, а если нет — то это свойство (хотя на эту тему в синтаксисе OPascal есть недостаток, которым я не пользовался).
И если человек, после изменения члена класса Width, считает, что теперь нужно вызвать какую-нибудь функцию, чтобы это нарисовалось на экране, то этот человек заражен программированием на процедурном plain C.
Иногда вопрос объясняют эффективностью, так как в основе концепции языка С++ — сохранение возможности писать такие же эффективные программы, как и на plain C. В моем случае, использование только кэширования позволило увеличить скорость алгоритма в 1.5 тысячи раз. Дальнейшее улучшение не имело смысла Не скоро еще современная промышленность сможет добиться такого коэфициента за счет снижения размеров транзисторов...
Вместе с тем, в оригинальном языке С++ свойства конечно же не нужны, и их можно эмулировать
вышеуказанным в статье образом, хотя сам этот образ и напрашивается на нецензурные определения, так как не всякий индус, извините, сможет осилить данный образ, извините, без специальной подготовки. Но самое-то главное, свойства — удобны,
а это совершенно не в духе идеологии языка (в смысле главного идеолога), достаточно IMHO почитать его высказывания в c++.moderated.
Подводя черту.
1.Каждый программист С++ должен понять, что лишние ключевые слова — это ЗЛО, так как ускоряют компиляцию, что снижает продажи процессоров и новых компьютеров, а еще потребность в программистах. Поэтому архитекторы языка одобряют только такие нововведения, которые замедляют компиляцию, особенно если они контекстн-зависимо используют уже существующие ключевые слова, а еще лучше — символы, например + или *. Новый оригинальный подход — это делать такие ключевые слова, которые в определенных местах — ключевые слова, а в других местах — обычные идентификаторы. Привет фортрану.
2.С++, в силу тяжелой истории, — язык очень сложный и запутаный, и нечего плодить дальнейшие "сложности", и если что-то уже можно сделать каким-либо образом, то пускай оно так и будет.
Перекуём баги на фичи!
твоя оценка помогла бы другим, тем, кто предпочитает читать сообщения с оценками, подсознательно считая их потенциально более интерестными(корректными).
