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

E>Если этот пункт статический (не появляется в произвольный момент), то в одном -- там где меню формируется.
E>Или ты имел в виду и обработчик события так же? Если с обработчиком события -- то в двух, естественно.

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

К тому же ты явно захардкодил свое меню. Все! Приплыли! Дальше ты его будешь менять лазия по исходникам. Тут же определяется обработчик и все необходимые атрибуты. А уж меню и тулбары задаются декларативно в отдельных ХМЛ-ях. И их можно конфигурировать в рантайме!

Если ты не ощущашь разницу между этими подходами, то действительно объяснять что либо просто бессмысленно.

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


E>Так как же в C# сделать делегат, который должен вызывать нестатический метод объекта, но при этом не связан с конкретным объектом?

А зачем?

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

E>Мне интересно, возможно ли с делегатами C# то, что выделено жирным? И если не возможно, то как тогда твое возражение понимать?

Ты пример приведи где я делегатами не смогу реализовать твои изыски. Пойми, это просто более универсальная и гибкая сущьность.

А привязан, не привязан это все пустые рассуждения. Если метод экземплярный, то и вызвать его прийдется у экземпляра. Чудес не бывает. Требовать никому не нужные вещи бессмысленно.

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

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

VD>> нужна возможность вызвать метод у объекта тип которого не важен для вызывающей стороны. В общем получился уродец единственно существенное применение которого стала эмуляция делегатов. При этом получается целая гора кода которую не только долго компилировать, но еще и чертовски сделать универсальной (компилирующейся на разных компиляторах). На сегодня появились реализации вроде boost::bind, но это только сеогодня и компилируются они только на правильных компиляторах.

ПК>1) Все, кому было надо, имели свои варианты boost::bind уже давным-давно. В простом виде это было сделано в незапамятные времена в виде std::bind1st и std::bind2nd. Кому надо -- обобщали.

Ага. Я был одним из них. Было только три проблемы:
1. На моем VC6 получилось не очень типобезопасно. Ну, да тут можно сказать у меня умений не хватило. Ну, тупой я. Такую простую вещь не могу сделать.
2. Компиляция проектов занимала 25 минут. Внес изменение в общий хэадр и приплыли.
3. Решение это жило в глубинах С++-ного кода и я никак не мог использовать его между модулями соеденяемыми по средством КОМ-а. Ну, не компонентное решение все эти шаблоны.

ПК>2) По поводу "правильных компиляторов": если посмотреть на результаты тестов, то можно увидеть, что bind в объеме делегатов C# работает на всех известных компиляторах.

Что-то даже по этой ссылке не очень то на всех.

ПК>Собственно, в том же C# уже потихоньку появляются те же проблемы с совместимостью разных версий компиляторов: часть новых возможностей доступна только в новом компиляторе, у пользователей старых версий компилятора этих возможностей нет. Это совершенно естественное явление, сопутствующее развитию языка при наличии пользователей предыдущих версий.

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

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

E>У C++, к счастью, есть компиляторы и кроме Visual C++.
E>Кстати, официального релиза generic-ов в Java и C# разработчикам пришлось ждать и после наступления XXI века.

А долго в каком веке был создан C#? Если ты забыл, то я напомню. C# появился на свет в 2002 году. Так что это функционального типа с кучей ограничений пришлось здать 20 лет. А дженериков пришлось ждать 3 года. И не нужно приплетать сюда красивые даты вроде веков.

E>А ты бы смог сделать делегаты, создавая компилятор C#?

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

E>Я это к тому, что всем должны заниматься профессионалы в своей области. Ведь boost в C++ пишут очень продвинутые люди.

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

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

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

C>В С++ были шаблоны еще в 80-х годах, как раз на 4-5 году жизни.

В 90-ых скорее. Да и делать вещи подобные boost::bind на них точно было нельзя. Их еле еле стало можно делать в конце девяностых. Так что можно смело говорить о том, что 10 лет приходилось сосать лапу.

