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


E>Собственно у меня к тебе личная просьба. Если такой пример вдруг отыщется, то сообщи о нём нам всем. Ладно?

Предлагаю не пример, а небольшую задачку. Очень часто при разработке и проектировании встречается следующая задача — есть некий объект-источник событий, и есть подписчики на эти события. При возникновении события объект уведомляет о нем своих подписчиков. С помощью критикуемых вами технологий организация такого взаимодействия решается достаточно просто — с использованием библиотек boost::function и/или boost::signal + boost::bind решение займет три строчки. При этом ни на на подписчиков событий, ни на источник оных не будет накладываться никаких существенных ограничений при минимальном уровне связности кода. Как подобную задачу решают у вас без приминения оных "изысков"?

FF>Как подобную задачу решают у вас без приминения оных "изысков"?
Делают абстрактный класс (интерфейс). Подписчики должны его реализовывать. Не самое страшное требование, ИМХО.

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

L>Делают абстрактный класс (интерфейс). Подписчики должны его реализовывать. Не самое страшное требование, ИМХО.

Ок. Тогда конкретнее. Возьмем типичный пример — форма и набор контролов. Контролы уведомляют форму о происходящих в них событиях. Кнопка — вызовом метода void OnClick(), editbox — void OnTextChange(const char* newText), listbox — void OnSelChange(int oldItem, int newItem);
Правильно ли я понимаю вашу логику, что для каждого варианта такого вызова надо делать отдельный интерфейс? А в форме — все их реализовывать? А что мне делать, если на форме несколько кнопок, несколько полей ввода и списков, и для каждого такого контрола должен быть свой обработчик? Это первый момент. Второй — такой подход накладывает некоторые ограничения. А именно:
— В качестве обработчиков я не могу передавать свободные функции.
— Обработчиком может быть только метод полиморфного класса.
— Я обязан унаследовать класс-обработчик от заданного интерфейса.

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

AA>Легкий оффтопик: данная проблема не имеет ничего общего с шаблонами, строго говоря. Пересечение динамических имен может случится и на обычных функциях. Назвали два чувака в разных библиотеках функцию getRecordCount одинаково — и добро пожаловать в gdb. Решается с помощью version scripts для дисциплинированных или при помощи опции линкера -Bsymbolic для ленивых.

Расскажи поподробнее, как это всё поможет при наличии таки двух реализаций STL в проекте?

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

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

, я бы в базовом классе создал [чисто] виртуальную функцию которая бы вызывалась при выборе текущего айтема и отвечала за установку состояния контролов. Ну а классы-потомки бы переопределяли ее как им нужно.

K>Попробуй вначале разобраться с STL. Я Александреску читал, был в восторге. Однако на практике применить материал удаётся крайне редко. Так что можно особо не торопиться с современным программированием. Оно, как искуство каллиграфии, уходит в область, далёкую от практических задач.
Приколола фраза выделенная выше. Материал нужно применять только если это реально необходимо а не пытаться впихнуть его куда-нибудь только потому что это есть и выглядит круто и устрашающе.

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

FF>Ок. Тогда конкретнее. Возьмем типичный пример — форма и набор контролов. Контролы уведомляют форму о происходящих в них событиях. Кнопка — вызовом метода void OnClick(), editbox — void OnTextChange(const char* newText), listbox — void OnSelChange(int oldItem, int newItem);

ИМХО это стандартная задача и есмть много станадртных решений. Одно из самых простых -- задавать события идентификаторами и иметь мапинг из идентификаторов в массив обработчиков или методов, что удобнее. Что-то типа MFC-way

Всё красоты boost'а ничего особенно нового не добавляют в это дело. Кроме всяких формальных свобод. Вроде того, что можно повесить на кнопку формы сразу функцию KillProcess, а не писать для этого специальный метод-обработчик из одной строки

Лично мне больше нравится таки подход, когда отображение событий на функции задаётся как-то формально, а все обработчики являются методами какого-то класса. Скажем методами той самой формы.
Поддерживать проще как-то получается

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

