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

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

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

0

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

смотрите исходники билдеровского Object Inspector прекрасный пример рантайм-рефлекшина.

Сообщение от hoggy оно эксплуатирует нативные расширения компилятора по полной.

Ото ж то и оно

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

Сообщение от hoggy причем сеттеры/геттеры за каким то фигом заталкивать в протестед?

Это называется инкапсуляция.

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

Сообщение от hoggy шаблоны были ещё слишком не стандартизированны.

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

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

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

Смысл? Поиметь пенальти в виде невозможности переназначения обработчиков в рантайме? А разница в пенальти между direct call и indirect call насколько мизерна, если вообще существует на современных процах, что ни идет ни в какое сравнение с невозможностью переназначения.

0

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

Что-то у меня большие сомнения на этот счет. Посмотрел какой код генерирует VS2015, там что в debug'е, что в release обычный виртуальный вызов.

0

Сообщение от Voivoid Что-то у меня большие сомнения на этот счет.

Не в первый раз такую инфу встречаю. Скорее всего обернули аналог __closure

Сообщение от Voivoid обычный виртуальный вызов.

виртуальный или indirect? Где происходит vmt lookup? В случае с __closure vmt lookup происходит при назначении callback-метода, а при вызове просто indirect call

0

Сообщение от Voivoid Что-то у меня большие сомнения на этот счет. Посмотрел какой код генерирует VS2015, там что в debug'е, что в release обычный виртуальный вызов.

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

однако я рассматривал реализацию std::function,
его исходный код.

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

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

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


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

1. нужно уметь нацеливаться на разные функции.
2. нужно уметь перенацеливаться.
3. делать это можно в рантайме.

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

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

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

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

0

Позвольте встрять..., но на простом примере GCC вроде бы без труда оптимизирует indirect call в direct call:

f:/msys32/mingw32/i686-w64-mingw32/include/c++/functional:1871:2: note: converting indirect call in static void std::_Function_handler<void(_ArgTypes ...), _Functor>::_M_invoke(const std::_Any_data&, _ArgTypes&& ...) [with _Functor = void (*)(); _ArgTypes = {}] to direct call to void foo()

0

Сообщение от Fulcrum_013 смотрите исходники билдеровского Object Inspector прекрасный пример рантайм-рефлекшина.

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

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

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

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

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

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

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

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

использование же std::function - стандартно, и без каких либо изменений
единообразно работает на любой платформе,
которая поддерживает с++11

если можно поиметь профит такой же, как от расширений, но без расширений,
то без расширений - это реальный профит.

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

Сообщение от Fulcrum_013 Это называется инкапсуляция.

это больше похоже на маразм.

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

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

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

нафига их протектить?

Сообщение от Fulcrum_013 В механизме шаблонов с момента их появления ничего особо не поменялось.

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

вот вам для сведения:
при переходе с++03 на с++11,
основные изменения в ядре языка заронули именно механизм шаблонов.

я приведу самый банальный пример: constexpr, decltype, auto.
одни лишь эти средства преподнимают метапрограммирование
на принципиально иной уровень.

в с++17 нас ожидают концепты (уже доступны для гцц)
и статическая рефлексия.

Сообщение от Fulcrum_013 Смысл? Поиметь пенальти в виде невозможности переназначения обработчиков в рантайме?

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

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

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

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

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

Сообщение от Fulcrum_013 А разница в пенальти между direct call и indirect call насколько мизерна

я не знаю, что такое "direct call" и "indirect call".

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

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

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

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

Сообщение от castaway Позвольте встрять..., но на простом примере GCC вроде бы без труда оптимизирует indirect call в direct call:

я правильно понял, что "indirect call" это опосредованный вызов,
а "direct call" - это прямой вызов?

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

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

0

Сообщение от hoggy я не знаю, что такое "direct call" и "indirect call".

Как же вы тогда можете скорость сравнить если не знаете?

Сообщение от hoggy какие инженерные задачи решают разработчики таких систем.

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

Ну так и быть разъясню -
direct call - операнд - адрес вызываемой функции
indirect call - операнд указатель на адрес вызываемой функции.

0

Сообщение от hoggy я правильно понял, что "indirect call" это опосредованный вызов, а "direct call" - это прямой вызов?

Правильно.

1

Сообщение от hoggy и нет никаких ограничений по части перенацеливания. тобишь, в рантайме можно как подписываться, так и отписываться, так и назначать/переназначяать кастомные обработчики сообщений