C> И в
C>отличие от С#/Java у Страуструпа не было перед глазами примера
C>промышленного языка, в котором уже реализован механизм шаблонов (разве
C>что генерик-модули в Аде). Все шишки комитет С++ набивал самостоятельно.

Сейчас у него перед глазами есть и С++, и Ада, и Шарп с Явой, и черт лысый. Но выводов он делать не торопится и выводы все какие-то странные.

C>boost.function+boost.bind, для мультикаста — boost.signals. Что еще вам
C>надо?

Блин, примитивного указателя на методы который не был бы ограничен методами одного класса, а инициализировался бы любыми методами с совпадающей сигнатурой. Это же так просто! Ни языка, ни концепций эта вещь не нарушит. Об этом Страуструпу долдонили целых 10 лет. Но у него свой путь.

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

C>В чем отличия boost.bind+boost.function от делегата?

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

C>А зачем? Или вы будете ждать утверждения стандарта ISO на C# 2.0, прежде
C>чем начать использовать его?

C# 1.0 уже ISO-стандарт. Делегаты были уже в нем. Да и используя даже не стандартизированный C# 2.0 я уверен, что никому и в голову не прийдет написать свой велосипед на тему делегата, а на С++ это в норме вещей. И это главное.

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

C>Я предпочитаю ISO — так как они работают по своим же стандартам качества
C>(в отличие от ECMA).

А ничего что ISO принимает на рассмотрение стандарты любых стран? Тот же Шарп стал ISO с подачи ECMA.

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

ПК>В данном случае: для C++ есть только ISO стандарт. Соответственно, ответ на этот вопрос получается в первых же результатах любого запроса в Google, содержащего слова "C++" и "Standard". А если искать именно по поводу вопроса "есть ли ISO стандарт для C++", т.е. включив слово "ISO" в запрос, то ссылки на ISO стандарт будут в каждом из результатов, по крайней мере, на первой странице.

Ну, вот и поискал бы. ISO, как я понимаю, стандарты прорабатывает и принимает. А подают их как раз разные ECMA, ANSI и т.п. Вот что удалось найти буквально с ходу:
http://www.informit.com/articles/article.asp?p=170770&rl=1

Back in 1998, ANSI released its official standard for the C++ programming language.

NOTE

Note: Actually, it's ISO that released the standard. Officially, it ratified an ANSI standard that had been approved a year earlier, in 1997. The current standard is therefore an ANSI/ISO standard or simply an ISO standard.

ПК>Мне факт задания вопроса в форум вместо единственного запроса к Google показался удивительным и смешным

Ничего смешного если человек не фанатствует до посинения. Я вот о том, что C# ISO-стандарт узнал на этом форуме. Можешь тоже посмеяться.

VladD2,

> ISO, как я понимаю, стандарты прорабатывает и принимает. А подают их как раз разные ECMA, ANSI и т.п.

Это хорошее замечание, но применительно к C++, в составе ISO существует соответствующая рабочая группа (JTC 1/SC 22/WG 21), что и определяет требования к процессу по работе над стандартом C++.

VladD2,

> C>Я предпочитаю ISO — так как они работают по своим же стандартам качества (в отличие от ECMA).

> А ничего что ISO принимает на рассмотрение стандарты любых стран? Тот же Шарп стал ISO с подачи ECMA.

Не совсем так. C# принят по так называемому fast track процессу, который к процессу выработки стандарта требований не предъявляет. Разница описана здесь: http://www.iso.org/iso/en/stdsdevelopment/whowhenhow/proc/deliverables/iso_stan.html

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

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

E>>Мне интересно, возможно ли с делегатами C# то, что выделено жирным? И если не возможно, то как тогда твое возражение понимать?

VD>Ты пример приведи где я делегатами не смогу реализовать твои изыски. Пойми, это просто более универсальная и гибкая сущьность.

