// Описание свойства только для записи
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)
{
}
};
Цитата: aks
Ну на сколько я понял из дискуссии, народ в первую очередь обсуждал реализации того, что принято называть "свойством" приведенные здесь.
Еще раз перечитай на что отвечал Green, когда я с ним не согласился, потом делись своими откровениями. Там шел разговор о добавлении свойств в stl вообще, а не той реализации которую привел автор темы.
Цитата: aks
ну да, немножко покритиковали расширения языка в билдере, но на основное обсуждение (так и хочется назватить демагогию) это не особо влияло.
При чем тут билдер вообще? Я его косался только в диалоге с kot_ и к дискусии с Green'ом это не имеет никакого отношения.
Цитата: aks
Ты предлагаешь обсуждать с точки зрения свойст в общем виде. Мне интресно что это такое. С твоим определением, я не согласен - оно слишком общее и под него можно подвести кучу всего что не является свойством в том виде как его привыкли понимать из других языков (где оно есть).
Я специально даю такое определение. Тут утверждалось что абсолютно любая реализация свойств вызовет переделку всей stl. Так пусть приведут хоть один пример (ведь у них такой простор для творчества) что vector придется переписать. Но даже с таким определением никто ничего не привел.
Цитата: aks
А если ничего кроме абстракых несуществующих вещей нет - может хватит это обсуждать? )
Дык, иницатор спора давно прекратил и я бы вместе с ним, но некоторый товарищи продалжают меня по очереди в чем-то убеждать. Ты вот тоже зачем-то продолжаешь эту тягомотину, пытаясь что-то мне показать.
=))))))))))
Пожалуй, один из самый бессмысленных споров на форуме из тех что я видел.
Предположим, в простом случае. Есть свойства, кто-то их создал.
И зачем они нужны?
(аргумент "они сокращают время на набор кода" я, естественно, проигнорирую. Генерация набора методов get/set для полей класса, это несколько шоткатов, которые должны быть на кончиках пальцев).
Я не рассматриваю вообще глючность свойств. Я не рассматриваю сложность их реализации.
Просто - зачем они нужны?
Предположим, в простом случае. Есть свойства, кто-то их создал.
И зачем они нужны?
(аргумент "они сокращают время на набор кода" я, естественно, проигнорирую. Генерация набора методов get/set для полей класса, это несколько шоткатов, которые должны быть на кончиках пальцев).
Я не рассматриваю вообще глючность свойств. Я не рассматриваю сложность их реализации.
Просто - зачем они нужны?
Цитата: Zorkus
(аргумент "они сокращают время на набор кода" я, естественно, проигнорирую. Генерация набора методов get/set для полей класса, это несколько шоткатов, которые должны быть на кончиках пальцев).
Я не рассматриваю вообще глючность свойств. Я не рассматриваю сложность их реализации.
Просто - зачем они нужны?
Я не рассматриваю вообще глючность свойств. Я не рассматриваю сложность их реализации.
Просто - зачем они нужны?
Код пишется человеком и для человека.
Посмотрел на интерфейс класса - и видишь, вот "действия" - методы классов. А вот различные "параметры" - свойства.
get/set - это слишком примитивно. Да компилятор разворачивает определение свойства в такие методы, но главная цель - это логическая связь между этими методами, их единство.
А еще свойства помогают при отражении.
Цитата: hardcase
Код пишется человеком и для человека.
Посмотрел на интерфейс класса - и видишь, вот "действия" - методы классов. А вот различные "параметры" - свойства.
get/set - это слишком примитивно. Да компилятор разворачивает определение свойства в такие методы, но главная цель - это логическая связь между этими методами, их единство.
А еще свойства помогают при отражении.
Посмотрел на интерфейс класса - и видишь, вот "действия" - методы классов. А вот различные "параметры" - свойства.
get/set - это слишком примитивно. Да компилятор разворачивает определение свойства в такие методы, но главная цель - это логическая связь между этими методами, их единство.
А еще свойства помогают при отражении.
Лично для меня в этом нету удобства. Я вижу в интерфейсе методы (среди которых выделяю, если хочу, get-set), и поля.
Впрочем, это конечно лично для меня удобство.
А что с отражением? В шарпе они играют в нем особенную роль?
Цитата: Nixus
Лично от вас я пока тоже ничего внятного не услышал, кроме возможных причин которые может что-то вызовут.
Были приведены не возможные, а вполне конкретные причины.
Цитата: Nixus
Давай по порядку, что случиться с stl если туда введут свойства. Какие преимущества из-за этого потеряются? Перечисли.
Их неоднократно перечисляли, в т.ч. и ты сам.
Не вижу смысла повторяться. (впрочем, повторился ниже)
Цитата: Nixus
Может не стоит меня в чем-то убеждать, не разобравщись о чем я хочу сказать?
Ну так пора уже сказать, а не хотеть. :)
Цитата: Nixus
Что случится с тем же std::vector? Ответ - ничего не случится, он даже не изменится.
С вектором не случиться (возможно), а вот с тем же min случится. И это тебе уже тоже говорилось и даже предлагалось провести эксперименты, но отрицать проще, чем пробовать. Не так ли?
Цитата: Nixus
Как я устал повторять. Были приведены аргументы глючности свойств приведенных автором темы. Как это относится к свойствам в общем виде - не вижу. Покажи.
А как я устал повторять, что были приведены аргументы глючности свойств в общем виде.
"Знаешь что такое решение задачи в общем виде? Вот тут и оно: не делая акцент на особености конкретных реализации."
Несогласен, попробуй создать свойства лишенные перечисленных недостатков.
Цитата: Nixus
Я не виноват, что у некоторых участников этого форума мое мнение вызывает острое отторжение и они начинают со мной спорить, при чем самое интересное, что всегда одни и те же лица.
Попытайся быть честным сам с собой, ты до сих пор не высказал своего мнения, а задавал вопросы в вызывающей форме: "Как изменят? А, ну как? А ну покажи!"
Теперь о чем собственно спор.
"Свойства" - вызов нестатического метода (оперирующего нестатическими данными этого объекта) через агрегируемый прокси-объект, создающее видимость (аналогичный синтаксис) простого обращения к полю объекта.
Т.е. другими словами, "свойства" это когда мы пишем obj.val, а это "разворачивается" в obj.func().
Так вот
1. При любой реализации "свойств", они будут багоопасны даже не по своей реализации, а по своему применению.
2. При любой реализации "свойств", они будут работать только с простыми типами.
3. При любой реализации будут ограниченно работать с существующей STL.
4. При любой реализации потребуется расширить существующие интерфейсы STL.
5. При любой реализации "свойства" не вписываются в концепцию STL.
6. При любой реализации свойства нельзя будет использовать там, где можно будет использовать обычное обращение к полю класса, и это вызовет путаницу.
7. При любой реализации "свойства" ставят под удар принцип "инкапсуляции".
Вывод: даже если такую библиотеку-монстр можно будет реализовать, то пользоваться ей надо будет с такой осторожностью, а ошибки находить на столько сложно, что это сведет на нет все преимущества STL.
Как я понял ход твоих мыслей.
Если глючные свойства будут включены в STL, то это никак не отразиться на глючности остальной STL
Но ведь свойства станут частью STL, а известно, если в бочку меда добавить ложку дерьма, то получим не "бочку меда с ложкой дерьма", а "бочку дерьма".
Кроме того "остальная часть" STL разрастется и это тоже скажется на качестве библиотеки вцелом.
Цитата: Zorkus
Лично для меня в этом нету удобства. Я вижу в интерфейсе методы (среди которых выделяю, если хочу, get-set), и поля.
Поля на сколько я знаю всегда делают приватными.
Цитата: Zorkus
А что с отражением? В шарпе они играют в нем особенную роль?
В общем виде, .NET позволяет отражать методы и свойства раздельно. Т.е. существует два разных метода у класса System.Type: GetProperties и GetMethods (ну и для полей - GetFields).
Подход со свойствами удобнее, когда осуществляется привязка данных (наборов некоторых объектов) к интерфейсу (контрол для отображения набора на форме или веб-странице): мы указываем именно имя свойства, которое привязываем. Применение свойств также обосновано, когда мы имеем дело с XML: тег соответствует классу, атрибуты - свойствам.
Цитата: hardcase
Поля на сколько я знаю всегда делают приватными.
Сорри, оговорился, имел в виду -- просматриваю структуру класса (в какой-то панели IDE).
[QUOTE=hardcase]А еще свойства помогают при отражении.[/QUOTE]Также, свойства помогают лучше (быстрее) понять назначение и смысловую нагрузку интерфейса (то есть "абстрактного класса", определяющего способ доступа к данным) при его объявлении (свойства или "свойства" должно быть можно полиморфить, кстате), закрытые либо защищённые свойства позволяют вводить, например, отложенное создание объектов, либо отслеживание изменения значения какого-либо поля, "без потерь" (то есть, изменить придётся лишь декларацию: поле -> свойство).
Но, по большому счёту, свойства - как спа-салон: реальной пользы мало, но приятно безумно.
Но, по большому счёту, свойства - как спа-салон: реальной пользы мало, но приятно безумно.
Цитата: Green
Были приведены не возможные, а вполне конкретные причины.
Эта фраза относилась лично nikitozz'у. Вообще странно что ты отвечаешь на сообщение адресованное не тебе.
Цитата: Green
Ну так пора уже сказать, а не хотеть. :)
Свойства не "сведут на нет" и не "сломают" stl.
Цитата: Green
С вектором не случиться (возможно),
С ним вообще ничего не случиться.
Цитата: Green
а вот с тем же min случится. И это тебе уже тоже говорилось и даже предлагалось провести эксперименты, но отрицать проще, чем пробовать. Не так ли?
И с min не "сломается". Конечно, внешнии по отношению к stl "свойства" не будут работать с min. Ведь stl в данном случае ничего не знает о свойствах, однако если они будут частью stl min будет прекрасно о них известно. Т.е. min будет работать со свойствами. Мы же говорим об этом.
Цитата: Green
А как я устал повторять, что были приведены аргументы глючности свойств в общем виде.
Единственный подкрепленный кодом аргумент глючности свойств в общем виде был аргумент про sizeof(). Однако какой смысл брать у своства размер? Это все равно что применять sizeof к string или iostream. Ты же не будешь этого делать? Остальные аргументы были про глючность свойств приведенных автором в текущей stl.
Цитата: Green
"Знаешь что такое решение задачи в общем виде? Вот тут и оно: не делая акцент на особености конкретных реализации."
Несогласен, попробуй создать свойства лишенные перечисленных недостатков.
Несогласен, попробуй создать свойства лишенные перечисленных недостатков.
Т.е. в общем виде доказетльств предоставить ты не можешь кроме спорного аргумента про sizeof?
Цитата: Green
Попытайся быть честным сам с собой, ты до сих пор не высказал своего мнения, а задавал вопросы в вызывающей форме: "Как изменят? А, ну как? А ну покажи!"
Попытайся буть честным с собой, ты до сих пор не покзал почему min сведется на нет если в stl включат "свойства". Ты доказываешь сведение на нет предположениями не подкрепленными кодом.
Цитата: Green
Теперь о чем собственно спор.
"Свойства" - вызов нестатического метода (оперирующего нестатическими данными этого объекта) через агрегируемый прокси-объект, создающее видимость (аналогичный синтаксис) простого обращения к полю объекта.
Т.е. другими словами, "свойства" это когда мы пишем obj.val, а это "разворачивается" в obj.func().
"Свойства" - вызов нестатического метода (оперирующего нестатическими данными этого объекта) через агрегируемый прокси-объект, создающее видимость (аналогичный синтаксис) простого обращения к полю объекта.
Т.е. другими словами, "свойства" это когда мы пишем obj.val, а это "разворачивается" в obj.func().
Сразу возникает вопрос почему obj.func(), а не setter::func(obj), например?
Цитата: Green
Так вот
1. При любой реализации "свойств", они будут багоопасны даже не по своей реализации, а по своему применению.
1. При любой реализации "свойств", они будут багоопасны даже не по своей реализации, а по своему применению.
Багоопасны почти все инструменты stl.
Цитата: Green
2. При любой реализации "свойств", они будут работать только с простыми типами.
Не совсем понимаю о чем ты. Поясни.
Цитата: Green
3. При любой реализации будут ограниченно работать с существующей STL.
А это тут при чем? Разговор совсем не об этом.
Цитата: Green
4. При любой реализации потребуется расширить существующие интерфейсы STL.
Ну и что с того?
Цитата: Green
5. При любой реализации "свойства" не вписываются в концепцию STL.
Да ну, в чем-же?
Цитата: Green
6. При любой реализации свойства нельзя будет использовать там, где можно будет использовать обычное обращение к полю класса, и это вызовет путаницу..
Какую путаницу? Приведи пример.
Код:
obj.s = "123";
s может быть как stirng, так и char*, так и void*. Не долго и запутаться. :)
Цитата: Green
7. При любой реализации "свойства" ставят под удар принцип "инкапсуляции".
Не в коем разе. Если для тебя инкапсуляция это только прятанье пременных в private/protected и работа с ними через методы, то тогда конечно.
Цитата: Green
Вывод: даже если такую библиотеку-монстр можно будет реализовать, то пользоваться ей надо будет с такой осторожностью, а ошибки находить на столько сложно, что это сведет на нет все преимущества STL.
Вот, например, нади ошибку здесь:
string s = "Hello" + 'o';
Цитата: Green
Как я понял ход твоих мыслей.
Если глючные свойства будут включены в STL, то это никак не отразиться на глючности остальной STL
Но ведь свойства станут частью STL, а известно, если в бочку меда добавить ложку дерьма, то получим не "бочку меда с ложкой дерьма", а "бочку дерьма".
Если глючные свойства будут включены в STL, то это никак не отразиться на глючности остальной STL
Но ведь свойства станут частью STL, а известно, если в бочку меда добавить ложку дерьма, то получим не "бочку меда с ложкой дерьма", а "бочку дерьма".
Сильная метафора, однако stl это уже мед с примесью дермеца.
Цитата: Green
Кроме того "остальная часть" STL разрастется и это тоже скажется на качестве библиотеки вцелом.
Да ну. Как размер библиотеки сказывается на качестве? Размер boost'а видел?
Цитата: Nixus
Свойства не "сведут на нет" и не "сломают" stl.
Что ты подразумеваешь под "сведут на нет" и "сломают" stl ?
Цитата: Nixus
С ним вообще ничего не случиться.
Докажи в общем случае.
Цитата: Nixus
И с min не "сломается". Конечно, внешнии по отношению к stl "свойства" не будут работать с min. Ведь stl в данном случае ничего не знает о свойствах,
Так все же min придется перерабатывать, как и остальную STL? Просто "добавить" свойства не получится?
Что значит "не знает о свойствах"?
vector тоже ничего не знает о string и тем более о "внешних классах", однако работает с ними.
Цитата: Nixus
однако если они будут частью stl min будет прекрасно о них известно. Т.е. min будет работать со свойствами.
Что значит "прекрасно будет о них известно"?
Цитата: Nixus
Единственный подкрепленный кодом аргумент глючности свойств в общем виде был аргумент про sizeof().
Это единственный аргумент который ты понял. А вот аргумент про параметр шаблона функции, например min, ты не понял.
Это касается всех ф-ций, не только из stl.
Цитата: Nixus
Однако какой смысл брать у своства размер? Это все равно что применять sizeof к string или iostream. Ты же не будешь этого делать?
Скажи, пожалуйста, я могу сделать так?
Код:
sizeof obj.val;
Почему не могу, если это просто поле класса?
Как ты разграничишь это между полями и свойствами?
Цитата: Nixus
Остальные аргументы были про глючность свойств приведенных автором в текущей stl.
Докажи. Я утверждаю обратное.
Приведи свои аргументы обраьного.
Цитата: Nixus
Попытайся буть честным с собой, ты до сих пор не покзал почему min сведется на нет если в stl включат "свойства".
Где я утверждал, что "min сведется на нет" ?
Цитата: Nixus
Ты доказываешь сведение на нет предположениями не подкрепленными кодом.
Там где необходимо код приводится, общие случаи аргументируются ограничениями языка.
Где доказательства твоих предположений? Где код?
Цитата: Nixus
Сразу возникает вопрос почему obj.func(), а не setter::func(obj), например?
Потому, что мы обсуждаем "свойства" именно с такой общепринятой трактовкой.
Имеешь другую трактовку, обсуждай её в отдельной теме.
Цитата: Nixus
Багоопасны почти все инструменты stl.
Докажи.
Цитата: Nixus
Не совсем понимаю о чем ты. Поясни.
Невозможно создать свойство для классов и пр. "составных" объектов.
Только для простых типов - int, float, char и т.п., указатели и массивы.
Цитата: Nixus
А это тут при чем? Разговор совсем не об этом.
А о чем?
Цитата: Nixus
Ну и что с того?
Да ну, в чем-же?
Ответы дан в теме неоднократно выше.
Цитата: Nixus
Какую путаницу? Приведи пример.
Ответ дан неоднократно в т.ч. в этом посте, см. выше.
Цитата: Nixus
Не в коем разе. Если для тебя инкапсуляция это только прятанье пременных в private/protected и работа с ними через методы, то тогда конечно.
Докажи, что "не в коем разе". Именно "не в коем".
Цитата: Nixus
Код:
obj.s = "123";
Вот, например, нади ошибку здесь:
string s = "Hello" + 'o';
Эта ошибка не имеет никакого отношения к stl.
Цитата: Nixus
Сильная метафора, однако stl это уже мед с примесью дермеца.
Добавим ещё? Это пойдет STL на пользу?
Цитата: Nixus
Да ну. Как размер библиотеки сказывается на качестве? Размер boost'а видел?
Если stl - "мед с при с примесью дермеца", то boost - сточная канава. И размер в т.ч. имеет значение.
А ты размер MFC видел?
Цитата: Green
Что ты подразумеваешь под "сведут на нет" и "сломают" stl ?
То, что невозможно будет пользоваться библиотекой. А ты?
Цитата: Green
Докажи в общем случае.
Покажи обратное. Как я тебе докужу что не существует, то что не существует? Можно доказать существование чего-то показав это, но не несуществование чего-то показав что-то.
Цитата: Green
Так все же min придется перерабатывать, как и остальную STL? Просто "добавить" свойства не получится?
Что значит "не знает о свойствах"?
vector тоже ничего не знает о string и тем более о "внешних классах", однако работает с ними.
Что значит "не знает о свойствах"?
vector тоже ничего не знает о string и тем более о "внешних классах", однако работает с ними.
А кто сказал, что они буду добавлены просто как дополнительный класс без изменения других компонентов?
Цитата: Green
Что значит "прекрасно будет о них известно"?
Значит будут внесены дополнительные декаларации, если это потребуется.
Цитата: Green
Это единственный аргумент который ты понял. А вот аргумент про параметр шаблона функции, например min, ты не понял.
Это касается всех ф-ций, не только из stl.
Это касается всех ф-ций, не только из stl.
Я понял все твои аргументы. Я не вижу как это доказывает что stl "сведется на нет".
Цитата: Green
Скажи, пожалуйста, я могу сделать так?
Почему не могу, если это просто поле класса?
Код:
sizeof obj.val;
Почему не могу, если это просто поле класса?
Можешь. А если val это string или iostream ты будешь так делать? Зачем?
Цитата: Green
Как ты разграничишь это между полями и свойствами?
Никак, а зачем мне это разграничивать, если согласно принципу инкапсуляции у меня есть только интерфейс и только через него я должен работать с объектом?
Цитата: Green
А так:
Код:
template<T>
void max(T,T);
max(obj.val, 6);
void max(T,T);
max(obj.val, 6);
В данном случае придется использовать max<int>(obj.val, 6). Только где тут stl с реализованными свойствами?
Цитата: Green
А вот так:
Код:
void func(int&);
func(obj.val);
func(obj.val);
Ну как быть в данном случае ты и сам знаешь. operator T& () никто не отменял. :)
Цитата: Green
Докажи. Я утверждаю обратное.
Приведи свои аргументы обраьного.
Приведи свои аргументы обраьного.
Ну ты же не знаешь как изменится min после того как туда добавят свойства? Т.е. все что приведено - по поводу текущей всерсии stl, остальное - это софистика.
Цитата: Green
Где я утверждал, что "min сведется на нет" ?
Подумаешь, описался. Перефразируем:
Попытайся быть честным с собой, ты до сих пор не покзал почему stl сведется на нет если в stl включат "свойства".
Ты показал проблемы в использовании свойств автора темы и несовместимость их с частью библиотеки stl.
Цитата: Green
Там где необходимо код приводится, общие случаи аргументируются ограничениями языка.
Там где код придумал он приводиться, а тем где не придумал - не приводиться. :)
Цитата: Green
Где доказательства твоих предположений? Где код?
Внимание, цитата:
Цитата: Nixus
Не вижу как свойства сведут на нет stl.
Где я что-либо предполагаю или доказываю?
Цитата: Green
Потому, что мы обсуждаем "свойства" именно с такой общепринятой трактовкой.
Имеешь другую трактовку, обсуждай её в отдельной теме.
Имеешь другую трактовку, обсуждай её в отдельной теме.
Опять эта общепринятая трактовка! :D
Где в теме говориться об этой "общепринятой трактовке"?
Почему ты считаешь что свойства обязаны привязыватся к нестатическим методам? Что мешает свойствам в общем виде привязыватся к статическим?
Цитата: Green
Невозможно создать свойство для классов и пр. "составных" объектов.
Только для простых типов - int, float, char и т.п., указатели и массивы.
Только для простых типов - int, float, char и т.п., указатели и массивы.
Возможно создать свойство, но не полуится получить доступ к членам этой структуры через оператор . примененный к объекту свойства.
Но что случится с stl в данном случае? Это вообще никак не доказывает, что stl "сведется на нет" или "сломается" после введения в нее "свойств".
Цитата: Green
А о чем?
Я где-то доказываю обратное? Как это доказывает то, что stl сломается?
Цитата: Green
Ответы дан в теме неоднократно выше.
Стандартная отмазка.
Как доказывает необходимость изменить stl, то что stl "сломается"? Никак!
Да и огласите "концепцию stl", а то эту свещенную корову все доят по поводу и без повода.
Цитата: Green
Ответ дан неоднократно в т.ч. в этом посте, см. выше.
Ну если ты не видешь принципиальной разницы между полем и свойством, то конечно можно запутаться.
Цитата: Green
Докажи, что "не в коем разе". Именно "не в коем".
Цитата:
Инкапсуля́ция — свойство языка программирования, позволяющее объединить данные и код в объект и скрыть реализацию объекта от пользователя. При этом пользователю предоставляется только спецификация (интерфейс) объекта. Пользователь может взаимодействовать с объектом только через этот интерфейс.
Ну и как свойства нарушают инкапсуляцию? Ответ: Никак.
Цитата: Green
Эта ошибка не имеет никакого отношения к stl.
Так же как и многое приведенное тобой. :)
Цитата: Green
Добавим ещё? Это пойдет STL на пользу?
Кто говорит про пользу?
Цитата: Green
Если stl - "мед с при с примесью дермеца", то boost - сточная канава. И размер в т.ч. имеет значение.
Т.е. boost ты не используешь и другим не советуешь?
Цитата: Green
А ты размер MFC видел?
MFC это не библиотека шаблонов.
Цитата: Nixus
То, что невозможно будет пользоваться библиотекой. А ты?
Что подразумеваю я, я уже говорил.
А что значит, "невозможно будет пользоваться"? Почему?
Цитата: Nixus
Покажи обратное. Как я тебе докужу что не существует, то что не существует? Можно доказать существование чего-то показав это, но не несуществование чего-то показав что-то.
Я сказал не "показать", а "доказать".
Ты же утверждаешь, что с вектором "вообще ничего не случится", а вот доказать этого не можешь.
Сл-но голословное утверждение.
Цитата: Nixus
Можешь. А если val это string или iostream ты будешь так делать? Зачем?
Возможно и буду. И получу размер полей этого типа. И путанницы тут не будет.
А вот что я получу взяв sizeof val.obj не понятно.
Особенно это скажется на рефакторинге.
Цитата: Nixus
В данном случае придется использовать max<int>(obj.val, 6).
Ты всегда пишешь func<int>(arg1, arg2) ? :)
И даже если аргументов больше двух?
Цитата: Nixus
Только где тут stl с реализованными свойствами?
Вот видишь, ты уже путаешься. obj.val - это "свойство". Не узнал?
Цитата: Nixus
Ну как быть в данном случае ты и сам знаешь. operator T& () никто не отменял.
Я то знаю, поэтому и спросил. А ты вот на эти грабли наступил.
Надеюсь свой баг найдешь сам.
Цитата: Nixus
Ну ты же не знаешь как изменится min после того как туда добавят свойства? Т.е. все что приведено - по поводу текущей всерсии stl, остальное - это софистика.
Я утверждал, что глючность свойств не зависит от STL.
Ты с этим споришь, но доказать обратного не можешь?
Цитата: Nixus
Ты показал проблемы в использовании свойств автора темы и несовместимость их с частью библиотеки stl.
Я ссылался на свойства автора темы? Где?
Я базировался в своих рассуждениях на его реализации? Где?
Цитата: Nixus
Внимание, цитата:
Где я что-либо предполагаю или доказываю?
Внимание цитатЫ:
[QUOTE=Nixus]
Наличие свойств в stl никак не скажется на остальных компонентах stl в плане совместимости с версией без свойств.
однако их наличие там не сломет (как утверждают некоторые) и не сведет на нет саму билиотеку.
Нарушена концепция, если и будет, то только по отношениюк свойствам, остальные компоненты останутся такими же какие были. Т.е. не сведутся на нет и не сломаются.
В данном случае с библиотекой ничего трагического не произойдет, она будет работать как работала.
Я говорю, что если свойства введут в stl ничего c stl не случится.
По моему, я чеко выразил свою позицию. Введение свойств в stl не сведет ее на нет, т.е. библиотека не сломается.
Свойства не "сведут на нет" и не "сломают" stl.
С ним вообще ничего не случиться.
[/QUOTE]
Это даже не предположения, а утверждения. А доказательст, действительно, нет. :)
[QUOTE=Nixus]
Почему ты считаешь что свойства обязаны привязыватся к нестатическим методам? Что мешает свойствам в общем виде привязыватся к статическим?
[/QUOTE]
А какой смысл привязывать "свойства" к статическим методам?
[QUOTE=Nixus]
Возможно создать свойство, но не полуится получить доступ к членам этой структуры через оператор . примененный к объекту свойства.
[/QUOTE]
Здорово, а зачем нам такое свойство?
[QUOTE=Nixus]
Да и огласите "концепцию stl", а то эту свещенную корову все доят по поводу и без повода.
[/QUOTE]
Ну ты ввел в обсуждение "концепцию", тебе и объяснять. :)
[QUOTE=Nixus]
Ну и как свойства нарушают инкапсуляцию? Ответ: Никак.
[/QUOTE]
Докажи.
[QUOTE=Nixus]
Так же как и многое приведенное тобой.
[/QUOTE]
Если ты вводишь "свойства" в STL, это автоматически будет иметь к STL отношение.
[QUOTE=Nixus]
Т.е. boost ты не используешь и другим не советуешь?
[/QUOTE]
Крайне ограничено. И другим советую хорошенько подумать, прежде, чем использовать.
[QUOTE=Nixus]
MFC это не библиотека шаблонов.[/QUOTE]
Boost, кстати, тоже не библиотека шаблонов.