а можете вы написать контейнер, в котором могут хранится как функции так и методы? Напишите. Потом я кину пару своих строчек - сравним, что безопасней и понятней.

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

Сергей ИльичДелегат - это типа указателя на функцию? В Java его обычно так делают:
код понятен. Уточняю делегат - это указатель скорее на функтор в понятии С++, то есть это может быть как указателем на функцию, так и указателем на метод. Делегаты в C# еще из себя представляют коллекции таких указателей, которые вызываются в порядке следования.

теперь посмотрим как это можно сделать в С++. Это будет безопасней( с точки зрения контроля типов) и удобней. Потому как в вашем случае вы можете опираться только на одну сигнатуру. Сделать же контейнер из делегатов разных сигнатур у вас не получится. Если только не прибегать опять к множественным преобразованиям типов.

Итак в С++ помимо удобного bind есть такой классный шаблончик, как function<T>. Аргумент шаблона здесь это сигнатура функции. Т.е. мы имеем в своем распоряжении класс, реализация которого для функци и методов не зависит от оных помимо строгой проверки типов. Пример

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

Не сотавит труда написать и следующее vector< function<void> >, т.о. мы будем иметь несколько указателей, для последовательного их вызова. который может выглядеть так

самое главное. мне не надо по сто раз писать ОДИН и ТОТ ЖЕ код для разных типов callback функций. Суть generic programming состоит в том, чтобы также как в ООП увеличить удобства повторного использования кода и сделать это БЕЗОПАСНО. Для того чтобы изменить сигнатуру вызова callback функции изминения в случае с шаблонами минимальны, сохраняя главное условие СТРОГОЙ СТАТИЧЕСКОЙ проверки типов.

а теперь скажите мне:
1) Это такой сложный код, который я привел? Он опасен с точки зрения проверки типов?
2) если бы у вас был контейнер callback функций с множественными преобразованиями типов, то в случае с изминением типа callback-функтора ругался бы ваш компилер на все места, где нужно сделать изминения? НЕТ.

В случае с шаблонами компилятор не даст вам пропустить ни одного некорректного использования типов. Скажите разве это плохо? НЕТ! Это отлично.

относительно вашего полного непонимания книг Александреску. Вы конечно вправе иметь свое мнение, но оно больше смахивает на высказывания желтой прессы, которая не желает разбираться в том, что ей показывают. Она лишь делает "сенсационно"-крекливые возгласы, имеющие только одну цель - никакой разумности, главное взбудоражить.

Будьте последовательны. Давайте начнем с конструктива. Самый простой и часто используемый мной и моими друзьями, да и многим другими программистами, прием называемый СТРАТЕГИЯ. Скажите, что вам в нем не нравится? И почему вы считаете что он не имеет практического использования. Приведите пожалуста КОНКРЕТНЫЕ фрагменты кода это демонстрирующие в не просто голословные фразы типа: "Я ни разу его не использвал, значит он не нужен!"

Вопросик другой более сложный, скажите а вы знаете что такое фабрика объектов? Абстрастрактная фабрика? Вы считаете, что это не имеет практического использования? Или вы считаете, что реализация Александреску не подходит? Почему? укажите конкретные примеры. Желательно со ссылками на паттерн Фабрики(см.Гамму) а также с примерами кода.

www.boost.org - в большинстве своем будет включен в новый стандарт С++. уже есть в MSVC 2005 и MSDN 2005. В бусте реализованы многие приемы, которые описывал Александреску. Желающие воспользоваться только этими приемами могут найти библиотеку LOKI на сорцфорж. Но в бусте например гораздо лучше и богаче реализованы аллокаторы и функции выделения памяти для маленьких и средних объектов. Так например там есть выделение памяти для синглтонов. Но в тоже время boost не имеет реализации мультиметодов и генерации иерархий для фабрик. Хотя список типов в boost имеется mpl::vector. В локи также имеется очень удобная и гибкая реализация фабрики, абстрактной фабрики, rtti оболочки, синглтон-холдер с выбором стратегии уничтожения и оживления, ну и конечно визитер.

Сергей Ильич
Зачем нужны функции и методы? Почему не одни методы?

таково уж определение делегата. не я его выдумал.

Сергей ИльичТвой пример вообще не соберется MSVC 6
надо же! только что собрал под MSVC 6. видимо мы живем в разных мирах.