VD>А привязан, не привязан это все пустые рассуждения. Если метод экземплярный, то и вызвать его прийдется у экземпляра. Чудес не бывает. Требовать никому не нужные вещи бессмысленно.

Это достаточно грубая и неумелая попытка уйти от конкретного вопроса.

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

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

E>>У C++, к счастью, есть компиляторы и кроме Visual C++.
E>>Кстати, официального релиза generic-ов в Java и C# разработчикам пришлось ждать и после наступления XXI века.

VD>А долго в каком веке был создан C#? Если ты забыл, то я напомню. C# появился на свет в 2002 году. Так что это функционального типа с кучей ограничений пришлось здать 20 лет. А дженериков пришлось ждать 3 года. И не нужно приплетать сюда красивые даты вроде веков.

Все претензии к Sinclair (Re[17]: Has C# lost its point?

Автор: Sinclair
Дата: 28.06.05

):

V>В общем, Страуструп просто напросто не стал ограничивать возможности разработчика автоматически "за кулисами" генеренным классом.
Да-да. Поэтому разработчики, так классно неограниченные Страуструпом, должны были сначала дождаться введения шаблонов в С++, а потом сидеть и куковать до XXI века, пока компиляторы не научились делать частичную специализацию. В каком году вышел VC++ 7.0? Предыдущую версию компилятора ты небрежно оставил за бортом.

E>>Я это к тому, что всем должны заниматься профессионалы в своей области. Ведь boost в C++ пишут очень продвинутые люди.

VD>И почему проффесионалы в области программирования занимаются работой компиляторо-строителей и дизайнеров языков? Почему нужно было ждать 20 лет пока прийдут эти самородки и наежжут тех кто делал компиляторы их же компилятором? Что мешало сделать аналог сигнала или бинда еще в 85-ом?

VD>Так вот я тебе скажу. Сначала это была ошибка дизайнера языка. А теперь неумение ее признать и гордыня.

Так вот я тебе скажу, что созданный на основе опыта Ada (где уже были generic-и), C++ (с шаблонами) и Java (с виртуальной машиной и рефлекшеном) C# даже не получил generic-ов в первой версии, этого пришлось ждать еще 3 года. Хотя их можно было бы тупо скопировать. А вот были ли в 85-ом году концепции делегатов в том виде, в котором они тебе нравятся -- это еще бООльшой вопрос.

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

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

E>>Если этот пункт статический (не появляется в произвольный момент), то в одном -- там где меню формируется.
E>>Или ты имел в виду и обработчик события так же? Если с обработчиком события -- то в двух, естественно.

VD>Как же в одном, если тебе нужно создать метод обработчик в одном месте и добавить пункт меню совсем в другм. Причем во втором месте тебе прийдется сослаться на обработчкик чтобы подключить его к менюхе.

VD>К тому же ты явно захардкодил свое меню. Все! Приплыли! Дальше ты его будешь менять лазия по исходникам. Тут же определяется обработчик и все необходимые атрибуты. А уж меню и тулбары задаются декларативно в отдельных ХМЛ-ях. И их можно конфигурировать в рантайме!

VD>Если ты не ощущашь разницу между этими подходами, то действительно объяснять что либо просто бессмысленно.

Влад, по моему, ты слегка не в теме. С AndrewVK мы, имхо, прекрасно друг друга поняли.

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

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

E>>Имхо, суть указателя на метод именно в том, что это указатель на метод. Который можно применить к любому объекту этого типа (и к любому объекту производного типа).

VD>Ага. А по жизни требуется применять его к любому объекту любого типа у которого есть метод с нужной сигнатурой.

Ага. Предположим у тебя есть объект типа TextFormatter и объект типа DiskFormatter. У обоих есть метод void format(). Захотел бы ты получить делегат, который вызывает метод format у неизвестно какого объекта? Прямо как русская рулетка -- либо текст отфоматирует, либо диск, на котором этот текст должен лежать.

Но даже для таких извращенцев в C++ есть способы получить удовольствие:

