Открытая реализация OpenVG

В общем, я понял. Кернел, написанный на QT, вот-вот появится.

Ой. Ты ведь всё это не про c++?

Любопытно, что же оно из себя представляет..

> Ребят, кто из вас чей виртуал?;)

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

Сергей, а серьёзно, мне кажется, вы тратите свой запал несколько втуне. Про гнусно медленный C++ вы можете рассказывать, скажем, на шутауте или в тестах кайры супротив кутешного артура или как оно у них там называется.

Единственный более-менее внятный аргумент против C++ в споре с C - это несколько более сложное создание привязок к /некоторым языкам/, включая C. Но, по мне, биндинги С к С++-библиотеке выглядят не более отвратительно, чем биндинги С++ к С-шной библиотеке...

>Но, по мне, биндинги С к С++-библиотеке выглядят не более отвратительно, чем биндинги С++ к С-шной библиотеке...

2AlexM, Мне кажется вы хотели сказать: "Но, по мне, биндинги С к С++-библиотеке выглядят не менее отвратительно, чем биндинги С++ к С-шной библиотеке..."

Иначе - бессмыслица /или вы сдали позиций в споре/

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

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

100% поддерживаю и разделяю вашу точку зрения как 50/50 C-шник и C++-ник.

А svu - фонатег ;)

Вы думаете? :-)

P.S. Сейчас перечитал свою фразу. Удостоверился, что сказал именно то, что хотел сказать.

>Для GUI лучше подходит C++.

библиотека - это не GUI.

Не смешивайте мои претензии в один флакон%)

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

2. Претензия к QtOpenGL была в том, что (как я предполагал - и ошибся) он обертывает OpenGL функции в плюсовую обертку - т.е. создает доп. код над OpenGL API. Я бы таким же образом ругался на любую, даже чисто сишную надстройку - потому как она тут не нужна ИМХО. Но коль скоро выяснилось, что QtOpenGL занимается совсем другими вещами - я претензию снял (с той оговоркой, что лучше б использовали GLUT/SDL).

Для GUI подходят "танковые клинья и ковровое бомбометание" (с). В смысле - скриптовые языки и managed языки. Ваять GUI на языке, в котором есть понятие "обратиться к произвольному куску памяти" - глупо.

>Для GUI подходят "танковые клинья и ковровое бомбометание" (с). В смысле - скриптовые языки и managed языки. Ваять GUI на языке, в котором есть понятие "обратиться к произвольному куску памяти" - глупо.

Надо позги немного другие иметь (не лучше и не хуже, а просто другие). Я, например, мыслю исключительно понятиями "память", "указатель" и пр.

> библиотека - это не GUI.

Если не ошибаюсь, о name mangling и прочих прелестях C++ мы с Вами знатно пофлеймили еще в сентябре. Баянчик получается, не находите? ;-)

> Для GUI подходят "танковые клинья и ковровое бомбометание" (с). В смысле - скриптовые языки и managed языки. Ваять GUI на языке, в котором есть понятие "обратиться к произвольному куску памяти" - глупо.

Я имел в виду, что в тандеме C/C++ для написания GUI лучше подходит C++. GTK'шные приложения долго удивляли меня прямо-таки армейской стройностью кода по сравнению с тем бардаком, что творится в Qt/KDE, пока я не влез в это поближе и не осознал, что если они с таким инструментом еще и писать станут как попало - полный линукскапец наступит :)

А скриптовые/managed языки - это разговор отдельный. В каких-то случаях, действительно, можно обойтись и ими. Но когда (по каким-то причинам) возникает задача: "GUI должен быть бинарным" - что делать прикажете?

Остается только порадоваться, что Вы не мыслите понятиями сигналов и логических элементов на кристалле процессора;)

ЗЫ Да, парадигмы разные есть - но общий тренд таков, что уровень абстракции хорошо б повышать изо всех сил

Насчет С - согласен. За то и люблю. На С можно писать либо хорошо и дисциплинированно - либо капец наступает практически сразу. Плюсы прощают неряшливость дольше - но и завалы при этом образуются куда выше;)

Кстати, а когда это бывает "GUI должен быть бинарным"? Мне не попадалось. Бывает "GUI должен быть быстрым" - но это совсем другая задача.

> Кстати, а когда это бывает "GUI должен быть бинарным"?

Навскидку - во встраиваемых системах

Или когда сильно хочется скрыть исходный код GUI ;-)

Ок, есть отдельные экзотические случаи. Но тогда (если embedded платформа очень уж хилая) и на асме можно GUI наваять;) В общем, по хорошему, каждый случай применения плюсов для GUI надо рассматривать под микроскопом и искать специальное обоснование...

Проприетарщиков - давить!%) Кстати, можно ли обфускировать скриптовый код? Кто-нибудь с таким сталкивался?

> Проприетарщиков - давить!%) Кстати, можно ли обфускировать скриптовый код? Кто-нибудь с таким сталкивался?

Аааа :( Написал длинный трактат и заснул на бекспейсе :( Заново набирать лень, ограничусь тезисами:

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

Насчет маломощных платформ и GUI на Асме - там всякие извращения бывают. Недавно судьба сталкнула с маршртуизаторами асуса - которые домашние. Так вот - там все rc-скрипты (в том числе, такая мелочь, как /etc/ppp/ip-up) написаны на C, более того - упакованы в один здоровый ELF< который одновременно является init. Зато вся эта байда на 200MHz MIPS'е загружается и открывает PPTP соединение быстрее, чем Sempron 3000+ на моем ноутбуке скажет "Ok, loading the kernel...." :)

Спать надо ночами!;)

Да, rc+init на С - это жесть... Впрочем, из моего скромного опыта (размером в один проект) - весь embedded development является одним большим куском жести...

> Да, rc+init на С - это жесть... Впрочем, из моего скромного опыта (размером в один проект) - весь embedded development является одним большим куском жести...

За весь embedded не скажу - но броадкомо-марвелловский дистрибутив, на котором строится большинство этих самых роутеров - жесть точно. Чего только стоит неутолимое желание ставить исходники в корень ;-)

>Вы думаете? :-)

Пардон

В тот момент, кажется, не думал, или делал это не тем местом.

>Только я надеюсь не дожить до того момента, как в Xorg появится зависимость от Qt...

Современная геронтология может творить чудеса :)

> Но когда (по каким-то причинам) возникает задача: "GUI должен быть бинарным" - что делать прикажете?

Все на хаскель, товаг'ищи!

> Проприетарщиков - давить!%) Кстати, можно ли обфускировать скриптовый код? Кто-нибудь с таким сталкивался?

Можно. Например, так: http://idisys.iae.nsk.su/~alex/shots/2001_02_09_203718_shot.jpg

Еще есть pyobfuscate итп. Вопрос только в том, что обфускация байткода - это... ну, это обфускация байткода, т.е. весь алгоритм останется как есть. Максимум, чего можно добиться, это чтобы внутримодульные классы/методы назывались по-дикому, от подглядывания в код это не помогает. Я в своё время вполне успешно "подглядывал" в объектный код, скомпиленный BorlandC-3.x, так что, ничего невозможного нет.

Тут скорее современная эфтаназия, чем современная геронтология =)

>Тут скорее современная эфтаназия, чем современная геронтология =)

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

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

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

Всё бы хорошо, да вот беда -- я из сотоварищей =)

Ничего, Саша, и тебя вылечат :-)

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

Не рвался и не рвусь. Девелоперов много, а техписов с юзабилистами -- мало =)