Сергей ИльичКовыряние в носу.
Это практическая необходимость. Именно так работают делегаты C#.
удобный и читабельный код. Вобчем, я так понял на яве нельзя написать контейнер для указателей на метод или функцию. На любую. Интересно глянуть как вы будете реализовывать удаление типа из списка callback методов.

Сергей ИльичКонцептуально довольно сложный. С точки зрения проверки типов очень опасен, поскольку если там где-нибудь будет неподходящий тип, то появится столько ошибок, что будет проще его переписать, чем разобраться "что же не так" ?
Я приблизительно так и думал что вы ответите.
1) можно поподробней в чем его КОНЦЕПТУАЛЬНАЯ сложность. с примерами кода. а то вы льете много воды не подтвержденой словами.
2) ошибок будет несколько вы правы. но насчет разобраться увы не так. все легко читается и исправляется. Это лучше чем лазить отладчиком и смотреть где какое преобразование типов неверно. Вы везде используйте ложные постулаты о том что ТО-ТО и ТО-ТО черезвычайно замочрочено. Это неверный подход. Хотя бы потому что это не является правдой.

вам видимо сложно понять подход generic programming, но его суть состоит и в том числе в отвлечении алгоритмов от типов операндов при сохранении строгой типизации. Как в случае с контейнерами. Я рад за программистов Явы и C#, что у них тоже появились generic. Это сильно облегчит им работу.

Вот полный список компиляторов, на которых ставится boost

Borland C++, Comeau C++ (win, non win), Metrowerks CodeWarrior Pro 6.x, 7.x, 8.x, and 9.x, GCC, Digital Mars C++, Edison Design Group, GNU GCC, Intel C++ for Linux, Intel C++ for Windows, KAI C++, Borland C++ for Linux (Kylix), MinGW, SGI MIPSpro C and C++, Microsoft Visual C++ version 6, 7, 7.1 (в SMVC 2005 включан фициально), SunPRO C++, Compaq C++ for Tru64 Version 6.5 and less, IBM Visual Age C++

Это еще в опровержении ваших поспешных высказываний.

Кстати относительно ваших поспешных высказываний, вы так и не ответили про книгу Александреску. Я вам задал пару наводящих вопросов. Делаем выводы...

Сергей ИльичMSVC 6 довольно слабо поддерживает стандарт. Готов ли ты нести ответственность за поведение boost в этих условиях ?
ну во-первых готов. Во-вторых это ответственность на самом деле несут разработчики буста. С самого ее первого появления она дружила с MSVC 6. И до появления 7.1 я спокойно юзал буст на шестерке. Никаких нареканий.

Сергей ИльичНо фича в том, что в контейнер *невозможно* положить сущность неправильного типа, не используя reflection или JNI
ктож спорит. я о другом. о том, что благодаря шаблонам я пишут ОДИН КЛАСС, который отвечает за использование callback функций и методов. Я полностью инкапсулирую все что мне нужно для этого класса. Ну там вызовы виртуальных функций (указатели на функцию или метод этого делать не могут), операции сравнения и т.д. Я делаю эту работу один раз. Далее я оформляю это в качестве шаблона. И в коде, потом просто указываю нужную сигнатуру. ВСЕ! Это как раз УМЕНЬШЕНИЕ СУЩНОСТЕЙ. Потому что мне не надо пложить классы для функций с другими сигнатурами. Понимаете, нет?

аналогично с контейнером. я беру vector и передаю ему нужный тип. мне не надо беспокоится о выделении памяти, синхронизации и прочее. Тот же прием. Мне не надо писать массив или копировать из другого файла что-то - УВЕЛИЧИВАЯ СУЩНОСТИ. я использую ОТЛАДЕННЫЙ КОД. Безопасно использую без всяких преобразований типов.

Сергей ИльичСлишком много сущностей. не больше чем в вашем варианте. Если вас так смущает ПРОСТЕЙШИЙ bind, то можно вместо boost::function написать boost::mem_fn. И код менять ОСОБО не надо, только убрав BIND. Просто в случае с function мы можем использовать не только методы, но обычные функции или СТАТИЧЕСКИЕ МЕТОДЫ. В вашем варианте такое совместное использование не возможно. Это(тип функтора) можно убрать в typedef, это можно спрятать в стратегию. Сущностей будет еще меньше. И код мне не придется почти менять. И читабельность не пострадает. Вы ИМХО предвзяты ОЧЕНЬ. Более подробно относительно УМЕНЬШЕНИЯ СУЩНОСТЕЙ см выше.