Ну тоже самое делает __closure. и вся проверка сигнатур тоже в компайл-тайме. Лямбды и бинды сто лет не нужны делегатам поэтому их и нет. И все это существует уже 20 лет в борландовских коммпиляторах.

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

0

Сообщение от Fulcrum_013 Ну тоже самое делает __closure. и вся проверка сигнатур тоже в компайл-тайме.

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

Сообщение от Fulcrum_013 Лямбды и бинды сто лет не нужны делегатам поэтому их и нет.

очень забавно наблюдать, как вы игнорируете "скользкие вопросы".

я вам выше предложил продемонстирровать,
как вы со своим __closure сможете реализовать очередь задач.

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

при создании задачи можно указать с какими аргументами
её нужно позвать когда то в будущем.

и это - не какой то редкий юзкейс, а очень распространенная задача.

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

если бы этого не сделали,
то те же лямбды оказались бы такими же ущербными,
как и ваш __closure

который ласоснёт по полной при попытке порешать подобную задачу.

Сообщение от Fulcrum_013 поэтому их и нет.

вы опять противоречите реальным фактам.

сто лет назад они были в boost

но поскольку они оказались очень востребованными,
то с++11 их узаконил.

и теперь они есть в std
при этом лямбды были реализованы на уровне ядра языка.

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

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

Сообщение от Fulcrum_013 при этом разработчик решает какой механизм слежения за жизненным циклом подписчика использовать.

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

Сообщение от Fulcrum_013 Ну а Reflection дает возможность простого построения редактора взаимосвязей пользователем в рантайме.

ну это как в дельфи.
однако с++ далеко не формошлепка.
и одной лишь формошлепкой не ограничивается.

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

для CEGUI например, можно вообще описывать виджеты в xml.
а редактор умеет цеплять их в рантайме.

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

0

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

Вы не поняли. Оно нужно не для того чтобы формы шлепать в билдере. А для того чтобы можно было легко сделать редактор свойств компонентов бизнес-логики в приложении пользователя. Qt сырцы парсит. А что будет когда сырцов не будет?
Т.е. простейший пример - есть набор линий точек окружностей. Нужно их поредактировать c возможностью добавления удаления/перемещения. Будем под каждый тип объекта форму шлепать или свой велосипед в сторону рефлекшина городить?
Еще пример - банально триггер в игровом движке (хотя то же касается и вообще движков моделирования), который надо добавить/удалить/связат с датчиками и подписчиками в редакторе уровня/сохранить в фал/прочитать из файла вместе со всеми назначченными событиями. Опять будем огород городить в духе либо кучи формошлепства либо велосипедить рефлекшин?

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

Сообщение от hoggy сто лет назад они были в boost

То что они были в ище ни о чем не говорит. Embarcodero к примеру boost вышвырнула за борт. Раньше в комплекте была. теперь нет. надеюсь следом полетит и STL. Если к делегату нужно что то биндить, кроме самого объекта из которого он прислан, то это говорит о криво спроектированной иерархии.

0

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

ну и нахрена для этого рефлексия?

чем вам не угодил какой нибудь std::map<property-name, value>?
ну или, если так париспичило что-то более извращенное,
то variant ?

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

тобишь редакторы это схавают на раз.

Сообщение от Fulcrum_013 Qt сырцы парсит.

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

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

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

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

Сообщение от Fulcrum_013 Т.е. простейший пример - есть набор линий точек окружностей. Нужно их поредактировать c возможностью добавления удаления/перемещения. Будем под каждый тип объекта форму шлепать или свой велосипед в сторону рефлекшина городить?

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

Сообщение от Fulcrum_013 Еще пример - банально триггер в игровом движке (хотя то же касается и вообще движков моделирования), который надо добавить/удалить/связат с датчиками и подписчиками в редакторе уровня/сохранить в фал/прочитать из файла вместе со всеми назначченными событиями. Опять будем огород городить в духе либо кучи формошлепства либо велосипедить рефлекшин?

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

нахрена тут рефлекшен?

Сообщение от Fulcrum_013 Embarcodero к примеру boost вышвырнула за борт. Раньше в комплекте была. теперь нет. надеюсь следом полетит и STL

я уже понял, что вы STL не осилили.
куда уж там до boost.

а то что Embarcodero не держит его в коробке - это нормально.
никто не держит boost в коробке "просто что б был".

0

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

Насколько я понимаю как-то так:

Сообщение от hoggy но каково же было мое удивление, когда я вообще не обнаружил там присутствия ключевого слова virtual

