// Описание свойства только для записи
template<class owner_t, class value_t>
struct domen_write_only_t
{
typedef void (owner_t::*set_method_t) (const value_t &);
template<set_method_t set_method>
class property_write_only_t
{
owner_t& m_owner;
public:
property_write_only_t(owner_t& a_owner) : m_owner(a_owner) { ; }
const value_t& operator = (const value_t& a_value)
{
(m_owner.*set_method)(a_value);
return a_value;
}
};
};
class sample_t
{
private:
double m_val;
public:
void set_value(const double& a_val)
{
m_val = a_val;
}
domen_write_only_t<sample_t, double> ::
property_write_only_t <set_value> val;
sample_t(): m_val(0.), val(*this)
{
}
};
Можно ли реализовать свойства шаблонного класса?
Вот пример обычного описания свойства для записи и использование его в тестовом классе sample_t.
Здесь для простоты приведен пример свойства, реализующего только запись.
Возможно ли реализовать подобные свойства для шаблонного класса?
Например для класса sample2_t:
Код:
Здесь для простоты приведен пример свойства, реализующего только запись.
Возможно ли реализовать подобные свойства для шаблонного класса?
Например для класса sample2_t:
Код:
template<class T>
class sample2_t
{
private:
T m_val;
public:
void set_value(const T& a_val)
{
m_val = a_val;
}
sample2_t(): m_val(0)
{
}
};
class sample2_t
{
private:
T m_val;
public:
void set_value(const T& a_val)
{
m_val = a_val;
}
sample2_t(): m_val(0)
{
}
};
Цитата: !Волк
В предыдущем моем примере запись вида
Код:
table.cells[1][2] = 5;
Код:
table[1][2] = 5;
Меня интересует именно первый вариант, поскольку в одном классе может потребоваться индексированный доступ к различным данным.
Записью table.cells ты сообщаешь, что table агрегирует cells.
Ну так и в чем проблема?
Код:
class Table
{
public:
vector< vector<int> > cells;
};
{
public:
vector< vector<int> > cells;
};
Цитата: !Волк
Кстате, я предпочитаю использовать в качестве таблицы просто
Код:
vector<T>
Код:
vector<vector<T> >
Ну это не серьезно :)
Цитата: Green
Но ты назвал его одним из пунктов, и я ответил тебе по этому пункту.
Нет, ты сделал на этом акцент, а вторую часть цитаты опустил и получилось, что мое заявление звучало как - "без справки не понять".
Цитата: Green
Может тебя в бан отправить?
Мне ответить публично?
Цитата: Green
Идиотская улыбка показывает идиотизм твоего примера?
Заметь, я свое мнение на счет твоего интыллекта держу при себе.
Цитата: Green
...
поэтому по-тихому и слил.
...
Тогда ты все удачно слил...
Пожайлуста не повторяй по нескольку раз я не глухой:)
Цитата: Green
Это самый весомый твой аргумент в защиту "удобства" :D
Впрочем, после твоего "шедевра" с примером "удобства"... информативностью является количество букв? :D
Стоит смайлик, ясно, что это шутка. А ты, наивный, принял все за чистую монету.
Однако в каждой шутке есть доля правды, и твои аргументы такие же бредовые:
видим строчку - set_value(1);
Что за аргумент - информативность в префиксе set_? Ты что-нибудь можешь сказать кроме того, что этот метод устанавливает какое-то значение, какого типа, что возвращает и устанавливает-ли вообще без ознакомления с кодом?
Я к тому, что как вообще можно о чем-то говорить не залезая в описание класса, а там (по крайней мере для меня) информативность одинаковая как для описания св-в, так и просто методов чтения записи.
Цитата: Green
В противовес всем тем вменяемым и обоснованным аргументам, которые привели другие участники обсуждения?
это Вы про себя во множественном числе?
Цитата: Green
P.S. Если твои сообщения не начнут носить информативный характер, мне придется их удалить, начиная с первого.
а давай я фсе свои сообщения буду начинать с префикса set_, а? это информативно будет?
P.S. и пожайлуста дружиЩе не надо обИжаться, обзываться и удалять сообщения пользуясь служебным положением...
Цитата: GIZMO
<мусор проигнорирован>
и твои аргументы такие же бредовые:
видим строчку - set_value(1);
Что за аргумент - информативность в префиксе set_? Ты что-нибудь можешь сказать кроме того, что этот метод устанавливает какое-то значение, какого типа, что возвращает и устанавливает-ли вообще без ознакомления с кодом?
Я к тому, что как вообще можно о чем-то говорить не залезая в описание класса, а там (по крайней мере для меня) информативность одинаковая как для описания св-в, так и просто методов чтения записи.
Я говорил не только об имени метода. Видимо остального ты не заметил или не понял.
Два моих основных аргумента:
1) такой подход (использование "свойств") ИЗЛИШНЕ запутывает код;
2) добавляет потенциальных багов.
Есть чем оспорить?
Твоих аргументов так и не видно. Пока вижу только хамство и пустословие,- яркий признак, что сказать то нечего.
Цитата: GIZMO
P.S. и пожайлуста дружиЩе не надо обИжаться, обзываться и удалять сообщения пользуясь служебным положением...
Это положение на то и дано, чтоб вычищать мусор наносимый неадекватными личностями.
Цитата: GIZMO
Однако в каждой шутке есть доля правды, и твои аргументы такие же бредовые:
видим строчку - set_value(1);
Что за аргумент - информативность в префиксе set_? Ты что-нибудь можешь сказать кроме того, что этот метод устанавливает какое-то значение, какого типа, что возвращает и устанавливает-ли вообще без ознакомления с кодом?
видим строчку - set_value(1);
Что за аргумент - информативность в префиксе set_? Ты что-нибудь можешь сказать кроме того, что этот метод устанавливает какое-то значение, какого типа, что возвращает и устанавливает-ли вообще без ознакомления с кодом?
Это давний холивар. Он и для Java vs C# справедлив: что лучше - свойства или геттеры/сеттеры.
Я вот горой за свойства - они удобнее и человечнее, чем безликие методы, они агрегируют функционал получения/изменения значения, отлично вписываются в ООП идеологию.
Но вот в C++ я резко против использования шаблонов для реализации подобного функционала, так как приведенная модель реализации, на мой взгляд, слишком сложная для понимания, да и реализация хромает (наверняка будут идиотские случаи-исключения, это ж C++). Шаблоны C++ не приспособлены для метапрограммирования, а привнесение в язык новой структуры и есть метапрограммирование.
Цитата: hardcase
Но вот в C++ я резко против использования шаблонов для реализации подобного функционала, так как приведенная модель реализации, на мой взгляд, слишком сложная для понимания, да и реализация хромает (наверняка будут идиотские случаи-исключения, это ж C++). Шаблоны C++ не приспособлены для метапрограммирования, а привнесение в язык новой структуры и есть метапрограммирование.
думаю, что если бы разработчики задались целью и в stl включили шаблоны, поддерживающие свойства, т.е. это было бы сделано на профессиональном уровне с соответствующим тестированием и пр. то получилось бы и удобно и читаемо (один раз врубился как работает и дальше пользуешься), и холивара такого бы не вызывало.
Цитата: oxotnik333
думаю, что если бы разработчики задались целью и в stl включили шаблоны, поддерживающие свойства, т.е. это было бы сделано на профессиональном уровне с соответствующим тестированием и пр. то получилось бы и удобно и читаемо (один раз врубился как работает и дальше пользуешься), и холивара такого бы не вызывало.
"Свойства" не уживаются с шаблонами, т.о. включение "свойств" в STL, свело бы на нет всю остальную STL. :)
Цитата: Green
"Свойства" не уживаются с шаблонами, т.о. включение "свойств" в STL, свело бы на нет всю остальную STL. :)
Не вижу связи между присутствием свойств и ненужностью stl. :)
Свойства штука хорошая, но только когда нативны. Написать подобный геморой сам когда давно пытался, думая что это круто. Оказалось что не очень круто. :) Хотя, утверждать что такой подход неверен всегда - неправильно. Все хорошо в меру и зависит от конкретной задачи.
Цитата: Nixus
Не вижу связи между присутствием свойств и ненужностью stl. :)
Кто говорил о ненужности?
Я сказал "может свести на нет", т.к. "свойства" эти не дружат с шаблонами.
Цитата: Nixus
Хотя, утверждать что такой подход неверен всегда - неправильно. Все хорошо в меру и зависит от конкретной задачи.
Такой подход не верен изначально и мера тут не при чем.
Цитата: kot_
Т.е. за легкость использования приходиться платить - и это кстати одна из причин - почему билдеровские ехешники имеют столь монструозные размеры - использование где надо и не надо инлайн-функций и использование пропертей.
Монструозные они вовсе не от свойств или inline-функций. :)
Цитата: Green
Кто говорил о ненужности?
Я сказал "может свести на нет", т.к. "свойства" эти не дружат с шаблонами.
Я сказал "может свести на нет", т.к. "свойства" эти не дружат с шаблонами.
Все равно не вижу связи. :)
Цитата: Green
Такой подход не верен изначально и мера тут не при чем.
Это подход. Он не верен и не неверен, он просто есть. Догматические подходы на мой взгляд еще хуже. :)
Цитата: Nixus
Все равно не вижу связи. :)
Какой связи ты не видишь?
Цитата: Nixus
Это подход. Он не верен и не неверен, он просто есть. Догматические подходы на мой взгляд еще хуже. :)
Где ты видишь догматические подходы? Скорее, высказывание, что "всё сотворенное с божей милостью имеет свое место под солнцем", больше смахивает на догму.
Есть вполне объективная аргументация, что подход запутывает код и увеличивает возможность ошибок. При этом никаких аргументов "за", кроме "это красивенько", нет.
Цитата: Green
Какой связи ты не видишь?
Не вижу как свойства сведут на нет stl.
Цитата: Green
Где ты видишь догматические подходы?
Вот тут:
Есть вполне объективная аргументация, что подход запутывает код и увеличивает возможность ошибок. При этом никаких аргументов "за", кроме "это красивенько", нет.
Если ты не решал каких-то задач, где был бы уместен такой подход, то это не значит, что таких задач не существует.
Цитата: Green
Скорее, высказывание, что "всё сотворенное с божей милостью имеет свое место под солнцем", больше смахивает на догму.
При чем тут божья милость?
Цитата: Nixus
Монструозные они вовсе не от свойств или inline-функций. :)
да ну?
т.е. чем больше по 4 байта тем лучше.
Цитата: Nixus
Не вижу как свойства сведут на нет stl.
Standard Template Library - библиотека построенная на шаблонах, а "свойства" не дружат с шаблонами. Отсюда делаю предположение, что "свойства" могут свести на нет использование STL, в т.ч. сильно затруднит использование.
Более того, "свойства" не дружат с классами. Другими словами "свойство" не может быть проксёй для класса или структуры. Только для простых типов (int, char, double).
Цитата: Nixus
Если ты не решал каких-то задач, где был бы уместен такой подход, то это не значит, что таких задач не существует.
Мой опыт говорит, что задач, где был бы уместен такой подход, нет.
Логика говорит, что задач, где нельзя обойтись без свойств , тоже нет.
Здравый смысл говорит, что использование "свойств" может привнести ошибки в код.
Вывод: "свойства" лучше не использовать.
Цитата: kot_
да ну?
т.е. чем больше по 4 байта тем лучше.
т.е. чем больше по 4 байта тем лучше.
При чем тут 4 байта? Борландовские свойства не хранят в себе лишние 4 байта на указатель. И даже если бы хранили, на размер exe-шника это повлияло бы очень и очень слабо, если бы повлияло вообще.
Цитата: Green
Standard Template Library - библиотека построенная на шаблонах, а "свойства" не дружат с шаблонами. Отсюда делаю предположение, что "свойства" могут свести на нет использование STL, в т.ч. сильно затруднит использование.
Не вижу взаимосвязи. Например:
Код:
class A {
// ...
std::property<....> P;
// ...
}
std::vector<A> As;
// ...
std::property<....> P;
// ...
}
std::vector<A> As;
Как в данном случае property помешает vector'у?
Цитата: Green
Более того, "свойства" не дружат с классами. Другими словами "свойство" не может быть проксёй для класса или структуры. Только для простых типов (int, char, double).
Как это относиться к тому что свойства сведут на нет stl?
Цитата: Green
Мой опыт говорит, что задач, где был бы уместен такой подход, нет.
Логика говорит, что задач, где нельзя обойтись без свойств , тоже нет.
Здравый смысл говорит, что использование "свойств" может привнести ошибки в код.
Вывод: "свойства" лучше не использовать.
Логика говорит, что задач, где нельзя обойтись без свойств , тоже нет.
Здравый смысл говорит, что использование "свойств" может привнести ошибки в код.
Вывод: "свойства" лучше не использовать.
Если ты не решал каких-то задач, где был бы уместен такой подход, то это не значит, что таких задач не существует.:)
Цитата: Nixus
Как в данном случае property помешает vector'у?
Я не знаю реализации std:: property, т.к. это несуществующий (в stl) класс.
Поэтому не могу сказать, как несуществующий класс может помешать вектору.
Цитата: Nixus
Как это относиться к тому что свойства сведут на нет stl?
Это отдельное замечание, не имеющее отношение к STL.
Цитата: Nixus
Если ты не решал каких-то задач, где был бы уместен такой подход, то это не значит, что таких задач не существует.:)
Ты апеллируешь к опыту, при этом совершенно забываешь про логику.
Я не просто сказал, что я с такими задачами не сталкивался, но и четко показал, почему не стоит решать задачи таким способом.
Цитата: kot_
да ну?
т.е. чем больше по 4 байта тем лучше.
т.е. чем больше по 4 байта тем лучше.
... в клаузе есть "на 4 байта больше".
Цитата: Nixus
При чем тут 4 байта? Борландовские свойства не хранят в себе лишние 4 байта на указатель. И даже если бы хранили, на размер exe-шника это повлияло бы очень и очень слабо, если бы повлияло вообще.
он имеет ввиду клаузу, а вообщем поддерживаю...
Цитата: Green
Я не знаю реализации std:: property, т.к. это несуществующий (в stl) класс.
Поэтому не могу сказать, как несуществующий класс может помешать вектору.
Поэтому не могу сказать, как несуществующий класс может помешать вектору.
Т.е. ты не знаешь как свойства сведут на нет stl? :)
Цитата: Green
Я говорил не только об имени метода. Видимо остального ты не заметил или не понял.
Как раз на имя метода ты делал упор.
Цитата: Green
Два моих основных аргумента:
1) такой подход (использование "свойств") ИЗЛИШНЕ запутывает код;
Код:
class TMyClass : public TForm
{
...
private:
int FVal;
void __fastcall SetVal(int value);
int __fastcall GetVal();
public:
__property int Val = { read=GetVal, write=SetVal };
};
void __fastcall TMyClass::SetVal(int value){}
int __fastcall TMyClass::GetVal(){}
{
...
private:
int FVal;
void __fastcall SetVal(int value);
int __fastcall GetVal();
public:
__property int Val = { read=GetVal, write=SetVal };
};
void __fastcall TMyClass::SetVal(int value){}
int __fastcall TMyClass::GetVal(){}
Что тебе здесь не понятно? Как тут запутаться для меня загадка.
строчка:
__property int Val = { read=GetVal, write=SetVal };
Это расширение языка и то, что ты не понимаешь данной строчки это твои проблемы.
Цитата: Green
2) добавляет потенциальных багов.
Есть чем оспорить?
оспорить, что? Приведи пример класса со св-вами где можно словить баг
Цитата: Green
Твоих аргументов так и не видно. Пока вижу только хамство и пустословие,- яркий признак, что сказать то нечего.
Это положение на то и дано, чтоб вычищать мусор наносимый неадекватными личностями.
ну вот апять абзывается:)
Цитата: GIZMO
Как раз на имя метода ты делал упор.
Цитата: GIZMO
Нет, ты сделал на этом акцент,
У тебя какие-то проблемы с упорами и акцентами... :D
Если ты объяснишь мне доходчиво, где тебе мерещутся упоры, я постараюсь тебе объяснить причины твоей предвзятости.
Цитата: GIZMO
Это расширение языка и то, что ты не понимаешь данной строчки это твои проблемы.
Слышит звон, но не знает, где он.
А при чем тут расширение языка? Мы говорим об этом расширении?
Ты бы перечитал ветку, прежде, чем влезать в спор. Так что это твои проблемы, невнимательность и излишняя горячность.
Цитата: GIZMO
оспорить, что? Приведи пример класса со св-вами где можно словить баг
Гы... пример класса
Да любой:
Код:
class A
{
public property<...> val;
};
{
public property<...> val;
};
но вот где при использовании такого класса ты словишь баг, думаю, догадаешься сам, если считаешь себя специалистом. Тем более, что я об этом уже говорил. Так что достаточно будет уметь читать и думать.
Я что-то уже несколько страниц прошу привести пример удобства "свойств" и задач, где уместен такой подход. Пока что-то тихо. Нет удобств? Нет задач?
"Тогда зачем платить больше?"
(для тех, кто в танке: упор выделен жирным)
Цитата: Nixus
Монструозные они вовсе не от свойств или inline-функций. :)
ну я не сказал что это едиственная и основная причина.
Цитата: Nixus
Т.е. ты не знаешь как свойства сведут на нет stl? :)
А ты знаешь задачи, где был бы уместен подход со свойствами? :)
Я делаю обоснованное предположение. Довольно сложно перебрать все возможные варианты реализации STL и реализации "свойств".
Ты представляешь хотя бы примерно, какого огромного размера будет класс свойств, чтоб он был хоть как-то приемлемо рабочим?
Сколько там будет переопределено операторов, вспомогательных функций?
А если учесть, что "свойств" будет несколько (только для записи, для чтения).
Я могу показать примеры, где "свойства" сведут на нет текущие реализации STL.
А переработка STL под такие случаи значительно (на порядки) увеличит размер библиотеки и усложнит процесс её использования.
Кроме того можно предположить, что "свойства" могут нарушить принципы ООП, например, инкапсуляцию. Но это надо подробнее продумать.
Цитата: Nixus]
[QUOTE=Green
[QUOTE=Green
Более того, "свойства" не дружат с классами. Другими словами "свойство" не может быть проксёй для класса или структуры. Только для простых типов (int, char, double).
Как это относиться к тому что свойства сведут на нет stl?
[/QUOTE]
Кстати, по этому поводу изменил свое мнение, точнее, в раздумии я.
STL не налагает жестких ограничений на использование типов (в общем случае должен быть дефолтовый конструктор, конструктор копирования, операторы сравнения). А "свойства" накладывают жесткие ограничения на использование только простых типов.
Получается, что введя "свойства" в STL мы ограничиваем принцип использования с её любыми типами. Кроме того, довольно сложно юзер-френдли контролировать правильность использования типов.
Цитата: Green
А при чем тут расширение языка? Мы говорим об этом расширении?
вообще-то несколько человек имело ввиду именно св-ва "борландовские" (так что выходит я не один не внимательный?), а к тому, что навертел топикстартер через шаблон, ну ... действительно мне прочитать тяжело. Я за то, чтоб пользоваться св-ми от производителя компиллятора, а не за самодеятельность.
Цитата: GIZMO
вообще-то несколько человек имело ввиду именно св-ва "борландовские" (так что выходит я не один не внимательный?),
а к тому, что навертел топикстартер через шаблон, ну ... действительно мне прочитать тяжело. Я за то, чтоб пользоваться св-ми от производителя компиллятора, а не за самодеятельность.
Кто ещё невнимательный?
До твоего первого поста, который на первой странице, борландовское расширение вообще не упоминалось.
Совет: прежде чем влезать в спор, разберись о чем он.
Nixus, вот смотри, ты сам вырыл себе яму:
Цитата: Nixus
Не вижу взаимосвязи. Например:
Как в данном случае property помешает vector'у?
Код:
class A {
// ...
std::property<....> P;
// ...
}
std::vector<A> As;
// ...
std::property<....> P;
// ...
}
std::vector<A> As;
Как в данном случае property помешает vector'у?
В этом коде есть серьезный баг, который компилятором совсем не отлавоивается, а схлопочешь ты его где-то при выполнении программы.
Подсказка: баг заключается в отсутсвии у класса A некоторых очень в данном случае важных методов.
Сможешь сам их определить?
Посмотрим, на сколько просто выявлять ошибки в коде со "свойствами".
Цитата: GIZMO
вообще-то несколько человек имело ввиду именно св-ва "борландовские" (так что выходит я не один не внимательный?), а к тому, что навертел топикстартер через шаблон, ну ... действительно мне прочитать тяжело. Я за то, чтоб пользоваться св-ми от производителя компиллятора, а не за самодеятельность.
вобщето большинство обсуждало конкретное решение топикстартера. Хотя расширение языка тоже я например лично не считаю удачным решением.
Цитата: Green
Nixus, вот смотри, ты сам вырыл себе яму:
В этом коде есть серьезный баг, который компилятором совсем не отлавоивается, а схлопочешь ты его где-то при выполнении программы.
Подсказка: баг заключается в отсутсвии у класса A некоторых очень в данном случае важных методов.
Сможешь сам их определить?
Посмотрим, на сколько просто выявлять ошибки в коде со "свойствами".
В этом коде есть серьезный баг, который компилятором совсем не отлавоивается, а схлопочешь ты его где-то при выполнении программы.
Подсказка: баг заключается в отсутсвии у класса A некоторых очень в данном случае важных методов.
Сможешь сам их определить?
Посмотрим, на сколько просто выявлять ошибки в коде со "свойствами".
При чем тут ошибки возможные? Объясни как свойства сведут на нет stl.
Цитата: kot_
ну я не сказал что это едиственная и основная причина.
Это вообще не причина их монструозности.
Цитата: Nixus
При чем тут ошибки возможные? Объясни как свойства сведут на нет stl.
Вот этими ошибками, не возможными, а вполне реальными, и сведут.
Когда ты выявишь эти ошибки, тогда, наверное, и поймешь.
Цитата: Green
Вот этими ошибками, не возможными, а вполне реальными, и сведут.
Когда ты выявишь эти ошибки, тогда, наверное, и поймешь.
Когда ты выявишь эти ошибки, тогда, наверное, и поймешь.
Т.е. пример сведения на нет stl с пояснением ты привести не можешь? :)
Цитата: Nixus
Т.е. пример сведения на нет stl с пояснением ты привести не можешь? :)
Какой STL? Абстрактный или существующий?
Как сводится на нет существующий STL, ты показал сам. Только сам своего бага не видишь.
Могу ещё добавить, что кроме того сводится на нет практически весь <algorithm>. И многие другие места, где есть шаблонные функции и методы, где используется передача параметров по ссылке.
А на счет абстрактного STL, можно теоретизировать сколь угодно долго, но при этом он будет увеличиваться в геометрических размерах, а его надежность будет пропорционально падать.
Потому, что практически во всех методах и функциях STL придется делать частную специализацию входного параметра для класса property_ или даже для нескольких классов, если мы захотим иметь разные property_ (read_only_property_ etc.), а так же для всех вариантов сочетания (см. комбинаторный взрыв).
Возьми самую элементарную функцию std::min. И поэксперементируй. :)
И это только цветочки.
Так показать примеры, где уместны свойства ты не можешь? :)
Что-то вы в упор не видите моих просьб что-то показать или доказать. Твои измышления вообще ничем не подкреплены, при этом от меня ты требуешь доказательств, кроме около-философских изречений.
Покажи, где свойства удобны, уместны, безглючны и т.п.
Докажи обратное и с STL, если ты так уверен. Что введение в неё свойств ничего не изменит в остальной её части, а так же не повлияет на сложность и безглючность использования этой библиотеки.
2Green
[offtop]
твой аватар понравился моей дочке - сказала "прыгающая грушенька" :)
[/offtop]
[offtop]
твой аватар понравился моей дочке - сказала "прыгающая грушенька" :)
[/offtop]
Каким образом свойства сводят на нет stl абсолютно не вижу и ты показать не можешь. Вопрос, значит, закрыт.
Цитата: Nixus
Каким образом свойства сводят на нет stl абсолютно не вижу и ты показать не можешь. Вопрос, значит, закрыт.
Вот ведь хитрец... Услышал неудобные вопросы и в кусты. :)
Хороша позиция: а ты мне покажи! ой не вижу!
Я тебе показал и рассказал, чем использование "свойств" сводит на нет существующий STL. Ты, видимо, просто не можешь, не хочешь или не готов этого понять.
Ты смог ответить хоть на один мой вопрос? Показать хоть один приемлемый пример?
Ты обнаружил ошибку в своем коде?
Ты поэксперементировал с std::min? А с др. методами <algorithm> и пр. шаблонными методами?
Что касается "абстрактного" STL. Ты вник, какой сложности будет класс такого свойства?
Сколько операторов придется перегрузить?
Сколько классов "свойств" тебе надо будет создать?
Сколько с учетом этого других классов и методов STL придется специализировать под твой класс "свойства"?
Как ты собираешься осуществлять проверку того, что "свойства" можно создавать только для простых типов?
Как ты собираешься проверять корректность использования "свойств" пользователями STL? (ищи баг в cвоем примере)
"Свойства" и поля метода - это не одно и тоже, а выглядят в коде одинаково.
Как ты собираешься избавляться от такой путаницы?
Вот это что:
Код:
s.Value;
"свойство" или поле класса?
Можно для него вызывать sizeof или нет?
Можно его передать в шаблонную функцию или нет?
Анализ вышеперечисленных вопросов и дают мне повод (очень) сомневаться в возможности и целесообразности существование "свойств" в STL.
Вот когда ты сможешь ответить на эти вопросы, а ещё и покажешь мне примеры, где "свойства" удобны и уместны, тогда и есть смысл продолжать общение.
А пока я вижу слабое понимание с твоей стороны сути и сложности обсуждаемого.
P.S. И ещё очень важный вопрос:
А зачем добавлять "свойства" (ущербный, малоприменимый, запутывающий, багоопасный подход) в STL ?
Цитата: kot_
2Green
[offtop]
твой аватар понравился моей дочке - сказала "прыгающая грушенька" :)
[/offtop]
[offtop]
твой аватар понравился моей дочке - сказала "прыгающая грушенька" :)
[/offtop]
Передавай привет дочке от прыгающей груши. :)
Цитата: Green
Передавай привет дочке от прыгающей груши. :)
абизательно :)
к вышесказанному хочу добавить - как будут относится свойства к наследованию? По каким правилам оно будет происходить? В ВСВ это решается просто - там просто нет множественного наследования.
Господа, just FYI:
http://www.javalobby.org/java/forums/t90756.html
Может, кому то будет любопытно. Обсуждение свойств в (будущей) Java 1.7.
http://www.javalobby.org/java/forums/t90756.html
Может, кому то будет любопытно. Обсуждение свойств в (будущей) Java 1.7.