Линус Торвальдс ненавидит С++. А мы с вами? (4 стр)

winter
> А вот и фигню ты спорол только что, бро! Слыхал про функцию из состава OpenGL
> API, wglShareLists()? Она расшаривает таблицы дескрипторов одного девайса на
> другой девайс (в огле они называются контекстами).
я строил орхетектуру именно из предположения, что текстура принадлежит только одному девайсу. если очень хочется, можно попытаться придумать нормальный интерфейс для расшаривания текстур. ты же этого не требовал в нулевом посте, верно?

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

winter
> Проблема в том, что решение с дабл-диспатчингом учитывает даже такие детали, о
> которых ты не подозреваешь.
В том числе учитывает что мы гарантированно вызвали wglShareLists? Которая сама по себе сужает круг применения только до OpenGL+win. Потому что это не функция OpenGL.
Ну и контекст это не девайс. Девайс всегда один (ну по крайней мере это логично). Контекстов может быть много. DX11 это наглядно демонстрирует. OpenGL тоже, но с очень жесткой привязкой к одной системе. Я бы сказал - слишком сильной.

winter
> Суслик... НУ ЭТО ЖЕ ДЕСКРИПТОРЫ. Я про них уже третью странцу талдычу, черт...
> Сишный WinAPI-style подход, когда все методы - у девайса, а юзеру выдается
> только дескриптор текстуры без методов...
ну да, так и есть. если ты так сильно печёшься по поводу своих циклических ссылок, ну так используй дескрипторы. второй пример, который я попытался описать, даже чем-то ооп снаружи напоминает. немного. жаль только, дескрипторы не безопасны совершенно, можно запросить у кого угодно какую угодно текстуру и хоть ты их заоборачивайся, но это всегда можно будет сделать.

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

Я предпочитаю принцип "design for change" - типа, заранее старайся учесть все возможности!

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

>> какие это, интересно?
Такие, что при дабл-диспатчинге текстура может потенциально принадлежать нескольким контекстам (см. выше, с чем я в свое время столкнулся).

crsib
>> В том числе учитывает что мы гарантированно вызвали wglShareLists? Которая сама по себе сужает круг применения только до OpenGL+win. Потому что это не функция OpenGL.
Приложение в своей пользовательской части должно вести себя единообразно и для вин32, и для линуха, и для прямого х.., и для огла.

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

Suslik
>> ну да, так и есть. если ты так сильно печёшься по поводу своих циклических ссылок, ну так используй дескрипторы. второй пример, который я попытался описать, даже чем-то ооп снаружи
>> напоминает. немного. жаль только, дескрипторы не безопасны совершенно, можно запросить у кого угодно какую угодно текстуру и хоть ты их заоборачивайся, но это всегда можно будет
>> сделать.
Так про это и речь. Речь про то, что тут надо бы дескрипторы использовать, т.е. возвращаться от ООП к не-ООП в тех местах, где есть такая сильная связанность. Собственно, это Торвальдс и имел в виду, только выразил это своим обычным уродским образом.

> Я предпочитаю принцип "design for change" - типа, заранее старайся учесть все возможности!
В любом случае нужно учитывать особенности того, что проектируешь

winter
> Приложение в своей пользовательской части должно вести себя единообразно и для
> вин32, и для линуха, и для прямого х.., и для огла.
В этом-то и проблема. А wglShareList - win only и AFAIK без аналога под под Linux/OS X

winter
> Черт, ну что ж ты так к терминологии привязался? Ну замени во всех моих постах
> слово "девайс" на слово "контекст". Проблема останется прежней.
Не останется. Это разные сущности.

crsib
>> Не останется. Это разные сущности.
Под "девайсом" я имел в виду то место, куда байндятся текстуры и шейдеры. В огле это называется "контекстом". В прямом х..., что характерно, тоже. Дальше см. пост #15 в самом начале второй страницы и замени везде слово "IDevice" на "IContext".

Да, но контексты создаются девайсом. Ровно как и текстуры.

crsib
Да пофиг, чем они создаются. Ну сделай милость, прочитай еще раз нулевой пост и 15-ый пост в начале второй страницы. Я там везде слово "девайс" заменил на "контекст".

Нет, не везде. Текстуры и шейдеры (и контексты) создаются девайсом. Куда они биндятся и как это реализованно - другой вопрос. Но при этом, если мы можем гарантировать уникальность девайса (а мы можем в данном конкретном случае). Следовательно мы можем гарантировать, что реализации имеют, гм, общую базу. То есть если у нас был создан Device_GL, то ITexture = Texture_GL, IContext = GLContext. Об этом я толкую на протяжении всего топика.

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

PS: все эти огороды из ООП с С++ подходом в которых потом черт ногу сломит, порядком надоели...
кажись я постепенно перехожу в стадию "могу не использовать"...

winter
> Я предпочитаю принцип "design for change" - типа, заранее старайся учесть все возможности!
Я предпочитаю делать сначала хорошенько продумать то, что мне может когда-либо понадобиться и реализовать это и только это. Реализовать лишнее, если это приводит к меньшей безопасности/трудности поддержки кода/меньшей гибкости, смысла не вижу. Реализовать то, что нужно сейчас, а потом итеративно расширять функциональность тоже не здорово.

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

cNoNim
> такое ограничение для того, что бы где надо можно было преобразовать тем же реинтерпрет кастом к нужному дескриптору или из него...
you're doing it all wrong

> кажись я постепенно перехожу в стадию "могу не использовать"...
форсировав фазу "могу нормально использовать", cNoNim перешёл сразу к "могу не использовать" :)

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

crsib
>> Следовательно мы можем гарантировать, что реализации имеют, гм, общую базу
Это семантическая связь (связь, которую понимаешь ты сам), а компилятор - это синтаксис, ему ты семантику не объяснишь. Т.е. придется юзать апкаст.

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

if (tex instanceof Texture_GL)
    Texture_GL tex_GL = (Texture_GL) tex;

Долой апкаст.

<правка>
И, кстати, не забудь, что апкаст "без вопросов" возможен только в случае отсутствия множественного наследования. В противном случае - встраивание в приложение "информации о типах на этапе выполнения" + супер-медленные STL'евские касты.