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

E>Здравствуйте, Константин Л., Вы писали:


КЛ>>Ну от некоторых частей буста я тоже в шоке — трудно для понимания, с наскоку не разберешся.
E>+1

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

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

J>Грубо говоря, если тебе нужно нечто вроде for_each(v, v+size, mem_fun_ptr), то если у тебя нет под рукой STL — ты напишешь цикл и не будешь париться, а если под рукой есть STL — ты заюзаешь for_each. Но несмотря на все преимущества for_each, если у тебя нет STL, то ради одного for_each городить всю многофайловую инфраструктуру из iterator, algorithm, functional и т.д. несколько неумно. Но если оно уже есть — почему бы этим не воспользоваться?
Я вот не особо понимаю что же за преимущества у for_each? Мне for в данном конкретном случае и понятнее и приятнее и если не дай божи чего не работате, меня не утянет "под капот" откуда я может и не вынырну без помощи более опытного товарища


J>Я к тому, что нельзя с мерками прикладного кода подходить к библиотечному коду. А Александреску выступает именно как разработчик библиотек, и ничего страшного не произойдет, если ты, помимо STL, подключишь Loki, потому что пользоваться ею, насколько я понимаю — не сложнее, чем STL. А вся александресковская сложность — под капотом, ты ее и не увидишь и дела с ней иметь не будешь. Укажешь в параметрах типа, что именно тебе надо — и вперед.

Ну вот мне не известно удачных случаев применения библиотеки Loki. В сложном коде, в простом, в очень сложном. Короче в любом.
Мало того, я сильно подозреваю, что их никто не сможет привести.
Хотя мне известны попытки. Все в конце концов неудачные. Как на уровне использования Loki, так и на уровне использования идей А.

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

Мне не нравится парадигма "сделать так сложно, как только можно".
Мне нравится парадигма "сделать так просто, как только можно".
Понятно что слишком просто делать дорого. Но всё-таки стремиться надо к простоте, а не к сложности.
Если, например, у тебя протая программа, которая интегрирует 20 COM-объектов между собой, то напиши её на VB или на C# и не парь себе мозг без нужды с Comet

Автор: Cyberax
Дата: 17.04.06

.
Понятно, что если у тебя сложный проект, который ещё к тому же и 100 COM-объектов интегрирует и сам много чего нетривильного делает и почему-то никак не удобно все мозги засунуть в 101-й COM-объект, а менеджер этого барахла забомбить таки на VB, то тогда конечно проще будет с наворотами. Но это только тогда и только если действительно проще не сделать. А не всегда, когда есть такая возможность, раз уж мы научились писать такие решения не слишком задорого.

При этом соображения о том, что "все сложности под капотом" не многое тут меняет. Потому что эти все сложности с нами. Мне и std::vector не нравится потому, что он заради довольно простой функциональности, рожает нереально много всяких сложных довесочков. И от них нельзя просто отказаться.
Я бы, например, предпочёл, чтобы возможность использования алгоритмов подключалась в stl по явному требованию. А не была намертво в него вцементирована всегда. Почему? Потому что каждый раз, когда где-то, как правило в каком-то неудачном коде написанным невнимательным новичком, портится память, так я попадаю мордой под этот капот.И вынужден там ковыряться. И при этом пользы-то никакой от наворотов я не получаю. Получаю гемор, поучаю догую компиляцию, получаю причудливую зависимость от версий компиляторов и библиотек и много чего ещё "хорошего". А вот реально хорошего от этой всей сложности получаю мало. Потому что все "выгоды", заради которых всё так непросто, они мне не нужны. И я не думаю, что потому, что я учавствую в разработке слилшком простых программ.

Я ещё раз призываю рассказать где же оно всё бывает нужно-то?

Здравствуйте, Константин Л., Вы писали:

КЛ>Он это сказал аж в 2002 году. Для кого-то это не ново, для кого-то ново.