Подписываюсь. Читая книжку подумал "здорово, черт возьми". Потом подумал ещё, получилось "ну и на кой черт всё это надо?". Особенно мне нравится метапрограммирование с темплейтами: часок компилируем, отлаживать невозможно, ежели где запятую забыть — компилятор либо помрёт с internal error либо следующюю неделю можно посвятить чтению его ругани. Зато вычислим факториал во время компиляции — добрую тысячу тактов в рантайме наэкономим — может лучше константу на калькуляторе посчитать? Головоломки придумываем или всё же работаем?

Если бы я в университете каком работал и мне за такие вещи платили бы — может быть...

Выбирайте самое простое из всех возможных решений.

Хотя, такие взгляды лучше держать при себе: катить бочку на гуру — рискованное занятие, узколобые догматики-фетишисты на костре сжечь могут.

E>Потому что там уже трудно придумать что-то реально хорошее и нужное. А интересны либо какие-то извраты на почве синтаксиса, либо решение каких-то сверхсложных архитектурных задачь, в реальной жизни совсем не возникающих.
Угу. Никогда не слышал ни о чем мало-мальски полезном, в написании чего участвовали бы все эти гуру от языков. Так же как и гуру от архитектуры. Если так извращатся как они рекомендуют — до практически полезного результата в жизни не доберёшся.

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

R>Но этот подход гораздо более сложней и главное для его реализации надо знать гораздо больше: механизм распространения и перехвата исключений, политики обработки исключений, границы распространения исключений и т.д.

Давно программируете? Что-то выглядит всё это так, как будто вы вчера про исключения и шаблоны узнали и преисполнились чувства собственного достоинства. Исключения никак не относятся к самым сложным вещам из тех, которые должен знать профпригодный програмер.
Шаблоны как таковые тоже не ахти какая премудрость с точки зрения их использования, хотя и предоставляют извращенцам широкое поле деятельности. Заставь дурака богу молится ...

Что значит "механизм распространения и перехвата исключений" — средства ОС + их использование компилятором? Как это выглядит в ассемблере? Уверен, если того же Александреску спросить о том как реализован "механизм распространения и перехвата исключений" в Win и Visual C++ — вряд ли он детально знает, да оно и не надо (хотя и не мешат). Важно что этот механизм работает так, как того требует спецификация языка, а как он это делает — не так уж и важно.

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

E>>Если программист стал незамениным, его пора увольнять (с) не помню кто
Q>Это теоретики... Ни разу не видел ничего подобного. Задача тимлида проследить за необходимостью "навороченности" кода и дизайна.

А я это видел в 4 фирмах и десятке продуктов. В одном из случаев из я лично был таким незаменимым (уволился сам). В мелких фирмах всегда так. А крупные — это майкрософт с ораклом, да и там не всё с этим в порядке, по некоторым признакам. Тимлидами всегда были блатные, во первых просто бездельники, а во вторых — абсолютно безграмотные — при всём своём желании не в силах понять что там делают кодеры — языка-то не знают, ОС не знают, программирования не знают, всё больше про паттерны болтают — благо не особо трудно и нет компилятора, который бы их "творения" оценил по справедливости.
А там где тимлид с головой (бывает, хотя и редко) — он и есть незаменимый.

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

Можт не совсем в тему, но:

Берёте Stingray (RogueWave) продукты (C++ библиотеки). Документация восторженнo рассказывает вам о том, какой паттерн где задействован (а мне лично не это в первую очередь интересно, мне бы про то, как пользоватся). А библиотеки — бажные, хуже некуда. Лезть же в этот паттерн-спагетти — себе дороже.

Мой жизненный опыт говорит о том, что сложности придумывают в двух случаях:
1) Не умеют работать
2) Раздувают объём работ
Ну и как дополнительный вариант — комбинация этих двух.

Много вы от майкрософта про UML, паттерны и проч. слышите (про паттерны заговорили только в посл. время)? Код у них как правило "С с классами". Но кой-какие практические результаты налицо. А покажите мне плоды трудов проповедников сложности и те огромные проекты, с которыми они справлись благодаря своим теориям. Они все аппелируют к "большим проектам" — где их большие проекты?
Я не говорю что теже паттерны — плохо, в конце концов самой нужной половиной из описанных в лит-ре все и так всю жизнь пользуются, только до жуткой на них моды не знали, что это так называется.

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

