Как перегрузить методы, чтобы получились аналоги get set из C#

@Lagilo · Регистрация: 17.04.2014

Студворк — интернет-сервис помощи студентам

Как можно перегрузить методы, что бы получился аналог get set из C#. Т.е. что то такое:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class A
{
 private:
       int count;
 public:
       int X
       {
           get { return x; }
       }
       A(){}
       ~A(){}
}
 
main()
{
     int y;
     A a();
     y = a.X;
}

P.S. знаю, что данный код не будет работать

@hoggy · 14.10.2015, 20:41

Сообщение от Fulcrum_013

А для программиста? Посчитайте количество потребных символов.

количество потребных символов от классических сеттеров/геттеров отличается
лишь наличием () в конце метода.

и это - не есть критерий удобства в данном случае.

удобнее то, что привычно и поддается системе.

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

все методы, которые что-то устанавливают, начинаются с Set/set
все методы, которые позволяют что-то узнать, начинаются с Get/get

современная ИДЕ позволяет сразу показать
весь список доступных методов по первым 3м буквам.

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

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

Сообщение от Fulcrum_013

Смнительно. __closure хранит два указателя - на данные и на код.
вызов ассемблируется на прямую.

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

C++
1
(obj->*method)(arg);

ваш __closure всего лишь синтаксический сарах.
ничего революционного он не делает.

Сообщение от Fulcrum_013

Дают повышение читабельности и скорости разработки алгоритма, плюс фактически задают таблицы RTTI

повышение читабельности дает продуманная нотация имен.
например, все сеттеры начинаются с буковок set
зоопарк имен никакой читабельности не улучшает.

каким боком вы приплели RTTI вообще не понятно.

Сообщение от Fulcrum_013

А они никуда не деваются. Просто переезжают в protected

не понял.
вы ж не хотите мне сказать, что раньше я писал только сеттеры/геттеры,
а теперь мне придется писать и сеттеры/геттеры, и проперти?
причем сеттеры/геттеры за каким то фигом заталкивать в протестед?

Сообщение от Fulcrum_013

То что у них под капотом это и ежу понятно. Но все таки гораздо читабельней
Obj.Value++;
чем
Obj.SetValue(Obj.GetValue()+1);

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

C++
1
Obj.SetValue(Obj.GetValue()+1);

соотвествует

C++
1
++Obj.Value;

я в таких случаях использую:

C++
1
Obj.AddValue(1);

Сообщение от Fulcrum_013

Рефлексия - от слова отражение. т.е получение списка полей и методов объектов в рантайме. Именно это и делает борландовская система RTTI. восспринимайте просто "информацию о типе" шире чем classid

приведите пример:
как получить список функций-членов и данных-членов любого произвольного класса.

Сообщение от Fulcrum_013

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

ну-ну.

std::function полностью реализован средствами самого языка.
по сравнению с его возможностями,
ваш костыль __closure - жалкий огрызок.

вы как то очень легко противоречите реальности.

Сообщение от Fulcrum_013

Но не понятно что они еще пытаются выжать из такого вспомогательного средства как шаблоны.

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

Сообщение от Fulcrum_013

То как потом сделать вот так

никак.

дело здесь не в левостоящем делегате.
просто на плюсах нет такого синтаксиса:

C++
1
2
3
4
5
6
7
8
9
struct some
{
    void foo() {}
};
 
int main()
{
    some.foo; //<---  error: expected unqualified-id before ‘.’ token
}

@Fulcrum_013 · 14.10.2015, 21:02

Сообщение от hoggy

ваш костыль __closure - жалкий огрызок.

Который гораздо удобнее и позволяет не иметь пенальти в рантайме.

Сообщение от hoggy

технология шаблонов позволяет не иметь пенальти в рантайме.
неудиветельно, что на её развитие и сделанна ставка.

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

Сообщение от hoggy

ничего революционного он не делает.

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

Добавлено через 5 минут

Сообщение от hoggy

соотвествует

Разница будет только если использовать в более сложном выражении.

Сообщение от hoggy

я в таких случаях использую:

Это может и хорошо, пока для типов свойств нет перегруженных операторов, а сами свойства не участвуют в сложных математических выражениях

@hoggy · 14.10.2015, 21:06

Сообщение от Fulcrum_013

Который гораздо удобнее и позволяет не иметь пенальти в рантайме.

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

Сообщение от Fulcrum_013

