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

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

Страницы: 122 23 24 2530 Следующая »
#330
8:56, 26 янв 2012

winter
> Прочитал тут высказывания Линуса Торвальдса по поводу С++ в частности и ООП
> вообще...
> То, что Торвальдс - абсолютный моральный урод, никак не меняет того факта, что
> его слова иногда заставляют задуматься (примерно та же ситуация, как с
> некоторыми людьми на этом форуме, не будем показывать пальцем, да?).
>
> Нужно оговориться, что я просто обожаю плюсы. Как человек, имеющий солидный
> опыт программирования на жаве, я полагаю, что плюсы обходят жаву на несколько
> порядков: совершенно неудобоваримые, слабосильные генерики, невозможность
> объявления константных методов/ссылок и отсутствие перегрузки операторов, на
> мой взгляд, перевешивают встроенную сборку мусора.
>
> Но не суть. На протяжении многих лет нам пытались внушить, что главный принцип,
> управляющий ООП-разработкой - уменьшение "сцепленности" (англ. coupling) между
> компонентами системы; иными словами, объекты должны быть как острова в океане,
> обнесенные крепостными стенами, препятствующими любым попыткам заглянуть
> внутрь.
>
> Торвальдс спорит с этим утверждением, указывая на простой факт: внутренняя
> кухня операционной системы лучше всего описывается вовсе не объектами, а
> системами объектов и взаимодействиями между ними. Следовательно, ООП с его
> "малой сцепленностью" сразу идет как бы далеко и надолго, и мы вынуждены
> вернуться к старой процедурной парадигме: данные и функции для работы с ними.
> Несколько раз (сразу нужно сказать, что нечасто) я встречался с чем-то подобным
> - например, когда проектировал свой видео-движок.
>
> Текстура? Возьмем ее и закроем в черную коробочку, а юзеру выдадим интерфейс,
> который ни в коем случае не позволяет получить доступ к API-specific данным.
>
> Но ведь для того, чтобы "активировать" текстуру, скажем, в прямом х..., нужен
> не один, а сразу два объекта: сама текстура и контекст. Причем ни один из
> объектов не должен быть в "абстрагированном" виде - для активации нам нужен
> именно прямо-хшный контекст и прямо-хшная текстура. А у нас получается - если
> передаем ссылку на интерфейс контекста в метод текстуры, внутри метода имеем
> прямо-хшную текстуру и абстрактный контекст, если наоборот - прямо-хшный
> контекст и абстрактную текстуру.
>
> Варианты решения - либо ручное приведение типов (в углу кто-то ахает и роняет
> на пол бокал), либо синглтоны (ублюдство, т.к. сразу отпадает возможность
> использования нескольких контекстов), либо QueryInterface, либо использование
> того, что американцы называют "double dispatching". Последние два варианта по
> сути не отличаются, поэтому приведу листинг для дабл-диспатчинга:
>
> class IContext
> {
> virtual void Bind(const ITexture &tex) = 0;
> };
>
> ...
>
> class Context_DX;
>
> class ITexture
> {
> virtual void Bind(const Context_DX &context) const = 0;
> };
> Метод IContext::Bind(), соответственно, вызывает ITexture::Bind(). Детали
> класса Context_DX, разумеется, прикрыты от пользователя ранними объявлениями,
> только что толку - срамоту он все равно уже видел. Уродливо? Весьма.
>
> Как ни странно, в этом случае единственное красивое решение - возвращение к
> сишному, WinAPI-style программированию: дескрипторы и функции для работы с
> ними.
>
> Кто что думает по этому поводу?
>
> <правка> Поскольку были вопросы по поводу описанной проблемы, поясняю проще:
>
> 1. По правилам ООП, интерфейс скрывает детали реализации.
> 2. Я создаю два интерфейса IContext + ITexture и скрываю детали реализации, как
> положено.
> 3. Пока я работаю с каждым интерфейсом отдельно (случай "малой сцепленности"),
> все ОК.
> 4. Проблемы возникают, когда мне в одном и том же участке кода нужны
> одновременно детали реализации и контекста, и текстуры (случай "сильной
> сцепленности").
Вот представь себе пульт от телевизора и телевизор. Для того, чтоб переключать каналы, пульту не надо знать, как устроен входной фильтр, ему достаточно предоставляемого интерфеса - приёмника сигналов пульта. Интерфес же предоставляется самим телевизором и знает, в какой варикап чего надо послать, или через какой интерфейс уже части телевизора надо работать, а тогда уже тот интерфейс знает, куда послать дальше, в конце будет интефейс, посылающий реальное напряжение на конкретный варикап, но пульт не догадывается, что там не тупо шаговый двигатель крутит переменный конденсатор на подвижных обкладках. Так же и здесь. Ну завернул ты текстуру в класс, но как бы ты внутри неё ни хранил данные, хоть чередуй строки, хоть выделяй блоки, хоть поменяй порядок цветов на BRG, хоть сгруппируй по плоскостям, а выдать тексель по координатам тебе ни что не мешает, вот это и будет твой интерфейс, а девайсу и не нужна текстура, ему нужны тексели. Возможно это не будет работать в существующих картах, но только из-за того, что ОО не использовалась на нижнем уровне. Возможно это в чём то не оптимально, но это и есть истинно ООПное решение.

#331
13:49, 26 янв 2012

crsib
> Ну и контекст это не девайс. Девайс всегда один (ну по крайней мере это
> логично).
А если у меня две карты и на каждой по три дисплея?

#332
13:50, 26 янв 2012

crsib
> Ну и контекст это не девайс. Девайс всегда один (ну по крайней мере это
> логично).
А если у когото две карты и на каждой по три дисплея?
crsib
> DX11 это наглядно демонстрирует. OpenGL тоже, но с очень жесткой привязкой к
> одной системе.
К одной лишь винде привязан директ, а OpenGL есть во всех современных системах.

#333
14:04, 26 янв 2012

А мы ненавидим Линуса.

#334
15:08, 26 янв 2012

За всех не говори.

#335
15:11, 26 янв 2012

Этот парадигм гнусное идолопоклонство.

> I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. (Alan Kay)

> With the aphorisms you have hit upon my fancy. I love everything brief and find that in general the longer a work is the less there is
> in it. (Kurt Gödel)

> I did say something along the lines of "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows
> your whole leg off. (Bjarne Stroustrup)

> It certainly has its good points. But by and large I think it's a bad language. It does a lot of things half well and it's just a garbage
> heap of ideas that are mutually exclusive. Everybody I know, whether it's personal or corporate, selects a subset and these subsets
> are different. So it's not a good language to transport an algorithm -- to say, "I wrote it; here, take it." It's way too big, way too
> complex. And it's obviously built by committee. (Ken Thompson)

> Yes. When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got
> together and decided that we hated C++. (Ken Thompson)

#336
17:04, 26 янв 2012

Так и не понял, зачем был этот спор на 20 страниц... Зачем нужны всякие Texture_GL и Texture_DX, если можно сделать только DeviceGL и DeviceD3D, наследующиеся от интерфейса? А текстуры пусть запрашивают у них своё создание. Зачем дублировать классы ресурсов под разные контексты? А рендер пусть сам биндит текстуру. У меня так сделано и работает отлично. Чтобы добавить новый рендерер мне нужно написать класс, реализующий интерфейс Device.

#337
17:07, 26 янв 2012

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

Это классический пример неправильной трактовки принципов ООП и пример плохого дизайна.
Одна из наиболее частых (а чтобы говном не закидали - ИМХО, без претензий) ошибок начинающих программистов С++ в том, что они пытаются построить классы на все случаи жизни и в том, что некоторые программисты полагают, будто объекты существуют сами по себе. Это в корне неверное решение.

Ну что за догма, о том что ITexture должна выдавать пиксел по запросу. Зачем? Чем такое решение было продиктовано и кем эта догма поставлена?
Понятия объекта в себе - вещь чисто филосовская, не имеет к реальному практическому программированию никакого отношения. Нет никаких объектов самих по себе, это чушь!
Разве что stl контейнеры и какие-то простейшие абсолютно однозначно определенные математические понятия вроде векторов и комплексных чисел - ну они просто действительно всегда одинаковые в силу своей однозначной природы.

Что вы пишите? - CPU based ray tracer? - тогда да, текстура не только должна пикселы выдавать по запросу, но еще и фильтры реализовывать, типа анизотропного и билинейного.
Что вы пишете? - GPU render на OpenGL для игры? - тогда наоборот, выдавать пикселы на CPU не нужно, у ITexture совсем другие методы должны быть
Что вы пишите? - Конвертор изображений? - тогда наверное третьи. По крайней мере анизотропная фильтрация вам не понадобится.

Объектная архитектура строится под приложение а не наоборот.

#338
18:31, 26 янв 2012

FROL
> Ну что за догма, о том что ITexture должна выдавать пиксел по запросу. Зачем?
> Чем такое решение было продиктовано и кем эта догма поставлена?
FROL
Да нафиг это не нужно, но так будет по ООПу. В других же случаях ООП удобен. Например,

class TComplex
{
 ...
 public:
 TComplex operator + (TComplex &y);
 ....
};

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

#339
18:48, 26 янв 2012

atavin-ta
> хоть и нужны ему именно тексели, а не текстура.
Тексель - логическая абстракция. Не нужны дивайсу тексели. Ему нужен блоб данных, из которого он может семплить значения.
А будет ли это массив триплетов r/g/b, или куски чего-то, пожатого блочным сжатием, уже неважно.
В любом апи ты найдешь методы, работающие с абстракцией "текстура", но не найдешь ничего, оперирующего "текселями".

#340
9:10, 27 янв 2012

Не важно, как они хранятся, но нужны только они, так как именно они проецируются в пиксели экрана. А с текстурой ни одина реализация не работает целиком за одну элементарную операцию, её всегда разбирают на элементы и именно ради них и нужна сама текстура. Девиз растра: "Форма передаётся цветом". Всей текстуры? Рисунка целиком в растре просто нет, его синтезирует зрительная кора, да ещё в софте на высоком уровне есть логическая абстракция группы - растр, но реально могут как то обрабатываться машиной только текстели, пиксели, воксели, доксели, триксели и тому подобные элементы.

#341
18:14, 27 янв 2012

atavin-ta
> class TComplex
> {
> ...
> public:
> TComplex operator + (TComplex &y);
> ....
> };
Где здесь ООП?

#342
18:17, 27 янв 2012

Try
> Где здесь ООП?

как это где ? тут

#343
18:53, 27 янв 2012

innuendo
1980 - Alan Kay creates Smalltalk and invents the term "object oriented." When asked what that means he replies, "Smalltalk programs are just objects." When asked what objects are made of he replies, "objects." When asked again he says "look, it's all objects all the way down. Until you reach turtles."

#344
18:55, 27 янв 2012

vladislav

товарищу Кэю респект и уважуха :)

уточняю, статическое ООП тута в стиле C++

Страницы: 122 23 24 2530 Следующая »
ПрограммированиеФорумОбщее

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