Замыкания для методов классов в C++. Как?

← →
Городской Шаман (2008-12-12 22:20) [0]

Как самым простым способом в С++ реализовать замыкания для объектных функций?

Аналог делфийского:
TGetIntVal = function: Integer of object;

Вроде бы в boost нечто такое было, только найти не могу.

← →
Городской Шаман (2008-12-12 22:24) [1]

Конечно я могу реализовать так, но нужно указывать имя класса. А можно ли в динамике?

typedef int (ClassName::*TGetIntVal)();

← →
Сергей М. © (2008-12-12 22:25) [2]

> замыкания

Это ж надо так извратиться - назвать декларацию [прото]типа "замыканием")

← →
Городской Шаман (2008-12-12 22:33) [3]

Ну так борланд называет из в своём CBuilder - __closure, что в переводе значит замыкание.
typedef void __fastcall (__closure *TNotifyEvent)(System::TObject* Sender);

← →
Сергей М. © (2008-12-12 22:42) [4]

> что в переводе значит замыкание

Заглушка, затычка, квача в конце-концов - но не замыкание же !
Нельзя же так "в лоб" переводить)

← →
Городской Шаман (2008-12-12 22:44) [5]

> Сергей М. © (12.12.08 22:42) [4]

В книгах по computer science это тоже называется термином "замыкание".

Так вот хотелось бы особую компиляторную магию borland перенести на стандарт C++.

← →
Сергей М. © (2008-12-12 23:01) [6]

> В книгах по computer science это тоже называется термином
> "замыкание".

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

С какого бы бодуна ни были парни из Борланда, когда специфицировали этот "клозюр", все-таки речь, согласись, шла об обычном делегировании

← →
lucy (2008-12-12 23:31) [7]

http://www.boost.org/doc/libs/1_37_0/doc/html/function.html

или используй указатели на методы (->*).

← →
oxffff © (2008-12-12 23:54) [8]

> Сергей М. © (12.12.08 22:42) [4]

Вам бы не мешало освежить свои знания.

http://en.wikipedia.org/wiki/Closure_(computer_science)

In computer science, a closure is a function that is evaluated in an environment containing one or more bound variables. When called, the function can access these variables.

Так вот захват методом окружения вызова(читай объекта) есть суть процесса замыкания.

Но никак
не Заглушка,
не затычка,
не квача в конце-концов. :)

← →
Дятел © (2008-12-13 05:10) [9]

Городской Шаман (12.12.08 22:20)
Как самым простым способом в С++ реализовать замыкания для объектных функций?

Да нету способа. Страуструп об этом просто не подумал. Папа Борланд подумал, а Страуструп - ни фига.

← →
Григорьев Антон © (2008-12-13 08:32) [10]

> Сергей М. © (12.12.08 23:01) [6]
> Мало ли у нас авторов-переводчиков, не отягощенных бременем
> ответственности за "правильные жаргонизмы")

Много раз встречал перевод термина closure, и везде это было замыкание. Правда, впервые вижу, чтобы это слово употребяли по отношению к простым ссылкам на функции. Обычно его используют только в функциональных языках, в которых есть функции высших порядков, т.е. функции, результатом работы которых являются другие функции. Причём, не как в Delphi или C++, указатели на ранее объявленные функции, а именно новые функции, которые конструируются в run-time. И эти сконструированные функции называются замыканиями, потому что они замыкают на себя контекст той функции, которая их сконструировала.

Свойствами замыкания отчасти обладают анонимные функции в D2009, но никак не ссылки на методы класса. И почему Borland употребил это слово, мне тоже непонятно.

← →
oxffff © (2008-12-13 13:57) [11]

> Григорьев Антон © (13.12.08 08:32) [10]
Свойствами замыкания отчасти обладают анонимные функции в D2009, но никак не ссылки на методы класса. И почему Borland употребил это слово, мне тоже непонятно.

Свойствами замыканий не отчасти, а обладают анонимные функции D2009.

В том то и дело, что указатель на метод - это просто указатель на код. А указатель на метод объекта(.. of object) - это указатель код + окружение метода, т.е объект. Это в чистом виде замыкание, т.е неявно переданный контекст вызова. В С++ от Microsoft этого нет, а в СBuilder это есть.

← →
Городской Шаман (2008-12-13 17:14) [12]