Мне кажется ты куда-то не туда смотрел, глянь класс _Func_impl ( это в VS2015 ).

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

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

0

Сообщение от hoggy нахрена тут рефлекшен?

Представьте что его связи этого триггера редактирует юзер в рантайме. Используя рефлекшн вытаскиваем из этого триггера список его свойств (чтоб не все подряд показываются только из спец секции __published) и генеришь юзеру красивую формочку в которую все эти свойства в реалтайме обновляете и из которой в этот же триггер пишите. Теперь юзер вместо триггера нажимает на окружность. Тот же код точно так же генерит другую формочку и юзер точно так же играется с окружностью, хотя набор полей у нее абсолютно другой. Теперь юзер нажимает сейв. Запускается немного другой код, который вытаскивает данные из рефлекшина, только немного другие, а именно список чего сохранять по каждому объекту, и список методов сохранения пропертей назначенных кастомно. Теперя юзверь нажимат лоад. читаем classid вызываем создание объекта по classid, читаем его проперти и ему устанавливаем ну и далее по файлу, это если нам не совсем так надо как VCL обучен, если как он в исходе умеет устраивает - то пусть сам читает.
Т.е. достаточно в классе указать список свойств, а обрабатывать ввод/вывод извне можно не размазывая по всем классам, причем чем больше типов ввода-вывода тем больше размазывать, а компактным универсальным внешним кодом для каждого из видов(направлений) ввода-вывода.

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

Сообщение от hoggy например, их оригинальные слот-сигналы валидировали времени выполнения. что плохо отразилось на эффективности (медленно они работают)

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

Сообщение от hoggy но позже, когда стандарт устаканился, они добавили функционал std::function, поимев профит времени компиляции.

По сравнению с __closure никакого профита ни времени компиляции ни времени выполнения, ни удобства. Только лоссы. Хотя конечно есть небольшие оговорки с тем что __closure расчитан не на среднемелкомягкого кодера, а на человека хорошо знакомого с ООП, которому не взбредет в голову посылать делегатами non-member функции. честно ни разу с такой необходимостью ни сталкивался. так же как и с необходимостью посылать member function туда где не __closure, а просто указатель на функцию. Разве что callback винды, которому можно всегда static подсунуть, потому что он всегда имеет багаж, причем напрямую пользуется исключительно редко, WinAPI очень хорошо обернуто VCL.

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

Сообщение от hoggy я уже понял, что вы STL не осилили.

Та я на нее посмотрел еще в ее зародыше и сразу понял что эта штука нездоровая. Гораздо удобнее и безопасней списки void * собранные в интеллектуальные контейнеры, с несколькими разноплановыми списками и оповещением контейнера элементом о своих телодвижениях (изменения состояния), на основании которых контейнер его держит в соответствующих списках операций над ним. Во всяком случае если ООП занимаешся. Именно иерархию модели взаимодействия объектов предметной области строишь, а не массивы туда-сюда гоняешь в OnClick абы какой нить алгоритм запилить как получится, и по едитам красапету навести.

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

Сообщение от hoggy чем вам не угодил какой нибудь std::map<property-name, value>?

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

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

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

А имея Reflection я могу это делать с обычными свойствами любого типа. т.е. вытягивать и засовывать информацию из обычных объектов без всякого велосепидизма, причем даже обращаясь к ним по индексу а не по имени. Хоть int хоть __closure событие, хоть объект или многомерный массив. Мало того пользуются те же геттеры и сеттеры которые имеем в коде. Вопрос ведь особо не в том как обработать а как получить список свойст и функций доступа к ним. И здесь просто - либо этот список генерит компилятор либо велосипедим с возможностью наткнуться на ошибки в многократно повторяющихся списках.
Те же кстати ошибки в списках доступа пропертей ловятся довльно тяжко, если сигнатура геттера или сеттера подошла. А вы предлагаете еще использовать лисопед с заданием списков несколько раз, и скорее всего без проверки сигнатуры.
Кстати Embarcodero начала синтаксис пропертей двигать. В XE8 начали работать унарные операторы в духе ++ и +=. что в XE10 еще не видел, но похоже дело идет к ссылкам на свойства. Это еще гораздо больше все упростит.

0

Сообщение от Fulcrum_013 Представьте что его связи этого триггера редактирует юзер в рантайме.

что то я как то не осилил этот поток сознания.

Сообщение от Fulcrum_013 А вот когда делать - при вызове или при смерти подписчика, и как делать - это уже удобнее когда сам выбирать можешь как реализовать.

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