На самом деле книга вышла в начале 2001 года. Наверное, пять лет назад она была чем-то новым и интересным. А на мой вкус, если нужна книжка о шаблонах, то сейчас есть замечательная "C++ Templates: The Complete Guide", про паттерны тоже надо читать не Александреску. А вот если возникла идея реализовать свой велосипед аналогичный какому-нибудь из Loki-велосипедов, то в книжку эту можно и заглянуть, чтобы посмотреть описание одного из путей реализации и граблей с ним связанных.

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

E>Здравствуйте, Константин Л., Вы писали:

КЛ>>Нууу, я всей темы не знаю. Мало-ли как вы там его писали и нужен ли он был вообще . Я юзал 1 раз и остался очень доволен
E>Ну писали хорошо довольно. Но не шмогли всё равно прислонить с толком
E>А вообще интересно бы узнать задачу.

Есть иерархия полиморфных объектов, которые отображаются в комбобоксе. При изменении текущего объекта в комбике надо апдейтать UI(кнопочки, радиобаттоны и т.п.). Вот для этой хрени я и заюзал визиторов. Иерархия состоит из 3х(!) классов. И вот из-за них я и замутил все это дело с визиторами. Скажешь зачем, ведь проще было if'ов напихать? Да, проще, но я решил что:
а) так красивее (просто мне нравится!)
б) потом если придется добавить 4, 5, 6 класс я пойму, что сделал правильный выбор.

НО, у visitors есть свои нехилые недостатки (взаимозависимости) и никто не говорит о том, что это панацея.

КЛ>Есть иерархия полиморфных объектов, которые отображаются в комбобоксе. При изменении текущего объекта в комбике надо апдейтать UI(кнопочки, радиобаттоны и т.п.). Вот для этой хрени я и заюзал визиторов. Иерархия состоит из 3х(!) классов. И вот из-за них я и замутил все это дело с визиторами. Скажешь зачем, ведь проще было if'ов напихать? Да, проще, но я решил что:
КЛ>а) так красивее (просто мне нравится!)
КЛ>б) потом если придется добавить 4, 5, 6 класс я пойму, что сделал правильный выбор.

КЛ>НО, у visitors есть свои нехилые недостатки (взаимозависимости) и никто не говорит о том, что это панацея.

Насколько я помню visitor как раз удобен там где иерархия классов в будущем не будет изменяется, а будут только добавляться новые операции. Так что слова о 4,5,6 классе звучат странно.

Если я не ошибаюсь , то патерн визитор , полезен в иерархии где изменение базовых классов недопустимо , в вашем случае это было так ? Т.е. действительно нельзя было добавить пару виртуальных функций ?

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

L>Насколько я помню visitor как раз удобен там где иерархия классов в будущем не будет изменяется, а будут только добавляться новые операции. Так что слова о 4,5,6 классе звучат странно.

Насколько я понял 4, 5, 6 -- это клиенты. А визитор посещает контролы.

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

_DA>На самом деле книга вышла в начале 2001 года. Наверное, пять лет назад она была чем-то новым и интересным. А на мой вкус, если нужна книжка о шаблонах, то сейчас есть замечательная "C++ Templates: The Complete Guide", про паттерны тоже надо читать не Александреску. А вот если возникла идея реализовать свой велосипед аналогичный какому-нибудь из Loki-велосипедов, то в книжку эту можно и заглянуть, чтобы посмотреть описание одного из путей реализации и граблей с ним связанных.

Но главная польза, ИМХО, в том, что можно на всё это поглядеть и задуматься. Точно ли это таки надо?

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, Erop, Вы писали:

E>>Здравствуйте, Константин Л., Вы писали:

КЛ>>>Нууу, я всей темы не знаю. Мало-ли как вы там его писали и нужен ли он был вообще . Я юзал 1 раз и остался очень доволен
E>>Ну писали хорошо довольно. Но не шмогли всё равно прислонить с толком
E>>А вообще интересно бы узнать задачу.