class format_method_t
    {
    public :
        virtual void operator()() const = 0;
    };
    
template< class Object >
class format_method_binder_t : public format_method_t
    {
        typedef void (Object::*method_t)();
        
        Object * object_;
        method_t method_;
        
    public :
        format_method_binder_t( Object * o, method_t method ) : object_( o ), method_( method ) {}
        
        virtual void operator()() const { (object->*method_)(); }
    };
    
void call_format_on_something( format_method_t & method ) { method(); }

void do_something_stupid()
    {
        text_formatter_t my_text( "april_thesises.doc" );
        disc_formatter_t my_disck( "C" );
        
        call_format_on_something( format_method_binder_t< text_formatter_t >( &my_text, &text_formatter_t::format ) );
        call_format_on_something( format_method_binder_t< disk_formatter_t >( &my_disk, &disk_formatter_t::format ) );
    }

E>> Делегат же, насколько я понял из твоих объяснений, это тот же указатель, который намертво связан с конкретным объектом. Поэтому применить делегат к другому объекту этого же типа уже не реально (правильно?).

VD>Делегат — это ссылочный тип. Переменная типа делегат может указывать на любыее методы любых объектов. Так что функционально ты ничем не связан. Делегат же можно рассматривать как указатель на метод. Причем не только на метод эеземпляра. Он точно так же может указывать и на статический метод.

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

E>>И спрашивается: какой подход является более общим?

VD>Тот с который позволяет решить большее количество задач большим количеством способов.

Это точно.

VD> То есть делегат.

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

E>> Имхо, C++ный.

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

Я использую. И я приводил примеры тебе и AndrewVK.

E>> Т.к. функциональность делегата (указатель на метод + указатель на объект) мы можем очень просто сделать.

VD>Языком если только. Не уверен, что лично ты справишся если не заглядывал в тот же сигнал.

См. выше.

E>> И при этом имеем возможность работать с указателями на методы, не привязанными к конкретным объектам (где-то я такое использовал, при острой необходимости могу поискать). А вот от делегата таких возможностей мы вряд ли дождемся.

VD>Забавно. Ты только что смотрел пример где не только динамически привязывался экземпляр объекта, но и динамически же привязывался метод. Хрена два ты такое на современном С++ сделашь. Но тем не менее пыташся делать выводы об ущербности делегатов.

No comments.

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

E>>Это как же указатели на методы пасуют?

VD>Так же. Не позволяют ссылаться на метод по сигнатуре тем самым ограничивая тебя экземплярами одного объекта.

См. выше. В классе format_method_binder_t легко сделать замену как указателя на объект, так и указателя на метод.

E>>Влад, я уже давно не программировал на WinAPI, но даже в низопамятные времена получать в обработчик сообщения голый Message, а затем извлекать из wParam, lParam нужные значения было каменным веком. Даже если не брать обработчиков сообщений в MFC, то были замечательные макросы из windowsx.h. Поэтому приведенный здесь фрагмент может быть и выглядит красивым с точки зрения использования атрибутов .Net, но я бы хотел работать с обработчиками сообщений вида:
E>>

E>>void    OnLButtonDown(HWND hwnd, BOOL fDoubleClick, int x, int y, UINT keyFlags);
E>>void    OnRButtonDown(HWND hwnd, BOOL fDoubleClick, int x, int y, UINT keyFlags);
E>>void    OnMouseMove(HWND hwnd, int x, int y, UINT keyFlags);
E>>

E>>и т.д.

VD>Причем тут сигнатуры? Елы-палы, ну, ты вдумывайся в слова то.

Это я тебе хочу сказать: читай то, что тебе отвечают опоненты.

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

А я сказал, что если это декларативное программирование добавляет мне лишние неудобства -- по пусть оно идет лесом. Лично мне, когда я стал использовать макросы из windowsx.h программировать стало проще. И более того, избавило от проблем при переходе на 32-х битовый Windows, когда упаковка параметров в некоторых сообщениях изменилась. А приведенный код мне не понравился тем, что из-за декларативности все обработчики оконных событий имели одинаковую сигнатуру, хотя давно было доказано, что это неудобно.

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

