Войти
ПрограммированиеФорумОбщее

Указатели на функции-члены классов (комментарии) (10 стр)

Страницы: 19 10 11 1217 Следующая »
#135
21:46, 27 фев 2013

Kartonagnick
> Это не единичный случай. Это именно тот самый случай, когда для работы нужен
> делегат. Когда ты уже не отделаешься простым ООП
Да нет в задаче алекса не делегаты нужны, а сообщения, ты c ObjC знаком?
Kartonagnick
> Тупой базар пошел. Видимо ты не работал вплотную с идеомой "программирование в
> терминах сообщений". Я заколебался десять раз одни и те же очевидные вещи
> говорить.
facepalm
Kartonagnick
> Я так захотел. Хочешь - используй, но что бы и 2003 тоже работал.
XD ок тогда ты тоже не используй другие библиотеки, никакого  стл и буста. Если так то я согласен.

#136
22:00, 27 фев 2013

Kartonagnick
> Крайне не оптимальный способ по избавлению от жесткой привязки к протоколу
> вызова.
В чем его нерациональность?
Kartonagnick
> А не надо завязываться на адресе type_info, завязываться надо на самом объекте.
Вы все еще на С++ пишете?
Как будете востанавливать тип, если он приехал из dll? dll и exe могут и будут иметь свои экземпляры type_info для одного и того же типа, и в результате обратный каст провалится. Прямой же намек.
Kartonagnick
> Вот нахрена вообще тогда был нужен этот жесткий протокол? Вопрос вроде простой.
> Никто из вас так и не ответил.
Затем же, зачем нужен жесткий протокол при вызове функций. Потому что типобезопасность на уровне асма не может быть проконтролирована. Функция работает не с объектами, у которых всегда можно проверить тип, а с грудой байт.
И код должен "верить", что та груда байт, которую ему дали, можно интерпретировать именно так, как в описании функции записано. Или вам привычнее игнорировать типы? Ну и что, что функция просит указатель, а мы ей целое скормим?
Все равно не устраивает?

#137
22:10, 27 фев 2013

Chaos_Optima
> Да нет в задаче алекса не делегаты нужны, а сообщения, ты c ObjC знаком?

С ObjC я не знаком. Даже не представляю, как там устроен дизайн.

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

Chaos_Optima
> XD ок тогда ты тоже не используй другие библиотеки, никакого  стл и буста. Если
> так то я согласен.

можно использовать стандартную библиотеку 2003 стандарта. Просто там нет никаких std::function, или биндов.
А так - почему бы и нет.


Ещё требования:

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

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

Если принимаешь - тогда сделка заключена.

#138
22:30, 27 фев 2013

Grey304
> В чем его нерациональность?

Мой вопрос, который звучал на протяжении нескольких страниц типа не ясен?

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

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

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

Grey304
> Вы все еще на С++ пишете?
> Как будете востанавливать тип, если он приехал из dll? dll и exe могут и будут
> иметь свои экземпляры type_info для одного и того же типа, и в результате
> обратный каст провалится. Прямой же намек.


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

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

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

#139
22:48, 27 фев 2013

Kartonagnick
> можно использовать стандартную библиотеку 2003 стандарта. Просто там нет
> никаких std::function, или биндов.
> А так - почему бы и нет.
ок. ток я не пойму что ты привязался к std::function? мы же пишем свой делегаты, самособой готовые использовать нет смысла.
Kartonagnick
> Наличие документации к механизму.
не. нафига она, это же тест на восприятие, тоесть человек должен понять как работать с делегатом, не используя какую либо доку, как с stl::function
Kartonagnick
> Так же, разработчик должен предоставить формальное доказательство
> работоспособности его механизма, и продемонстрировать его можности. Я для этого
> использую гугл-тесты. Ты можешь использовать все что захочешь.
забей на тесты, слишком много телодвижений для такого теста, достаточно обычных примеров на все случаи жизни, тобишь:
- функции
- методы
- функторы (классы с переопределённым оператором() )
Kartonagnick
> Пользователи должны иметь гарантии, что механизм действительно работает именно
> так, как и ожидается. И без косяков.
омг. это простой тест на восприятие, какие гарантии, это не разработка библы, а лишь маленький класс (ну или маленькая система классов).

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

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

#140
22:52, 27 фев 2013

