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

Омфг.
winter
> Посты Суслика к твоим вообще никакого отношения не имеют, там про другое речь,
> и касты он не использует.
Он точно так же использует глубокую связность системы. Как ее использовать - другой вопрос. И, в данном случае, нет смысла эту связность убирать.

Z
> Тоесть будем в дивайсе тайпкастить и трогать кишки текстуръ из дивайса?
Не, мы лучше будем порождать веселее на манер glGet, "кто забинден на контекст", "а тот ли шейдер" и классического "Кто здесь? Я не один?"

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

И да, на уровне реализации это не класическое ООП. Оно в полной мере не реализуемо на С++.
Но пользователя не должно волновать, что и как делается. Мы должны гарантировать безопасность работы. И в данном случае хотелось бы это делать не в ущерб скорости.

Btw, расширение языка рефлекшином (не важно на какой манер) эффективно решает все рассматриваемые проблемы.

Z
>> Мне интересно, обьектно-ориентированное решение - как его нормально сделать.
Дык насколько мне известно, вариантов лишь два - double dispatching в случае, если текстуру и контекст нужно оставить разделенными, и сохранение указателя на реализацию контекста в реализации текстуры в случае, если их можно жестко связать. Второе решение быстрее.

>> Кстати, архитектурнъе умения смешивать с чисто реализаторскими или вообще с знаниями железа смешивать не стоит!
Согласен с твоей оценкой деятельности Хумуса...

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

crsib
>> Btw, расширение языка рефлекшином (не важно на какой манер) эффективно решает все рассматриваемые проблемы.
Так может, вообще скриптовый язык тогда использовать? Или вызывать методы по имени, как делается внутри ActiveX?
Рефлекшн = тормоза, а мы ведь все-таки более-менее рилтайм обсуждаем.

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

crsib
>> И да, на уровне реализации это не класическое ООП. Оно в полной мере не реализуемо на С++.
Так я этого и хочу от тебя добиться... Чтобы ты признал, что в этом месте проектирования СУЩЕСТВУЕТ ПРОБЛЕМА. Как ее решать - полагаясь, как ты, на собственный семантический анализ, или, как я, исключительно на синтаксический анализ компилятора - согласись, уже дело пятое? Проблема-то налицо.

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

crsib
> Не, мы лучше будем порождать веселее на манер glGet, "кто забинден на
> контекст", "а тот ли шейдер" и классического "Кто здесь? Я не один?"
именно по этому я решил использовать тонкие обертки над дескрипторами, ноторые предназначены лишь для более строгой типизации...
вместо glGet с какой то GL_Константой, я создаю жестко заданный getInfoLog (допустим)
в нутри которого жестко задана константа и вызов нужноей glGet функции...
типизация нарушается лишь в случае reinterpret cast, поэтому я пишу преобразование из индекса в обертку в которой проверяю правильность индекса допустим с помощью той же glIsShader... если на входе не шейдер то можно и бабахнуть по рукам исключением.
+ тонкая обертка либо не имеет прав обладания над тем на что указывает индекс (т.е. не должна в деструкторе вызывать разрушение того к чему индекс относится), либо то на что указывает индекс должно иметь ref counting и допустим glDeleteShader не вызывает нарушений в работе тех компонент, которые  связаны с данным шейдером и по прежнему его используют

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

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

cNoNim
>> лишь через factory методы, которые уже установят все необходимые внутренние связи...
...т.е., как уже писал Суслик, сохранят указатель на реализацию контекста внутри указателя на реализацию текстуры, намертво привязав одно к другому :)

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

cNoNim
> а лишь через factory методы, которые уже установят все необходимые внутренние
> связи...
Осталось убедить в этом winter)))

winter
> Чтобы ты признал, что в этом месте проектирования СУЩЕСТВУЕТ ПРОБЛЕМА
Я ее отрицал? Но ты начал рассматривать случай, где ее нет

winter
> Рефлекшн = тормоза
Зависит от реализации. Ой как зависит. Особенно в общем случае.

Еще раз. Я привожу решение для конкретной ситуации. Это не общее решение.

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

ЗЫ: но тем самым мы получили тот самый огород, изза которого, я отдаю предпочтение дескрипторам :)

cNoNim
>> и немного не понятно почему тебе такой подход не нравится
Потому что, как я уже писал, в свое время мне понадобилось "отвязать" текстуры и шейдеры от контекста. Конкретнее - при реализации двухпоточного приложения с дебагом шейдеров: огл создает отдельный контекст для каждого потока, а текстуры и шейдеры грузить в видео-память два раза - уже маразм.

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

crsib
>> Еще раз. Я привожу решение для конкретной ситуации. Это не общее решение.
Твое решение сводится к приведению типов.

Приведение типов - это ИМХО (подчеркиваю, ИМХО!)
а) дурной тон вообще;
б) крайне тормозное дело, если ты не используешь "железное" приведение вроде (Type *).

Ни Суслик, которого ты зачем-то постоянно цитируешь, ни Земледелец, ни кто-либо еще в этом топике приведение типов не использует. Если процитировать все того же Суслика в 31-ом посте, "тайпкасты кроме самых крайних случаев(описанные в этом треде случаи даже не близки к крайним) не использую." Что правильно.

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

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

winter
мне не совсем понятно если честно как решение пускай даже на дискрипторах поможет в описываемом тобой случае
> Конкретнее - при реализации двухпоточного приложения с дебагом шейдеров: огл
> создает отдельный контекст для каждого потока, а текстуры и шейдеры грузить в
> видео-память два раза - уже маразм.
точно так же тебе как то нужно будет либо определять текущий контекст (синглетон на дескрипторах),
либо при смене контекста обновлять дескриптор который хранит текстура (обновление указателей на конкретный контекст)...

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