Ну вроде как эту же задачу решают при помощи property sheets. И всё хорошо вроде как выходит. И без всяких визиторов. И контроды можно для разных объектов иметь вообще разные, с произвольно устроенной логикой. И попроще всё. И менять легче.

Или я чего-то не догнал?

Здравствуйте, Константин Л., Вы писали:

КЛ>>>Ну от некоторых частей буста я тоже в шоке — трудно для понимания, с наскоку не разберешся.
E>>+1

КЛ>Хочу заметить, что тут может играть роль наше подсознательное (или сознательное) чувство того, что мы так написать не можем (мозгов не хватает), и из-за этого может появится неприятие, непонимание, и даже отвращение ко всяким там бустам и т.п.
КЛ>


Увы, но я могу. Просто я стараюсь себя ограничивать, так как понимаю насколько это таки деструктивно

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

КЛ>>Есть иерархия полиморфных объектов, которые отображаются в комбобоксе. При изменении текущего объекта в комбике надо апдейтать UI(кнопочки, радиобаттоны и т.п.). Вот для этой хрени я и заюзал визиторов. Иерархия состоит из 3х(!) классов. И вот из-за них я и замутил все это дело с визиторами. Скажешь зачем, ведь проще было if'ов напихать? Да, проще, но я решил что:
КЛ>>а) так красивее (просто мне нравится!)
КЛ>>б) потом если придется добавить 4, 5, 6 класс я пойму, что сделал правильный выбор.

КЛ>>НО, у visitors есть свои нехилые недостатки (взаимозависимости) и никто не говорит о том, что это панацея.

L>Насколько я помню visitor как раз удобен там где иерархия классов в будущем не будет изменяется, а будут только добавляться новые операции. Так что слова о 4,5,6 классе звучат странно.

Не совсем. Добавление нового класса влечет за собой добавление новых методов void Visitor::Visit( SomeNewType& ); void SomeNewType::Accept( Visitor* ).
При этом меняется только интерфейс Visitor'а. Новые операции появляются за счет создания наследников Visitor'а. Так что о не применимости этого паттерна к иерархии, которая изменяется( в большинстве же случаев она разрастается ) не совсем корректно. Как раз о ее применимости и пишет господин А.
Кстати, она у меня скорее всего не изменится никогда.

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

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

L>>Насколько я помню visitor как раз удобен там где иерархия классов в будущем не будет изменяется, а будут только добавляться новые операции. Так что слова о 4,5,6 классе звучат странно.

E>Насколько я понял 4, 5, 6 -- это клиенты. А визитор посещает контролы.

Он посещает клиентов, и, в зависимости от того, что за клиент, он изменяет статусы контролов.

Здравствуйте, Константин Л., Вы писали:

L>>>Насколько я помню visitor как раз удобен там где иерархия классов в будущем не будет изменяется, а будут только добавляться новые операции. Так что слова о 4,5,6 классе звучат странно.
E>>Насколько я понял 4, 5, 6 -- это клиенты. А визитор посещает контролы.
КЛ>Он посещает клиентов, и, в зависимости от того, что за клиент, он изменяет статусы контролов.


Тогда действительно не понятно при чём тут visitor?

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

E>Здравствуйте, Константин Л., Вы писали:

КЛ>>Здравствуйте, Erop, Вы писали:

E>>>Здравствуйте, Константин Л., Вы писали:

КЛ>>>>Нууу, я всей темы не знаю. Мало-ли как вы там его писали и нужен ли он был вообще . Я юзал 1 раз и остался очень доволен
E>>>Ну писали хорошо довольно. Но не шмогли всё равно прислонить с толком
E>>>А вообще интересно бы узнать задачу.

E>Ну вроде как эту же задачу решают при помощи property sheets. И всё хорошо вроде как выходит. И без всяких визиторов. И контроды можно для разных объектов иметь вообще разные, с произвольно устроенной логикой. И попроще всё. И менять легче.

E>Или я чего-то не догнал?

property sheets тут не подходят