Сообщение от Fulcrum_013 По сравнению с __closure никакого профита ни времени компиляции ни времени выполнения, ни удобства.

вы просто бинды не осилили.

Сообщение от Fulcrum_013 Та я на нее посмотрел еще в ее зародыше и сразу понял что эта штука нездоровая.

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

Сообщение от Fulcrum_013 а в этот map их ручками прикажете засовывать в конструкторе каждого класса следя за совпадением списков их геттеров с сеттерами и иерархией наследования? Может таки удобнее когда это компилятор делает?

я не очень понимаю вашу точку зрения.

например, описал в обычном xml документе виджет для CEGUI.
я ж никаких std::map руками не правил.
однако все нужные свойства сами как то образовались в редакторе.

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

Сообщение от Fulcrum_013 А имея Reflection я могу это делать с обычными свойствами любого типа. т.е. вытягивать и засовывать информацию из обычных объектов без всякого велосепидизма, причем даже обращаясь к ним по индексу а не по имени.

здесь конечно ощущается какой то опредленный профит.

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

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

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

0

Сообщение от hoggy это может быть удобно, но не слишком эффективно с точки зрения затрат ресурсов машины.

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

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

Сообщение от hoggy мог без рефлексии создание становится в принципе не возможным.

Не знал что они парсят сырец компонентов. Такая не очень хорошая идея в голове не помещалась. Без парсинга - либо Reflection от компилятора либо велосипедить свой.

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

Сообщение от hoggy например, описал в обычном xml документе виджет для CEGUI

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

Сообщение от hoggy если чел не осилил STL, стало быть он языка не знает.

Если человек не пользует stl то это говорит о том что он знает язык, а только одну библиотеку. К примеру ни борланд stl в своих фрэймверках вообще не использует. Майкрософт только в некоторых экземплах к SDK во вспомогательных целях.к примеру в экземплах к DirectX STL пользуется только в компонетнте чтения конфигурации фркймверка DXUtil - т.е. даже для экземплов сделан довольно солидный фреймверк на базе которого они создаются. Причем никаких stl, пользуют свои динамические массивы. например CGrowableArray<> а не std::vector

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

Сообщение от hoggy если чел не осилил STL, стало быть он языка не знает.

Ну по моему личному мнению stl extremally unsafe при этом очень неудобна в использовании. Да и мама в детстве учила - не пользуй библиотеки у которых внутри малочитабельный говнокод.

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

Сообщение от hoggy вы просто бинды не осилили.

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

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

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

Кто в этот map ложит типы и адреса геттеров сеттеров и в какой момент времени?
Buileder генерит подобную таблицу сам и все это хранит с скомпилированном коде наподобие vmt, при этом в фреймверк входят функции чтения этой таблицы в рантайме. Т.е. дальнейшее развитие classid необходимость в котором комитет только узрел, а борланд уже 20 лет как всю эту концепцию развил на полную глубину ее возможностей. Было бы неплохо стандартизировать все это чтобы доступ к таблице осуществлялся не библиотекой а операторами языка.

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

Сообщение от hoggy например, описал в обычном xml документе виджет для CEGUI. я ж никаких std::map руками не правил.

Чем отличается описал в обычном xml от занес в map? Ну кроме того что этот map пропарсился кодом из xml

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

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

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

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

Сообщение от hoggy что то я как то не осилил этот поток сознания.

Если с задачей создания визуального редактора, который редактирует объекты неизвестные на момент компиляции редактора не сталкивались то осилить действительно трудно. Ну для того чтобы осилить задумайтесь как будете решать такую задачу, при условии что необходимо при обращении из кода (не из редактора, а из кода который работает помимо редактора, редактор только задает значения в свойтва объектов) к этим объектам сохранить штатный механизм вызовов. Т.е без велосепедизма в духе Object->Properties[Name]->Set(Value) и без сокрытия такого велосепедизма шаблонами. Т.е. должна оставаться возможность в коде этих неизвестных редактору классов писать Object->PropertyName=Value. Ну или как вы привыкли Object->SetPropertyName(Value); Т.е. другими словами универсально предоставить доступ визуальному редактору (сериализатору/десиализатору/движку скриптового языка и т.п.) к вашим сеттерам и геттерам и их списку у конкретного экземпляра, заранее неизвестного редактору класса.

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

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

Не факт. Как минимум нужен набор механизмов на выбор. Да и любой механизм за час лепится.

0