E>> На первый взгляд, может быть.

VD>И на 255-ый тоже. Если конечно не придумывать пробем специально.

Проблемы не придумывают специально. Специально на них не обращают внимания.

E>> Поэтому я вполне в состоянии эту информацию предоставить сам.

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

Я тебе могу сразу сказать результат. Решение на плюсах будет объемнее. Поскольку вручную придется делать то, что в C# уже сделано.
Но я пытаюсь объяснить тебе простую вещь, основанную на опыте: любое удачное решение будет требовать развития. И во многих случаях оказывается, что доработка специализированного решения бывает проще, чем отказ от стандартного решения в пользу специализированного. Вот сейчас ты воспользовался возможностями C# и тебе их хватило. Но ты так и не ответил мне, что ты будешь делать, если в конфиге нужно будет указать имя CaretVirtualLineUp, а в программе, в зависимости от других настроек, нужно будет использовать другие имена. Не придется ли тебе тогда программу латать? Скажем делать CaretVirtualLineUp вот так:

void CaretVirtualLineUp()
    {
        if( _config.isWrappedMode() )
            CaretVirtualLineUpWrappedMode();
        else if( _config.isRestructedMode() )
            CaretVirtualLineUpRestructedMode();
        else
            CaretVirtualLineUpStandardMode();
    }

E>> Кроме того, вот что ты будешь делать, если тебе потребуется имя метода CaretVirtualLineUp переименовать? Будешь править все конфиги?

VD>Что? А если имя не так уникально? А, ну, не беда. Тода прийдется заменить его у метода (средствами рефакторинга), а потом ручками в ХМЛ-файле.

Ключевой момент! Круто будет выглядеть продукт, выход новой версии которой сопровождается необходимостью править конфиги просто из-за того, что разработчик продукта произвел рефакторинг!

E>>Влад, я что-то не понял, а почему XML вручную читается?

VD>Ну, уж не совсем вручную. Я не маньяк еще парсить ХМЛ руками.

Я же не про парсинг, а про чтение значений из XML. Мне так сразу статью про якобы кульный способ автоматической сериализации/десериализации C#-ких объектов. А себе что-то применить такой способ слабо оказалось? Это что, двойные стандарты или "сапожник без сапог"?

E>> А где же хваленая прозрачная XML сериализация? Где XSD, которая бы позволила проверять семантическую корректность?

VD>Схему подключить можно, но для данной задачи не очень то и нужно. А читаю вручню по совсем банальной причине. Не хочу тормозить загрузку компонента.
VD>Конечно можно было бы заменить их на использование TataSet или XPath, но игра не стоит свечь. Было бы на две строки меньше и в 10 раз медленее. Может оно и не было бы заметно на современных машинах, да и выполняется чтение всего один раз на загрузку, но так как разница всего две строки, я вибрал более быстрое решение. XmlReader — это очень быстро.

Она как оказывается! XML это еще и тормоза, о которых даже при небольших размерах конфига нужно думать. Да уж, доморощенные велосипеды нервно курят в сторонке.

E>>И что будет, если в атрибуте Key задать, например: "Control | Alt | Control | Alt | Control"?

VD>Будет булево или.

Это я и так понял. Мне интересно, такая запись по-твоему нормальна? То, что твой код ее проглотит еще не означает, что пользователю нужно разрешать так писать. Может он ошибся, а мы ему об этом ничего не скажем.

VD>Да что уж скромничать. Ты создай полный код делающий тоже что и мой. Вот тогда и сравним. А за одно предложим общественности сравнить понятность и простоту форматов.

Полный код класса KeyboadShortcatsMap делать, естественно, не буду. А вот парсинг конфига:

shortcat_t shortcat_extractor( const tag_shortcat_t & tag ) { return tag.query_value(); }
...
using namespace cls_2;