и делает что оверхед

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

поэтому, шаблоны отлично inline.

приведите пример оверхеда.

оверхед рантайм-решения добавляют.
на то оно и рантайм, что выполняется в рантайме.

Сообщение от Fulcrum_013

и нечитабельность

тысячи программистов начиная от самых маленьких спокойно пользуются std::vector,
и не испытывают проблем.

а ну да, вы ж вроде бы STL не осилили.

ну понятно, откуда ноги растут.

Сообщение от Fulcrum_013

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

судя по вашему описанию,
он целиком и полностью повторяет поведение указателей на функции-члены.

Добавлено через 57 секунд

Сообщение от Fulcrum_013

Это может и хорошо, пока для типов свойств нет перегруженных операторов, а сами свойства не участвуют в сложных математических выражениях

не понял эту фразу.

@Fulcrum_013 · 14.10.2015, 21:06

Сообщение от hoggy

никак.

Вот в том и преимущество __closure, которое в эпоху событийного управления становится подавляющим. Поэтому std::function жалкий огрызок.

@hoggy · 14.10.2015, 21:09

Сообщение от Fulcrum_013

Вот в том и преимущество __closure, которое в эпоху событийного управления становится подавляющим.

это что то из области ваших фантазий?

Сообщение от Fulcrum_013

Поэтому std::function жалкий огрызок.

нет никаких "поэтому".

потому что из того факта, что язык не поддерживает синтаксис: obj.method
никак не следует ущербная функциональность std::function.
он умеет все, что может ваш кастрат,
плюс ещё многое полезное, чего ваш кастрат не умеет.

@Fulcrum_013 · 14.10.2015, 21:15

Сообщение от hoggy

он целиком и полностью повторяет поведение указателей на функции-члены.

С той разнице что работает и для заранее неизвестных вызывающему объектов

Добавлено через 3 минуты

Сообщение от hoggy

потому что из того факта, что язык не поддерживает синтаксис: obj.method

В нормальных компиляторах по этому поводу возникает неоднозначность "member function must be called or it address must be taken" Смотрите внимательно, там перед точкой объявленный объект а не тип класса. Но если результат выражения присваивается __closure то такой неоднозначности не возникает.

Добавлено через 1 минуту

Сообщение от hoggy

это что то из области ваших фантазий?

Это из области переназначения событий.

@castaway · 14.10.2015, 21:20

Fulcrum_013, да чего ты так привязался к этому __closure? Разве в языке есть такие задачи, которые нельзя решить без этого расширения твоего компилятора?

@Fulcrum_013 · 14.10.2015, 21:21

Сообщение от hoggy

он умеет все,

кроме нормального присваивания ему значения. Обшаблоненный костыль и не более.

Сообщение от hoggy

плюс ещё многое

Того что никому не надо + оверхед

Добавлено через 46 секунд

Сообщение от castaway

Разве в языке есть такие задачи, которые нельзя решить без этого расширения твоего компилятора?

Очень многие задачи встречающиеся на каждом шагу упрощаются. Али майрософт не по этой причине ввела аналогичное расширение delegate?

@castaway · 14.10.2015, 21:32

Сообщение от Fulcrum_013

Очень многие задачи встречающиеся на каждом шагу упрощаются. Али майрософт не по этой причине ввела аналогичное расширение delegate?

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

@Fulcrum_013 · 14.10.2015, 21:45

Сообщение от castaway

Просто предложенный тобою вариант не универсален, т.к. не соответствует стандарту, а ты преподносишь его как универсальное решение.

Человек как понимаю на MSVC++ пишет. Соответственно __property там есть.

Сообщение от castaway

Хочешь похвалить компилятор

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

Добавлено через 7 минут
Потому что те же property у всех как бы есть(С++ Builder, MSVC++, Intel C++), но вообще то их не существует

@castaway · 14.10.2015, 21:49

Сообщение от Fulcrum_013

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

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

@Fulcrum_013 · 14.10.2015, 22:23

Сообщение от castaway

Но ведь и там не дураки сидят. У них каждое решение тщательно взвешено.