> Дятел © (13.12.08 05:10) [9]
>
> Городской Шаман (12.12.08 22:20)
> Как самым простым способом в С++ реализовать замыкания для
> объектных функций?
>
> Да нету способа. Страуструп об этом просто не подумал. Папа
> Борланд подумал, а Страуструп - ни фига.

Есть, там немного нарушаются стандарты С++, но на всех известных компиляторах работает.
http://www.rsdn.ru/article/cpp/fastdelegate.xml

Ну и boost::function, но это более медленный способ(по вызову).

← →
Городской Шаман (2008-12-13 17:18) [13]

Вот пример использования применимо к моей проблематике

#include "FastDelegate.h" class RenderClass{ public: virtual int GetInt(){return 10;}; }; class CustomRenderClass: public RenderClass{ public: virtual int GetInt(){return 15;}; }; typedef fastdelegate::FastDelegate0<int> TDGetInt; class DabClass{ public: TDGetInt dGetInt; }; void _TestDelegate(){ CustomRenderClass rdc; DabClass dc; dc.dGetInt = NULL; dc.dGetInt = fastdelegate::MakeDelegate(&rdc,&CustomRenderClass::GetInt); int _res = dc.dGetInt(); }

← →
lucy (2008-12-13 20:39) [14]

Городской Шаман (13.12.08 17:14) [12]
>Есть, там немного нарушаются стандарты С++, но на всех известных компиляторах работает.

Все, кому было нужно, эту статью давно уже прочитали. Вы должны ясно осознавать, что то или определенное средство налагает на своего пользователя ряд фундаментальных ограничений, и попытки преступить эти ограничения с помощью "магии" - есть ересь.
С++ предполагает отсутствие магии (хотя не отменяет мистики), но взамен предоставляет средства, с помощью которых то чего нет в C++ может быть реализовано на самом C++. Это часть его идеологии. Без магии это может выглядеть странно и, может быть многословно, но вы должны мириться с этим, если не хотите выходить за фундаментальные ограничения, налагаемые языком. Вы должны смириться и с тем, что будучи связанным стандартом, C++ развивается медленно, и принимать его таким какой он есть. Только так вы сможете достичь просветления. Пожалуйста, не позорьтесь перед общественностью.

← →
Городской Шаман (2008-12-13 21:27) [15]

> lucy (13.12.08 20:39) [14]

Я не отношусь к религиозным фанатикам языка. Для меня язык всего лишь инструмент, как молоток, а не предмет для поклонения. И если я вижу возможность писать на C++ как я привык на Delphi, то с моей точки зрения это всего лишь третий "+" к C++.

← →
lucy (2008-12-13 21:36) [16]

Городской Шаман (13.12.08 21:27) [15]

Магия дельфи учит вас плохому, юный гакусэй. Не сравнивайте дельфи и С++. Вы поняли бы почему не стоит это делать, если бы сначала изучили С++. К сожалению, большинство приверженцев дельфи не хотят видеть ничего за пределами своего маленького мирка и осознать, что существует не только дельфи и не только С++. Отсюда их фанатизм и дельфицентричность. Почитайте чужой исходный код, и станется вам. Возможно, вы поймете тогда, что используете инструмент не так, как это виделось его создателям и не совсем по назначению.

← →
Городской Шаман (2008-12-13 22:04) [17]

> lucy (13.12.08 21:36) [16]

А какое назначение у С++? Ходить с косой и распальцовкой что типа крутой ЦЦ-программист, не чета этим ламерам-делфистам?

Здесь уже об этом уже давно говорили, но снова повторю - "работодателю важна нацеленность на результат, а не на процесс".

← →
lucy (2008-12-13 22:23) [18]

Городской Шаман (13.12.08 22:04) [17]

>А какое назначение у С++? Ходить с косой и распальцовкой что типа крутой ЦЦ-программист, не чета этим ламерам-делфистам?

Чтобы вы поняли, о чем речь - C++, как и C - это язык стандартизированный ISO. То есть этот язык, как и C претендует на звание lingua franca. Именно в этом его назначение. Соответственно, сфера его применения предполагает несколько более широкий охват (и можно сказать, что с этим он справляется), нежели чем написание бухгалтерских приложений. Но он может использоваться и для этой цели. Сфера же дельфи, в основном, не выходит за рамки написания упомянутых выше приложений. Причем, в кросплатфоменности и гибкости (если сравнивать, например, по возможностям поддержки ООП), дельфи значительно уступает другим пропиетарным технологиям (таким, как NET или Java). Однако, для написания пользовательского интерфейса для работы с БД она чертовски удобна. Теперь, поняв что к чему, сравните мировоззрение разработчиков той или иной стороны, учтя при этом такую особенность человеческой психики, как стремление мерить все своими мерками. Для того, чтобы приоткрыть завесу над Истиной, достаточно внимательно прочесть [14].