std::string error_desc;
tag_vector_of_tags_t< tag_shortcat_t > tag_shortcats;
std::list< shortcats_t > shortcats;

if( c_ok == std_cpp::parse_file( shortcat_file, tag, error_desc ) )
    // Парсинг прошел нормально, извлекаем значения.
    std::transform( tag_shortcats.begin(), tag_shortcats.end(),
            std::back_inserter( shortcats ),
            shortcat_extractor );
else
    std::cerr << "Ошибка разбора keyboard_shortcats_map.cfg: " << error_desc << std::endl;

E>> И поэтому не будет привязан ни к конкретным именам тегов, ни к конкретной реализации самого тега (например, можно прозрачным образом ввести псевдонимы для ctrl, alt, shift. Или даже сменить формат shortcat-а на такой:
E>>

E>>{shortcat
E>>        {key {ctrl}  "C"}
E>>        {key {ctrl}  "Insert"}
E>>    {action "Copy"}}
E>>{shortcat
E>>        {key {ctrl}  "V"}
E>>        {key {shift} "Insert"}
E>>    {action "Paste"}}
E>>{shortcat
E>>        {key {ctrl}  "X"}
E>>        {key {shift} "Delete"}
E>>    {action "Cut"}}
E>>

VD>Зачем?

Затем.
Чтобы нельзя было размазывать привязывание keymap-ов к одному action-у в разных концах конфига.

E>>Так что по объему мой велосипедный подход не сильно больше твоего, а вот в сопровождении, имхо, мой удобнее.

VD>А если его довести до работоспособности, то он будет намного больше.

Влад, здесь прослеживается попытка обвинить мой код в неработоспособности. Равно как и вот здесь: Re[5]: Что толку в Ада если Ариан 5 все равно упал

Автор: VladD2
Дата: 26.06.05

, когда ты усомнился, что в моем коде нет фрагментов, похожих на:

*((&array[0]) - 10) = 12345;

Если хочешь доказать неработоспособность чего-либо, то приводи примеры.

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

AVK>>Можно, но это лишний пустой код.

E>Но ты же сам несколькими постами выше говорил, что на современных процессорах это не играет никакой роли

А при чем тут процессор? Я о ручной работе.

E>Мне интересно, возможно ли с делегатами C# то, что выделено жирным?

Только для статических методов. Я о другом говорил — практически всегда существует решение, которому такой функционал не нужен.

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

ПК>Оценку "" ставлю, когда мне в результате прочтения сообщения смешно.

ПК>В данном случае: для C++ есть только ISO стандарт. Соответственно, ответ на этот вопрос получается в первых же результатах любого запроса в Google, содержащего слова "C++" и "Standard".

Ну и что? Смеяться где? Или ты считаешь что каждый программист обязан знать что на С++ стандарт выпущен именно ISO, а не ANSI к примеру?

ПК>Мне факт задания вопроса в форум вместо единственного запроса к Google показался удивительным и смешным

Понятно.

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

E>>Мне интересно, возможно ли с делегатами C# то, что выделено жирным?

AVK>Только для статических методов. Я о другом говорил — практически всегда существует решение, которому такой функционал не нужен.

Это уже, как говорится, второй вопрос.
Т.е., я был прав, говоря, что в C++ мы можем иметь указатель на нестатический метод без объекта, а в C# -- вряд ли.

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

E>Это уже, как говорится, второй вопрос.
E>Т.е., я был прав, говоря, что в C++ мы можем иметь указатель на нестатический метод без объекта, а в C# -- вряд ли.

Нет, не прав, поскольку ранее про нестатичность речи не было.

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

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

E>>Это уже, как говорится, второй вопрос.
E>>Т.е., я был прав, говоря, что в C++ мы можем иметь указатель на нестатический метод без объекта, а в C# -- вряд ли.

AVK>Нет, не прав, поскольку ранее про нестатичность речи не было.

Ok. 1:1
Пора