В Borland и Microsoft то же не дураки. и решения эти прижились уже 20 лет. В плане COM к примеру без property вообще никак, потому их майкрософт и приделал, хотя и кривые.
Просто как понял идея комитета исходила от Dinkumware потому как по другому у них со сбытом начало не получаться, в следствие того что расширения синтаксиса эффективнее шаблономазни. Такой комитет только тормозит развитие и стандартизацию языка.
тот же smartptr реализуется средствами компилятора еще лучше и надежнее. достаточно только добавить для указателей модификатор local. Хотя действительно может просто быть редко пользуемым. Потому что примеры которые объясняют зачем нужен std::smart_ptr - ну вообще рассчитаны на криворуких идиотов пишущих хелловверды а не объектно-ориентированные библиотеки.

@castaway · 14.10.2015, 22:32

Сообщение от Fulcrum_013

В Borland и Microsoft то же не дураки.

Тогда почему они никак не влияют/способствуют развитию языка?

Сообщение от Fulcrum_013

В плане COM ...

Разве это не устаревшая технология?

Fulcrum_013, почему ты не член комитета? И почему ты до сих пор пользуешься этим языком?

@Fulcrum_013 · 14.10.2015, 22:46

Сообщение от castaway

Тогда почему они никак не влияют/способствуют развитию языка?

Плевать они хотели на такой комитет. Вносят потребные под свои нужды расширения и никого не спрашивают. Не нравится - пиши на коммитетовском диалекте и не пользуй фрэймверк.

Сообщение от castaway

почему ты не член комитета?

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

Сообщение от castaway

И почему ты до сих пор пользуешься этим языком?

Потому что есть отличная штука называющаяся С++ Builder и фирма Borland/Embarcodero которой на комитет плевать, поделку Dinkumware на борт положили, но пользовать ее не обязаны. Начнем с того что я начал пользоваться этим языком еще до того как stl и комитет появились. Не менять же привычки к хорошей вещи из-за сборища нечистых на руку дельцов?

Сообщение от castaway

Разве это не устаревшая технология?

Есть COM+. Да и любая технология динамического импорта классов из dll будет подобной.

Возникает другой интересный вопрос, почему и майкрософт и борланд изобретают свои шаблонные велосипеды вместо к примеру std::vector если в std::vector все так взвешенно и продуманно?

@hoggy · 14.10.2015, 23:20

Сообщение от Fulcrum_013

С той разнице что работает и для заранее неизвестных вызывающему объектов

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

Сообщение от Fulcrum_013

В нормальных компиляторах по этому поводу возникает неоднозначность "member function must be called or it address must be taken"

есть только один критерий "нормальности" компилятора - насколько он соответствует стандарту.
все остальное - не портируемое,
а значит имеет незначительную область применения.

Сообщение от Fulcrum_013

Это из области переназначения событий.

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

так что это не более, чем ваши фантазии.

Сообщение от Fulcrum_013

кроме нормального присваивания ему значения. Обшаблоненный костыль и не более.

это не поддерживает язык, а не механизм.
неужели так трудно понять?

Сообщение от Fulcrum_013

Того что никому не надо + оверхед

голословное бла бла бла

бинд аргументов - более чем востребованная фича.

а по поводу оверхеда - вы сначала проверьте, потом вякайте.

объясняешь человеку: шаблон inline во все поля.
нет, человек тупит. у человека оверхед в сферическом вакууме.

Сообщение от Fulcrum_013

delegate?

ничо, что это расширение не доступно для нативного с++?
https://msdn.microsoft.com/ru-... 55798.aspx

@Fulcrum_013 · 15.10.2015, 02:06

Сообщение от castaway

Например, что мешает им реализовать это?

Для того чтобы от этого был профит необходимо гарантировать выполнение потоков на разных конвейерах, иначе просто будет оверхед по тасксвитичнгу. Хоть одна ось предоставляет возможность управлять тем на каком конвейере будет выполняться поток? Если и есть то библиотека станет ОС-зависимой. А если это не грантировать, то при повышении приоритета потоков будем натыкаться на оверхед чем выше приоритет тем сильнее. На низком/стандартном приоритете прирост от распараллеивания реально происходит от получения процессом большего количества квантов времени, что точно так же делается поднятием приоритета. Вообще если понимаешь как потоки устроены то трижды подумаешь перед тем как запустить еще один поток, если конечно не на CUDA программируешь.

Добавлено через 45 секунд

Сообщение от hoggy

ничо, что это расширение не доступно для нативного с++?

Ну значит с нативным неосилили

Добавлено через 6 минут

Сообщение от hoggy

