Здравствуйте, Андрей Галюзин, Вы писали:
АГ>Жаль, что анонимно: оценку ставить бессмысленно.
твоя оценка помогла бы другим, тем, кто предпочитает читать сообщения с оценками, подсознательно считая их потенциально более интерестными(корректными).
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, _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 узнает об изменениях ? Нужно ему сообщить -> еще накладные расходы.
Следовательно этот принцип он не выгодный.
Здравствуйте, Шахтер, Вы писали:
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.
Как выносить определения из объявления класса?
Здравствуйте, LaptevVV, Вы писали:
LVV>Прочитал я тут статью Дениса МайдыковскогоАвтор(ы): Денис Майдыковский
В этой статье автор рассматривает различные способы реализации свойств в
стиле Visual Basic на C++. Некоторые способы специфичны для Visual C++,
тогда как другие годятся для применения в любой программе, написанной на
языке C++.
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
Я, как упомянутый в начале этой самой статьи, просто не могу пройти мимо
Первое.
У меня в то далекое время была конкретная проблема. А именно, был довольно сложный математический код, представляющий "геометрические" объекты, состоящие просто из некоторого числа вершин, в многомерном пространстве. Модификацией с помощью довольно хитрых DCM алгоритмов этих объектов в пространстве очень эффективно искался экстремум функций, зависящей от 2 — 15 параметров, в более многомерных случаях алгоритм начинал тормозить (тут cкорее подойдут вариации обычного случайного поиска, рекламно именуемые "генетическими алгоритмами").
Так вот, написано это все было на Дельфи. Был класс точки, который кэшировал значение целевой функции в этой точке, заодно подсичитывая всякую интересную статистику. Был класс многомерной фигуры, который кэшировал разные критерии качества для этой фигуры.
Ну и вычисления записывалмсь доволно просто.
Бессмысленный пример от балды:
X[ii][jj] = X[ii][jj]*2 - Y[kk][ll]*X[ii][jj]*X[ii].f;
Тут я уже видел возражение, что для таких вещей надо заводить специальную функцию, а то ООП нарушается, 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.С++, в силу тяжелой истории, — язык очень сложный и запутаный, и нечего плодить дальнейшие "сложности", и если что-то уже можно сделать каким-либо
образом, то пускай оно так и будет.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Шахтер, Вы писали:
К>Шарповый стиль предположит иное:
К>К>class C
К>{
К>public:
К> int x
К> {
К> // эквивалент вышенаписанному
К> get() const;
К> get();
К> set(int);
К> set(string);
К> // или попросту, буквально
К> get;
К> set;
К> }
К>};
К>
К>Ключевое слово set войдёт в конфликт с std::set.
К>Как выносить определения из объявления класса?
int C::x::get() const
{
}
void C::x::set(int)
{
}
... << RSDN@Home 1.1.0 stable >>
Перекуём баги на фичи!