Здравствуйте, Константин Л., Вы писали:

КЛ>Не совсем. Добавление нового класса влечет за собой добавление новых методов void Visitor::Visit( SomeNewType& ); void SomeNewType::Accept( Visitor* ).
КЛ>При этом меняется только интерфейс Visitor'а. Новые операции появляются за счет создания наследников Visitor'а. Так что о не применимости этого паттерна к иерархии, которая изменяется( в большинстве же случаев она разрастается ) не совсем корректно. Как раз о ее применимости и пишет господин А.
КЛ>Кстати, она у меня скорее всего не изменится никогда.

Но, казалось бы, операция у тебя всего одна -- типа выбрали элемент.
На кой тебе визитёр?

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

M>Если я не ошибаюсь , то патерн визитор , полезен в иерархии где изменение базовых классов недопустимо , в вашем случае это было так ? Т.е. действительно нельзя было добавить пару виртуальных функций ?

Откуда такая информация? Каких виртуальных функций?
Упрощенный смысл визитора в том, что он позволяет статически выбирать тип объекта с помощью динамического механизма. Т.е. выбор типа объекта, с которым будем работать, делает сам объект, статически.

Здравствуйте, Константин Л., Вы писали:

E>>Или я чего-то не догнал?
КЛ>property sheets тут не подходят

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

Ну типа есть список людей, и окно с их свойствами, которые можно редактировать. Типа у женщин одни кнопки у мужчин другие у детей третьи. Иногда они совпадают иногда нет. Могут перемещаться, запрещаться, прятаться и т. д.

Обычно это делают при помощи PS. Что мешало так поступить и тебе?

Или я задачу совсем не понял?

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

E>Здравствуйте, Константин Л., Вы писали:

КЛ>>Не совсем. Добавление нового класса влечет за собой добавление новых методов void Visitor::Visit( SomeNewType& ); void SomeNewType::Accept( Visitor* ).
КЛ>>При этом меняется только интерфейс Visitor'а. Новые операции появляются за счет создания наследников Visitor'а. Так что о не применимости этого паттерна к иерархии, которая изменяется( в большинстве же случаев она разрастается ) не совсем корректно. Как раз о ее применимости и пишет господин А.
КЛ>>Кстати, она у меня скорее всего не изменится никогда.

E>Но, казалось бы, операция у тебя всего одна -- типа выбрали элемент.
E>На кой тебе визитёр?

Я уже писал об этом здесь

Автор: Константин Л.
Дата: 18.04.06

Захотелось сделать так. А насколько это оправданно?... Просто тогда мне показалось это более целесообразным. Может быть завтра я посмотрю на тот код и удивлюсь, зачем я так сделал.

Здравствуйте, Константин Л., Вы писали:

КЛ>Захотелось сделать так. А насколько это оправданно?... Просто тогда мне показалось это более целесообразным. Может быть завтра я посмотрю на тот код и удивлюсь, зачем я так сделал.


Ну в общем "и так каждый раз" (с) известный анекдот.

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

E>Здравствуйте, Константин Л., Вы писали:

E>>>Или я чего-то не догнал?
КЛ>>property sheets тут не подходят

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

E>Ну типа есть список людей, и окно с их свойствами, которые можно редактировать. Типа у женщин одни кнопки у мужчин другие у детей третьи. Иногда они совпадают иногда нет. Могут перемещаться, запрещаться, прятаться и т. д.

E>Обычно это делают при помощи PS. Что мешало так поступить и тебе?

E>Или я задачу совсем не понял?

Почти. Есть комбик для выбора текущего айтэма. Есть 2 кнопки, которые грэются в зависимости от него. Есть группа радиобаттонов, которые тоже могут грэиться. Есть листвью. В общем, все контролы общие, и я даже не думал делать это через ps. Кроме того, как ты стал бы выбирать, какой ps показывать? Опять же, либо if'ы, либо vf'ы, либо visitors. Надеюсь, теперь понятно?