← →
Городской Шаман (2008-12-13 22:39) [19]

> lucy (13.12.08 22:23) [18]

А можно я сам решу что мне хорошо?

← →
Городской Шаман (2008-12-13 22:43) [20]

> lucy (13.12.08 22:23) [18]

И вообще стандарт в С++, это как работа по трём зелёным свисткам, а вот что это такое понимает по разному каждый из разработчиков компиляторов и библиотек.

С++ настолько сложен, что про стандарт говорить уже нельзя, так как это абстракция которую нельзя полностью реализовать в компиляторе, можно реализовать близкую аналогию к стандарту.

← →
lucy (2008-12-13 22:45) [21]

Городской Шаман (13.12.08 22:39) [19]

>А можно я сам решу что мне хорошо?

Конечно, конечно. Только не ходите тогда по веткам с транспарантом "Я считаю, что это хорошо, потому, что гладиолус, а на то, как это принято в среде пользователей данного инструмента мне наплевать".

← →
Городской Шаман (2008-12-13 22:48) [22]

> lucy (13.12.08 22:45) [21]

Вот поэтому серьёзные программисты обычно выбирают Delphi, так как он позволяет тупо решать проблемы, без всякой философии.

Я в С++ одних реализаций делегатов уже 7 нашёл. НАФИГА СТОЛЬКО?

← →
lucy (2008-12-13 22:59) [23]

lucy (13.12.08 22:45) [21]
>И вообще стандарт в С++, это как работа по трём зелёным свисткам

В этом мире есть только один идеальный объект - сферический конь в вакууме :) Но попробуйте порассуждать, зачем вообще нужен этот стандарт, и что было бы, не будь его.

>Я в С++ одних реализаций делегатов уже 7 нашёл. НАФИГА СТОЛЬКО?

Реализаций калькулятора и открывателя cd-rom на дельфи на несколько порядков больше.

>Вот поэтому серьёзные программисты обычно выбирают Delphi, так как он позволяет тупо решать проблемы, без всякой философии.

Вот опять вы пытаетесь мерить все своими мерками. Это говорит о том, что вы не пытались писать серьезные ОО приложения на дельфи и расширять уже существующие. Когда вам доведется, вы вспомните эти слова.
Я вижу также, что вы испытываете серьезный дефицит общения. Завтра непременно выйдите на улицу, подышите свежим возудухом, поспрашивайте у прохожих который сейчас час, как проехать в библиотеку, спросите у милиционера как дела. Удачи вам.

← →
Alkid (2008-12-13 23:11) [24]

> Городской Шаман (13.12.08 22:48) [22]
> lucy (13.12.08 22:59) [23]

Ребята, давайте жить дружно!
Серьёзные специалисты уже давно выбирают С# :)
А Delphi и C++, при всех их достоинствах и несомненных заслугах для истории языков программирования, уходят со сцены в узкие экологические ниши.

← →
Городской Шаман (2008-12-13 23:49) [25]

> Alkid (13.12.08 23:11) [24]

Покажите хоть одну продакшин игру на C#.

← →
Городской Шаман (2008-12-13 23:51) [26]

Насчёт отмирания C++ не особо заметно
http://www.indeed.com/jobtrends?q=delphi%2C+C%23%2C+C%2B%2B&l=

← →
Alkid (2008-12-14 09:37) [27]

> Городской Шаман (13.12.08 23:49) [25]
> Покажите хоть одну продакшин игру на C#.

Игры являются одной из экологических ниш, где С++ самое место.

> Насчёт отмирания C++ не особо заметно

На самом деле как раз заметно - количество С++ вакансий стабильно, в то время, как шарповых - растёт. Т.е. имеется увеличение количества вакансий при стабильном количестве вакансий С++ => доля С++ на рынке падает.

Если говорить серьёзно, то я не говорил об отмирании. Я говорил об уходе в свои ниши. Для С++ это:
1. High-performace-приложения, где надо драться за байты и такты. Игры - хороший пример. Real-time процессинг информации (аудио, видео и т.п.) - тоже.
2. Кросс-платформенная разработка, особенно околосистемных вещей.
3. Работа в устройствах с жёсткими ограничениями по ресурсам.
Возможно я не всё перечислил.