Chaos_Optima
> давай так, пишем делегаы по стандарту 2003, можно использовать стл, в
> результате мы должны предоставить исходники + пример использования, юнит тесты
> по желанию, документации быть не должно, даже коментов быть не должно,
> пользователь должен интуитивно понять как их использовать, глядя только на
> примеры. Идёт?

Договорились.

#141
22:56, 27 фев 2013

Kartonagnick
> Договорились.
Ок, значь замётано.

#142
0:29, 28 фев 2013

Kartonagnick
> Нахрена нужен протокол вызова в параметре шаблона, если первое что сделает
> пользователь: это огородик, по избавлению от этого протокола, попутно потеряв
> контроль над ошибками времени компиляции?
Я не знаю, каким пользователям понадобится такой огородик, но мне этот огородик никогда не нужен был. И даже в голову не приходил бред, чтобы чужому коду скармливать не те типы, что указаны в документации.
Kartonagnick
> Ему ответили, что это справедливо если действие происходит в рамках одного
> процесса, но если объекты из разных процессов, то единство адресов не
> гарантируется.
И вы еще обвинениями кидаетесь. Эпик фейл...

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

(поскольку ссылка на пред страницы, повторюсь) http://www.rsdn.ru/forum/cpp/3780680.flat.1
Где в этом тексте хоть слово про процесс?

#143
1:06, 28 фев 2013

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

Тогда тебе и делегаты тоже не нужны. Любую твою задачу можно решить и без них.
А вот ALX да, ему потребовался делегат.

Предлагаешь каждому пользователю, которому потребовался делегат городить огород и выращивать там boost::any ?
У тебя такие понятия об удобствах?

Grey304
> И вы еще обвинениями кидаетесь. Эпик фейл...
Где это я кидался обвинениями?

Grey304
> Где в этом тексте хоть слово про процесс?

Ну мож не правильно выразился. см упоминание об exe/dll.
exe у меня прочно ассоциируется с процессами.

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

#144
1:39, 28 фев 2013

Kartonagnick
> Но это не суть. Суть в том, что бы не сравнивать адреса объектов, а
> пользоваться штатным интерфейсом класса, который гарантирует стабильную работу.
Этот штатный интерфейс работать не будет. Вот что там написано. Потому что typeid в разных модулях будет возвращать ссылки на разные type_info. И станет очень интересно.  (И не надо забывать, что ABI у плюсов плохое. И очень мало фич можно безболезненно таскать через границы модулей)
Kartonagnick
> Ну мож не правильно выразился. см упоминание об exe/dll.
Интересная ошибка. При том, что во втором же предложении идет упоминание об dll.
Kartonagnick
> А вот ALX да, ему потребовался делегат.
> Предлагаешь каждому пользователю, которому потребовался делегат городить огород
> и выращивать там boost::any ?
> У тебя такие понятия об удобствах?
Ваш делегат с общепринятым термином и наработанным опытом применения этих вещей очень сильно расходится, поэтому я не вижу смысла дальше дискутировать.

#145
19:47, 28 фев 2013

Grey304
> Этот штатный интерфейс работать не будет. Вот что там написано

Нет, там не это написано.

В обсуждении речь шла о том, что бы сравнивать адреса объектов type_info, вместо того, что бы использовать функционал самого класса. Якобы так будет гораздо быстрее. Но можно встрять на проблему. И чуть ниже человек писал, что можно использовать функционал класса, и все будет в порядке.

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

1. Мой делегат позволяет сделать все тоже самое, что и std::function с биндами вкупе, только намного проще.
Не требует обязательного знания шаблонов, и меньше буковок в клиентском коде получится.

2. А вот область его применения намного шире, чем у аналогов. Потому что он реализует правило "единство типа".

#146
8:07, 1 мар 2013

boost::bind + boost::function, зачем городить огород

1. Кто кроме вас знает, что может сделать ваш делегат ? а что нет.
2. Кто кроме вас знает, какой упрощенный синтаксис с меньшим кол-вом букв можно использовать для юзания делегата ?
3. Если придется что допилить, на сколько лучше придется выучить шаблоны ?
4. Какая область его приминения для того кто не писал эти делегаты ручками ?

#147
22:43, 2 мар 2013

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

#148
0:33, 6 мар 2013

Kartonagnick
> Договорились.
сегодня выдалось свободное время. вот моя реализация делегатов
Delegate

#149
1:25, 6 мар 2013

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

Страницы: 19 10 11 1217 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.