R>А есть программисты, которые сразу считают for_each — сакс, я его ни разу не применял, но всё равно это сакс.
Тот for_each который в STL — тот сакс, ибо писать функтор для каждого чиха неудобно
BOOST_FOREACH гораздо удобнее

Здравствуйте, Аноним, Вы писали:

А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр.
ИМХО, "стратегии", "паттерны" так бешенно популярны, потому как осилить все мировые запасы информации на эту тему проще, чем одну главу у Кнута. Потом ходишь и слова разные такие умные говоришь, все уважают. А какой прок от Кнута? (шучу, разумеется).

Положа руку на сердце — ведь то, что описано в любой лит-ре по дизайну/паттернам — доступно пониманию ребёнка. Берём для сравнения какую-нибудь книгу по, например, ЦОС, сжатию данных — упс — без определённой подготовки — далеко не уедешь.

Я не против паттернов, но: теоретическое знание паттернов — это то, что дёшего приобретают, но норовят дорого продавать. Спекуляцией попахивает. Любой нормальный программист с опытом от 3-5 лет и больше знает кучу паттернов, даже если никогда не штудировал эту тему специально. Пролистать соотств. лит-ру и такому не мешает, но каких либо великие откровения мало-мальски опытные программисты там вряд ли смогут обнаружить. Просьба не ссылатся на отдельных дебилов которые это утверждение якобы опровергают фактом своего существования.

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

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

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


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

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

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

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

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

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

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

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


Было несколько некрофилов , компания egartech.ru
Люди восприняли проект как свою личную песочницу и поюзали всю мощь Loki до какой смогли добраться.
А там где Loki не хватило или там где имена были слишком длинныим обильно склеили соплями макросов.
Использовать макросы они стеснялись не больше чем Loki, я даже подозреваю что они их ЛЮБИЛИ
Сомневаюсь что кто-то может представить ЧТО получилось ЭТО надо видеть.

Здравствуйте, Аноним, Вы писали:

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

А>Подписываюсь. Читая книжку подумал "здорово, черт возьми". Потом подумал ещё, получилось "ну и на кой черт всё это надо?". Особенно мне нравится метапрограммирование с темплейтами: часок компилируем, отлаживать невозможно, ежели где запятую забыть — компилятор либо помрёт с internal error либо следующюю неделю можно посвятить чтению его ругани. Зато вычислим факториал во время компиляции — добрую тысячу тактов в рантайме наэкономим — может лучше константу на калькуляторе посчитать? Головоломки придумываем или всё же работаем?
Дык не для этого все это писалось... Не для практики... А для защиты диссера...
Понимать нужно... Что у чела — цель другая... Диссер защитить...

А>Выбирайте самое простое из всех возможных решений.
В практическом программировании — безусловно!

Здравствуйте, Аноним, Вы писали:

А>Давно программируете? Что-то выглядит всё это так, как будто вы вчера про исключения и шаблоны узнали и преисполнились чувства собственного достоинства.

Достаточно для того, что бы писать то, что я пишу.

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

Я и не утверждал обратного. Я считаю, что исключения просто относятся к тем вещам, которые "должен знать профпригодный програмер".

А>Шаблоны как таковые тоже не ахти какая премудрость с точки зрения их использования, хотя и предоставляют извращенцам широкое поле деятельности. Заставь дурака богу молится ...

Если говорить о конкретных вещах/технологиях/библиотеках и т.д. То я считаю, что для человека с головой и способного для обучения вообще есть очень мало действительно сложных вещей.
При желании и наличии времени практически любую вещь можно изучить без особых сложностей. Различие в том, что можно желать и изучать что-то, а можно просто научится пользоваться на минимальном уровне и далее остановится.


А>Что значит "механизм распространения и перехвата исключений" — средства ОС + их использование компилятором? Как это выглядит в ассемблере? Уверен, если того же Александреску спросить о том как реализован "механизм распространения и перехвата исключений" в Win и Visual C++ — вряд ли он детально знает, да оно и не надо (хотя и не мешат). Важно что этот механизм работает так, как того требует спецификация языка, а как он это делает — не так уж и важно.