Теперь относительно больших сообщений обшибках, за которые вы ухватились как за соломинку бросив все остальное. Если посмотреть мое сообщение в этой ветке но страницей раньше, я уже сказал что все это флейм. Я написал, что помимо ООП есть generic programming и многие с ним не знакомы. Привычки выработанные годами вызвают бурю эмоций отторжения, которые зачастую ничем другим не мотивированны. Этим и объясняется большое колво ЛОЖНЫХ данных, которые даются о С++. Происходит как бы ИДЕОЛОГИЧЕСКОЕ ЗАПУГИВАНИЕ, особенно тех кто не знает что такое generic programming. Всему можно научится но обсуждать это в сравнении с принципиально другим языком - это флейм. так же я написал, что не считаю С++ идеальным языком. Как и любой другой язык и уж тем более яву. Но, во-первых это не дает право никому на ОБОБЩЕНИЯ. и, во-вторых, надо помнить о оптимальных решениях, когда кол-во плюсов, который дает инструмент превышает кол-во минусов. В той или иной ситуации.

Да, редко но случается большой дамп ошибок. ОН связан с глубиной иерархии шаблонного класса. Т.е. один класс инстанцирует другой, тот третий и т.д. и ВЕСЬ СТРАХ-ТО в том что компилятор печатает полное имя класса, которое получается нехилым. Страшно ли это? Да нет. я бы не назвал это армаггедоном.
1) умело проектируйте классы и используйте их с умом
2) есть такая штучка concept_check, которая в сочетании с static_assert побеждает этого зверя достаточно легко. Вы можете придумать свое сообщение об ошибке и ограничит глубину проверки. Используя те же шаблоны. Оба этих шаблона есть в boost, достаточно подробное их описание имеется у Александреску.
3) это была беда древних компилеров, теперь в большинстве своем они печатают сообщения более сжато, как бы ступенчато.

Итак, это происходит редко, это можно обойти, и это не ПЕРЕВЕШИВАЕТ кол-во ПЛЮСОВ использования шаблонов.

ЗЫЖ нучто ж. с контейнером функторов выяснили? вы поняли что вам придется пложить сущности в отличии от шаблонов? могу предложить еще задачку - анонимные методы. 8-))

Сергей Ильич
А она кидает исключения? А будет ли утечка памяти, если исключение выкинуто из конструктора? А если я хочу компилировать без исключений ?

А она потоково - безопасна? А если мне
1) нужна многопоточность?
2) не нужна многопоточность, но нужна скорость?

1) исключения в С++ никто не отменял, да кидает
2) про конструктор ваще смешно, стандартное раскручивание стека. никакой утечки памяти не бует. уничтожатся все объекты, кторые успели создаться. это стандарт. не только для буста.
3) если хотите без исключений ставьте опцию компилятора без исключений
4) да, буст потоково безопасна. многопоточность можно отключить.

Сергей ИльичА если обобщенному классу A нужен обобщенный класс В, а обобщенному классу B нужен обобщенный класс A?
конкретно, что вы имеете ввиду. если речь о форвардных декларациях в шаблонах они возможны.

Сергей Ильич Но в MSVC так с шаблонами делать нельзя.
я не знаю кто вам нашептывает на ушко. дайте кнкретный код, я его скомпилирую в MSVC.

Сергей ИльичПочему бы и не поплодить. Ведь в Java есть пакеты. По крайней мере я 100% знаю, что мне в качестве параметра будут передавать org.sergey.ilyich.sql-forum-conversation.Listener, а не какую-то сигнатуру.
да вы имеет право плодить сущности ради бога, я вас по рукам не бью. Однако меня вы очень рьбъяно и принципиально обвиняли в плодении сущностей. вы чертовски придирчивы и непоследовательны в своих высказываниях. не применяте свои же методы оценки к своим же методам решения. это идеализация.

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

итог - не одного трезвого аргумента против использования шаблонов.

Сергей ИльичЛямбда чтоли?
ну наверное, я понятия не имею что вы конкретно подразумеваете под этим словом. опять возвращаясь к вашему любимому критерию, который два поста назад был для вас принципиальным, а теперь вы его отторгнули. я о кол-ве сущностей. 8-) анонимные методы, тоже ИНОГДА удобный способ не плодить чего-то понапрасну.

Достаточно восторженная статья о генериках в сравнении с шаблонами. без комментариев.