объясняешь человеку: шаблон inline во все поля.
нет, человек тупит. у человека оверхед в сферическом вакууме.

Сообщение от hoggy

насколько он соответствует стандарту.

Есть только один критерий "нормальности" стандарта - насколько он соответствует потребностям.

Сообщение от hoggy

это не поддерживает язык, а не механизм.
неужели так трудно понять?

А вот за это комитет надо расстрелять вместе со всеми родственниками до 10-го колена.
Потому как механизм такой вкусности есть уже как минимум 20 лет, а в стандарте ее нет.

Сообщение от hoggy

бинд аргументов - более чем востребованная фича.

А типа указатель аж на целый объект в комплекте это не бинд кучи аргументов сразу?

Добавлено через 9 минут

Сообщение от hoggy

нет, человек тупит. у человека оверхед в сферическом вакууме.

С вызовом нету?
Неужели std::function будет быстрее чем

Assembler
1
2
mov eax, [Ptr+4]
call [Ptr]

Добавлено через 7 минут

Сообщение от hoggy

все остальное - не портируемое,
а значит имеет незначительную область применения

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

Добавлено через 36 минут

Сообщение от hoggy

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

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

Без closure событийная модель с объектами реализовывается либо через сообщения с тормознутой деспетчеризацией, либо через кучу костылей, третьего не дано.

А без рефлекшина... ну если конечно у тебя набор взаимосвязей определен в компайл-тайме то можно и без рефлекшина. Но в большинстве задач эти взаимосвязи end-user мышкой клоц-клоц. Событие это такое же свойство, которые редактировать очень часто надо в рантайме. Не пилить же под каждую мелочь отдельную форму если на 99% с пилением формы и алгоритм в рантайме справляется по данным рефлекшина?

Добавлено через 24 минуты

Сообщение от hoggy

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

Что программисту и надо, а не сношать мозги с костылями-обертками типа std::function, функторами, лямбдами и прочим бредом.

Добавлено через 1 час 12 минут

Сообщение от hoggy

так что это не более, чем ваши фантазии.

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

Но 20 лет назад они добавили __closure и сделали абсолютно все на нем. Не догадываешься почему?

@hoggy · 16.10.2015, 22:15

Сообщение от Fulcrum_013

Есть только один критерий "нормальности" стандарта - насколько он соответствует потребностям.

в контекте дегатов - удовлетворяет более, чем ваш кастрат.
потому что std::function умееет все тоже, плюс ещё многное.

Сообщение от Fulcrum_013

А вот за это комитет надо расстрелять вместе со всеми родственниками до 10-го колена.
Потому как механизм такой вкусности есть уже как минимум 20 лет, а в стандарте ее нет.

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

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

однако это никак не согласуется с его дизайном.

смотрите:

C++
1
callback = some.method; //<--- callback() эквивалентно some.method()

ну и как в таком дизайне может выглядеть бинд?

C++
1
callback = some.method(10); //<--- в правой части вызов метода

сырые указатели на функцию-член востребованны в инструментальных механизмах общего назначения.
делегат для них будет слишком не эффективно.

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

в результате имеем полнофункциональный,
гибкий, мощный std::function,
а не кастрированный делегат,
который не умеет ничего,
кроме нацеливания.

Сообщение от Fulcrum_013

А типа указатель аж на целый объект в комплекте это не бинд кучи аргументов сразу?

сам по себе вопрос даёт мне понять,
что вы вообще не осознаете область применения.

представьте себе задачу:

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

std::function жрет подобное тривиально.
ваш кастрат такое не умеет в принципе.
как вы будите запоминать аргументы,
с которыми нужно когда то в будущем позвать функцию?

а это - очень распространенный кейс.

Сообщение от Fulcrum_013

Неужели std::function будет быстрее чем

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

ещё раз, специально для тупеньких - шаблоны inline.

без биндов std::function разворачивается точно так же,
как и ваш кастрат, который в принципе не умеет бинды.

Сообщение от Fulcrum_013

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

бла бла бла.

я вообще то кросс-платформенный.
я как бе не вчера замужем.

Сообщение от Fulcrum_013

Без closure событийная модель с объектами реализовывается либо через сообщения с тормознутой деспетчеризацией, либо через кучу костылей, третьего не дано.

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

для реализации такой системы мне не понадобилось ни тормознутое RTTI,
ни указатели на функции-члены,
ни делегаты.

я что-то сделал не так?