В чём основная сила С++? Она в эффективности. С++ оправдан там, где необходимость экономить ресурсы машины важнее, чем экономить время программиста. Там, где такого требования нет, разумнее писать на более высокоуровневых языках.

Не надо думать, что я недооцениваю С++ или Delphi. Я очень много работал и на том и на другом и знаю их достоинства и недостатки. Сейчас, кстати, я программирую как раз на С++, но даже у нас в проекте имеется тенденция к увеличению доли .NET модулей по сравнению с C++-ными по мере развития продукта. Сейчас начинаем делать новоую версию, почти всё делаем на C#. Всё, что не можем на C# по техническим или историческим причинам - на С++.

← →
Alkid (2008-12-14 09:39) [28]

Кстати, советую ознакомитья и с такой статистикой: http://www.indeed.com/jobtrends?q=Java%2C+C%23%2C+C%2B%2B&l=

← →
Городской Шаман (2008-12-14 17:00) [29]

> Alkid (14.12.08 09:37) [27]
>
> В чём основная сила С++? Она в эффективности. С++ оправдан
> там, где необходимость экономить ресурсы машины важнее,
> чем экономить время программиста. Там, где такого требования
> нет, разумнее писать на более высокоуровневых языках.

Ой не надо. Если использовать C++ с "магией" которая доступна через механизмы шаблонов и других хитростей, по типу создания объектов на стеке и перегрузке операторов то по эффективности он не уступает C#. Используя бесплатную GUI библиотеку wxWidgets разработка интерфейса будет отличатся от разработки на Delphi только тем что редактор форм не встроен в IDE. Но если купить более дорогую платную библиотеку QT(интеграция с VS) то разработка формочек не будет сложнее делфийской разработки. Забудьте ужасы MFC их нет уже как и использования MFC.

Так что разработка ПО на C++ (не чистого С, там цугванг по части простоты) с использованием Платных!!! средств нисколько не отличается от разработки на Delphi или C#. Только в них не вбухивается столько рекламы.

← →
Городской Шаман (2008-12-14 17:31) [30]

> Не надо думать, что я недооцениваю С++ или Delphi. Я очень
> много работал и на том и на другом и знаю их достоинства
> и недостатки. Сейчас, кстати, я программирую как раз на
> С++, но даже у нас в проекте имеется тенденция к увеличению
> доли .NET модулей по сравнению с C++-ными по мере развития
> продукта. Сейчас начинаем делать новоую версию, почти всё
> делаем на C#. Всё, что не можем на C# по техническим или
> историческим причинам - на С++.

Ну сейчас техника достигла такого уровня, что проблема памяти или эффективного использования процессора перед программистом вообще не стоит. Поэтому и увеличивается процент использования таких скриптовых как python или интерпретируемых из байт-кода языков как C#. Это видно по такому тренду:

http://www.indeed.com/jobtrends?q=python%2C+C%23%2C+php%2C+perl&l=

Ну а написать еще одну учетную программу даже на том же C# да так чтобы она тормозила на современном компьютере можно только специально. В некоторых программах заложена возможность к оптимизации в 100раз, но никому она не нужна, дешевле купить новый процессор и добавить еще два гига памяти на офисный компьютер.

← →
Alkid (2008-12-14 19:42) [31]

> Городской Шаман (14.12.08 17:00) [29]

Я не силён в разработке GUI, так что этот аспект меня не очень волнует. Я говорю о более фундаментальных вещах. В частности, в С++ явно не хватает:
1. Нормальной модульности. Это самый большой косяк С++. Система заголовочных файлов убога и порочна в самой своей сути. Количество глюков, накладок и банальных неудобств, возникающих из-за этого, неисчислимо.
2. Автоматического управления памятью.
3. Рефлексии.
И это только самое насущное! Кроме того, С++ сильно перегружен тяжким наследием С. Это всё делает язык излишне сложным, заставляя иногда бороться не с проблемой, а с инструментом. Эта сложность приводит иногда к курьёзам в самом стандарте. Например, данный код с точки зрения стандарта некорректен:
class Base { }; class Derived : public Base { }; struct SomeStruct { Derived a; }; SomeClass::Derived* p = &SomeStruct::a; SomeClass::Base* p1 = p; // Compilation Error!
Налицо явное нарушение принципа подстановки. Увы.

При этом язык предоставляет больше свободы в выборе стиля, чем Дельфи или C#. Я, например, не пишу чисто объектно-ориентированные программы, предпочитая функционально-объектный стиль.