Зря ты такого мнения о Александреску. Он не только книжки пишет.
Хотя бы надо знать "как того требует спецификация языка". Многие не знают и этого. Вот что именно я подразумевал под "механизм распространения и перехвата исключений". Различные важные детали. Почему исключения надо ловить по ссылке. Почему кидать по значению. Что можно сделать в try блоке функции. Почему нельзя допускать вылета исключений из деструктора. И т.д. Тонких моментов много.
По поводу реализации на уровне ОС/компилятора. В принципе, это можно и не знать. Но. На то мы и с++ программисты, а не java программисты. Для java программиста, например, совсем не обязательно знать что такое стек и как на нём располагаются различные объекты. Или как изнутри выглядят их объектные сслыки. Или что такое указатель. Они и так вполне хорошо и быстро могут делать приложения определённого класса. С++ программист, я лично считаю, должен знать что такое стек, указатель, адрес возврата и т.д. Далее для себя каждый уже может решать лично хочет ли он знать эти вещи или нет.

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

R>Было несколько некрофилов , компания egartech.ru
R>Люди восприняли проект как свою личную песочницу и поюзали всю мощь Loki до какой смогли добраться.
R>А там где Loki не хватило или там где имена были слишком длинныим обильно склеили соплями макросов.
R>Использовать макросы они стеснялись не больше чем Loki, я даже подозреваю что они их ЛЮБИЛИ
R>Сомневаюсь что кто-то может представить ЧТО получилось ЭТО надо видеть.

Проекты написанные в стиле old-C тоже, знаешь, бывают "произведениями искусства"
Макросы там тоже, кстати, некоторые очень любят.
Суть не в шаблонах и не в макросах, суть, имхо, глубже. Шаблоны и макросы — средства.

Тут вот, например, есть один товарищь (не будем называть имён ), который пишет темы типа ручного создания аналога таблицы виртуальных функций с динамичискими временными замещениями ряда функций, и с поддержкой copy-on-write... Бррр. Мурашки по коже бегут

Макросы на пару экранов тоже приходилось видеть

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

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

R>>А есть программисты, которые сразу считают for_each — сакс, я его ни разу не применял, но всё равно это сакс.
CC>Тот for_each который в STL — тот сакс, ибо писать функтор для каждого чиха неудобно
CC>BOOST_FOREACH гораздо удобнее

Ну вот про это я и говорил. Ты знаешь и понимаешь чем for_each сакс. И чем BOOST_FOREACH не сакс

Здравствуйте, Аноним, Вы писали:

А>Что значит "механизм распространения и перехвата исключений" — средства ОС + их использование компилятором? Как это выглядит в ассемблере?

Кстати ничего сложного и для C++-программиста очень полезно

http://www.wasm.ru/article.php?article=Win32SEHPietrek1

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

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

R>>Было несколько некрофилов , компания egartech.ru
R>>Люди восприняли проект как свою личную песочницу и поюзали всю мощь Loki до какой смогли добраться.
R>>А там где Loki не хватило или там где имена были слишком длинныим обильно склеили соплями макросов.
R>>Использовать макросы они стеснялись не больше чем Loki, я даже подозреваю что они их ЛЮБИЛИ
R>>Сомневаюсь что кто-то может представить ЧТО получилось ЭТО надо видеть.

R>Проекты написанные в стиле old-C тоже, знаешь, бывают "произведениями искусства"
R>Макросы там тоже, кстати, некоторые очень любят.
R>Суть не в шаблонах и не в макросах, суть, имхо, глубже. Шаблоны и макросы — средства.

R>Тут вот, например, есть один товарищь (не будем называть имён ), который пишет темы типа ручного создания аналога таблицы виртуальных функций с динамичискими временными замещениями ряда функций, и с поддержкой copy-on-write... Бррр. Мурашки по коже бегут

R>Макросы на пару экранов тоже приходилось видеть

R>

Речь шла о примерах реального применения Loki

"-Доктор я умру?
— А как же!.. Лет через 30-40 если будете соблюдать умеренность в еде и питье
" (c)

В данном случае люди попав за шведский стол попытались скушать ВСЕ
Не важно что они кушали, шаблоны, макросы или С-функции с GlobalVar-ами, важно что умеренность и совместимось не соблюадась — НО это И ТАК ПОНЯТНО любому ежику