просто вы несете херь.

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

как новобранец.

я подозреваю,что вы остановились в развитии 20 лет назад.

Сообщение от Fulcrum_013

Что программисту и надо, а не сношать мозги с костылями-обертками типа std::function, функторами, лямбдами и прочим бредом.

бред.
за программиста и будут сношаццо std::function, функторы, лямбды

Сообщение от Fulcrum_013

Не догадываешься почему?

и после этого у них по прежнему была:

Сообщение от Fulcrum_013

система событийного управления основанная исключительно на сообщениях с диспетчеризацией

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

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

@Voivoid · 16.10.2015, 22:21

Сообщение от hoggy

в простых случаях там прямые вызовы.
то есть нет затрат на рантайм-полиморфизм.

В std::function type erasure, а значит оверхед на виртуальный вызов.

А вообще твою бы энергию, да в мирное русло

@Fulcrum_013 · 16.10.2015, 23:26

Сообщение от hoggy

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

Это тупо. Потому что получаются костыли причем ужасно кривые, неудобные и неполноценные.

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

Сообщение от hoggy

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

Вместе с __closure Борланд добавили на борт и поделку Dinkumware. Но предпочли добавить __closure а не пользовать std::function. Не догадываетесь почему?
А подход без STL смутные времена - тупой бред. Потому что любую библиотеку с открытым кодом можно скомпилировать на другом компиляторе, какой бы нестандартной она ни была, если расширения компилятора одинаковые. Поэтому стандартизировать надо расширения компилятора а не никчемную библиотеку.
Они и сейчас свои решения закладывают. К примеру майкрософт во всю пользует CGrowableArray а борланд TDynArray вместо std:vector. Никто не сможет обязать их пользовать в своих фрэймверках кривые поделки Dinkumware. Могут только обязать иметь их в комплекте.

Добавлено через 9 минут

Сообщение от hoggy

и после этого у них по прежнему была:

До этого система событийного управления работала на отпракве сообщений от одного объекта в другой через общую очередь сообщений.
А 20 лет назад переделали на фактически калбэки между объектами. А деспетчиризация используется только для обработки сообщений из очереди сообщений оси. Кстати и ось далеко не все передает через сообщения. Очень много идет через каллбэки.

Добавлено через 11 минут

Сообщение от hoggy

за программиста и будут сношаццо std::function, функторы, лямбды

напиши короче и понятнее присваивание события чем
TEvent a=b.OnEvent;
c использованием std::function, а потом уже рассказывай какая она универсальная и хорошая.

Добавлено через 4 минуты

Сообщение от hoggy

что вы понятия не имеете о возможностях языка.
как новобранец.

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

Добавлено через 7 минут

Сообщение от hoggy

как и ваш кастрат, который в принципе не умеет бинды.

Кастраты - это те кто проектирует иерархию так, что в последствии нужны бинды. У них мозги кастрированы.

Добавлено через 2 минуты

Сообщение от hoggy

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

Если есть мозги, то каждая задача оформляется в виде класса.

Добавлено через 2 минуты

Сообщение от hoggy

в рантайме вообще никаких пенальти.

Сообщение от hoggy

я что-то сделал не так?

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

Добавлено через 19 минут

Сообщение от hoggy

я вообще то кросс-платформенный.
я как бе не вчера замужем.

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

@hoggy · 16.10.2015, 23:29

Сообщение от Voivoid

В std::function type erasure, а значит оверхед на виртуальный вызов.

так бы сделали вы, или я.

но не стандартная тема.
оно эксплуатирует нативные расширения компилятора по полной.
причем "не документированные".

я смотрел под микроскопом вижал-студийную версию.

там используются вещи, о которых я в документациях и не подозревал.
и не единого виртуального вызова.

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

Добавлено через 1 минуту

Сообщение от Fulcrum_013

и __closure и __property и reflection без расширений компилятора в полном объеме не реализуются

я вам предложил представить пример рантайм-рефлексии.

если вы его не предоставите - ищите другого собеседника.
мне балаболки не интересны.

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .

@castaway 4986 / 3093 / 456 Регистрация: 10.11.2010 Сообщений: 11,170 Записей в блоге: 10
	14.10.2015, 21:20
	Fulcrum_013, да чего ты так привязался к этому __closure? Разве в языке есть такие задачи, которые нельзя решить без этого расширения твоего компилятора? 0