> Ну сейчас техника достигла такого уровня, что проблема памяти
> или эффективного использования процессора перед программистом
> вообще не стоит.

Вот именно! Точнее она не стоит в большинстве приложений. И для таких приложений надо использовать те средства, которые не заставляют думать программиста о таких вещах. А ещё лучше - дают ему пусть и не эффективный по ресурсам, но мощный инструментарий. Собственно, что и говорить - Lisp аж в 1958-ом году придумали. Требовательные байтодробительные задачи никуда не денутся и для них С++ будет нужен и сейчас и потом. Если только что-нибудь получше не придумают.

← →
Городской Шаман (2008-12-14 20:09) [32]

> 2. Автоматического управления памятью.

По части 2 уже давно проблема решена "умными указателями" с подсчётом ссылок на объект. Это, конечно, не сборщик мусора, но проблему частично решает.

По части 3, для внедрения в С++ рефлексии есть библиотеки макросов, которые ее позволяют сгенерировать по классу. Конечно простому смерному понять как работает эта библиотека не дано, но вы тоже же в компилятор С# не лезете.

А вот 1 это да, неудобно, но решаемо.

В общем идеология C# - все включено в стоимость билета. Идеология C++ - вы платите только за то, что заказываете. Какая из них лучше не скажу. Под проект и на любителя.

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

Ну а Java, .Net, Perl, Python - это конечно хорошо что у VB так много конкурентов, для некоторых задач они будут оставатся всегда недостаточно эффективны по причине "все включено в стоимость билета".

Да тот же доунлоадер или messaging клиент на C#/Java проиграет С++/Delphi по ресурсоёмкости. Конечно когда это одна программа то разница не особо существенна, а если их 40, то это уже лишний гиг памяти. Хотя через 4-5 лет на новых компьютерах меньше 16 Гб памяти стоять не будет... Так что предсказывать наперёд не берусь.

← →
Alkid (2008-12-14 21:32) [33]

> Городской Шаман (14.12.08 20:09) [32]

Да, всё верно. Идеология языков разная. И именно по-этому в С++ для управления памятью надо городить смарт-поинтеры - надо давать пользователю самые низкоуровневые средства. Но именно идеология обуславливает то, что С++ постепенно оставляет позиции в мэнстриме. Его аскетичная идеология не вписывается в мэйнстрим, лозунг которого - "даёшь максимальную производительность программиста!". Кстати, по этой же причине С++ не отомрёт окончательно - в его "коронных" областях ему просто нет нормальной замены (Ну разве что D допилят до кондиции, хотя мне он противен чисто эстетически :)). Мэйнстрим "покупает" свои возможности именно за счёт щедрого расхода памяти и тактов на продвинутые фишки. У Пола Грэхэма есть занятное эссе на эту тему : http://paulgraham.com/hundred.html.

← →
Городской Шаман (2008-12-14 22:03) [34]

> Alkid (14.12.08 21:32) [33]

Это по большей части рекламная лапша. Кривую архитектуру никакая rtti или сбор мусора не спасёт. Кроме того недостатков от сборки мусора часто больше чем преимуществ, особенно заметно в Java так как там нет C#-вского using, есть глюкавый "деструктор" finalize. При разработке нормального фреймворка под комплекс задач все равно какой использовать язык. Все упирается в возможности компилятора и существующие библиотеки.

Хотя если нужно получить программиста за 24 дня на реальный проект, то здесь только C# или Java, так как этот программист хоть на AV не будет натыкаться. Ну и как-то этот проект потом даже будет работать. Так практикует EPAM - месяц самостоятельного обучения за "стипендию", месяц "помощи в проекте" и через два месяца уже вполне солидный программист среднего уровня (ну так они отчитаются перед заказчиками).

← →
Alkid (2008-12-14 22:55) [35]

> Городской Шаман (14.12.08 22:03) [34]

Видал я таких "солидных программистов среднего уровня". Навык программиста - это не знание языков, всё же :) И программист "за 24 дня" напишет абсолютную лажу на любом языке, если только над ним с дубиной не стоять. Там как раз будет та самая кривая архитекторуа, которую ни RTTI, ни GC не спасёт. :)

Вообщем, как и в любом конструктивноем споре о том, какой язык круче, дошли до того, что круче своей головы на плечах и опыта работы ничего нет :)

Замыкания для методов классов в C++. Как? Найти похожие ветки