LINUX.ORG.RU

Сравнение производительности Qt и Cairo


2

0

Зак Русин провел сравнение производительности векторной графики в Qt и Cairo. Тест состоит из рендеринга трех сложных полигонов: text path, маленький полигон с большим количеством вершин на одной линии, огромный полигон с количеством вершин порядка 100000.

Измерялось количество кадров в секунду, использовались версии Cairo 1.2.5 (XRender и Glitz), Amanith из svn, Qt 4.3 (XRender и OpenGL) на Pentium4 3.2ГГц, 1Гб, NVIDIA 6600 с драйвером 1.0-9625.

Все тесты использовали антиалиасинг, и были предприняты усилия, чтобы поставить библиотеки в равные условия. Результаты очень интересны:

* Qt быстрее Cairo в XRender в 5-7 раз
* Qt(OpenGL) быстрее Qt(XRender) в 5-7 раз, но упирается в производительность GPU при 80000+ вершин
* Cairo(Glitz) показывает одинаковую производительность с Cairo(XRender)
* Ни Amanith, ни Cairo(XRender) не могут справится с последним полигоном в 100000 вершин.
* С большим полигоном Cairo(Glitz) отображает 0.2 кадра в секунду, а Qt переваливает за 10 fps.
* Qt(XRender) на порядок превосходит по производительности и Cairo(Glitz), и Amanith, хотя последние работают с OpenGL ускорением, а первый без него.


Выводы: Qt на голову выше других библиотек, а в OpenGL настолько быстр, что сравнивать с чем либо ещё просто нечестно.


PS от автора новости: Остается надеяться, что OpenSource позволит авторам Cairo "подсмотреть" построение тесселятора и рендерера, чтобы сократить разрыв до приемлемых значений.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от anonymous

> НИКОГДА под моим началом не будет кода на C

Ну да. А под моим - на С++. Скорее всего, под моим началом не будет никакого кода;)

Насчет методов доказательства - единственным ДОКАЗАТЕЛЬСТВОМ я признаю доказательство от противного - взять человека с опытом работы в gtk (но без опыта с кутей) и посмотреть, сделает ли он проект на куте на месяц быстрее, чем его же на гтк. В противном случае признать верным мое исходное утверждение - скорость разработки зависит от начального уровня скиллзов разработчиков (которая для большинства проектов является одной из входных констант, а не переменной).

svu ★★★★★
()
Ответ на: комментарий от svu

> взять человека с опытом работы в gtk (но без опыта с кутей) и посмотреть, сделает ли он проект на куте на месяц быстрее

Ты завел речь о шареварщиках, которые -- "мелкие коммерческие фирмочки (из одного-двух человек)". Где там "человеки с опытом gtk"?

Напомнить, на чём обычно пишут UI под Windows? Мало того, что всё насквозь ООП, так еще и визардами-шмизардами сдобрено. Значит отправной точкой будет человек /без/ опыта gtk и Qt, но с опытом MFC, VCL и прочих RAD. Поэтому мне очевидно, что набросать в QtDesigner, а потом продолжить разработку с ООП фреймворком будет намного проще, чем пробираться через дебри невнятной документации, и учиться использовать "объекты на Це".

Подчеркну, вопрос /документации/ будет стоять чуть ли не на самом первом месте.

> скорость разработки зависит от начального уровня скиллзов разработчиков

А с учетом того, что они все как один ООПшники...

baka-kun ★★★★★
() автор топика
Ответ на: комментарий от baka-kun

Вопрос о шареварщиках был отдельным, не связанным с вопросом "доказать"

> А с учетом того, что они все как один ООПшники...

Лучше им дать pythin/mono/... а не недоООплюсы.

svu ★★★★★
()
Ответ на: комментарий от svu

PyQt и/или Qt# ... :)

>> а не недоООплюсы.
типа gtk - супер ОО .... я фигею дорогая редакция

только не надо про биндинги
гавно , оно и под соусом гавно

P.S.
вот одного не могу понять
почему такие растакие недоОО плюсы могут поддерживать
объектную модель и C# и ObjectiveC и SmallTalk ?
объектная модель ObjectiveC в Qt в одну строку
widget->metaObject()->invokeMethod(widget, "setObject", Q_ARG(IObject*, object));
при этом ! с поддержкой асинхронной доставки
а может вы продемонстрируете объектную модел хаскеля на С ?
обгоните плюсы ?

P.P.S.
только откровенные урооды могут ругать плюсы
и только по одной причине - проф позволяющий себе оскорбления по отношению к одной из профессиональных областей исходя из модных веяний - урод

anonymous
()
Ответ на: комментарий от svu

>> Насчет методов доказательства - единственным ДОКАЗАТЕЛЬСТВОМ я признаю доказательство от противного - взять человека с опытом работы в gtk (но без опыта с кутей) и посмотреть, сделает ли он проект на куте на месяц быстрее, чем его же на гтк

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

чистый тест - это два одинаковых "нулевых" разработчика
но он уже проведен - общее число _маленьких_ приложений под Qt/KDE и gtk/GNOME ...
чем больше тем лучше - достаточно хороший интегральный критерий

anonymous
()
Ответ на: комментарий от anonymous

> типа gtk - супер ОО .... я фигею дорогая редакция

Вы путаете язык и библиотеку. Если говорить о ЯЗЫКАХ, реализация ОО в плюсах действительно не самая удачная (мягко говоря).

> а может вы продемонстрируете объектную модел хаскеля на С ?

Именно потому что на С нет "своей" объектной модели, туда можно запихать любую (что прекрасно демонстрируют байндинги из С к ОО языкам). А вот Вы попробуйте запихнуть, например, жабскую объектную модель в плюсы - не сваливаясь в полностью безобъектный код в сишном стиле? Что Вы будете делать, например, с различиями при инициализации объекта?

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

Бессмысленный параграф. Во-первых, С++ - это не "область" - это язык. Во-вторых, есть уважаемые мной люди, знающие и любящие этот язык - что не меняет моего отношения к нему (возможно, Вы просто недавно на ЛОРе и не в курсе...). И дело совсем не в модных веяниях - дело в качестве самого языка.

svu ★★★★★
()
Ответ на: комментарий от svu

> Вопрос о шареварщиках был отдельным, не связанным с вопросом "доказать"

"У меня все ходы записаны" (с)

svu **** (*) (26.10.2006 15:04:44) > Вы забыли одну составляющую - мелкие коммерческие фирмочки ... океан винюковской шаревари

svu **** (*) (26.10.2006 15:47:19) > Эти "халявщики" - мелкий бизнес.

h8 * (*) (26.10.2006 16:06:28) > Я какое-то время работал в мелкой фирме ... 1500 баксов на лицензию можно найти,.. не каждый месяц покупают

svu **** (*) (26.10.2006 16:31:33) > отмазки "месяц экономии" - не канают. Про этот месяц еще доказать надо, провести исследование, а 1500 надо из кармана прям щаз выложить...

Skull *** (*) (26.10.2006 18:19:16) > Экономия на скорости разработки окупается.

svu **** (*) (26.10.2006 21:36:51) > Вы готовы ДОКАЗАТЬ, что экономия от разработки на куте есть, по сравнению, допустим, с gtk+?

baka-kun *** (*) (30.10.2006 20:05:48) > Ты завел речь о шареварщиках... Напомнить, на чём обычно пишут UI под Windows?

svu **** (*) (30.10.2006 22:34:06) > Вопрос о шареварщиках был отдельным, не связанным с вопросом "доказать"

baka-kun ★★★★★
() автор топика
Ответ на: комментарий от svu

>> Вы путаете язык и библиотеку. Если говорить о ЯЗЫКАХ, реализация ОО в плюсах действительно не самая удачная (мягко говоря).

svu, ты написал хоть один компилятор для OO языка ?
так может не будешь пи...ть ?

>> Именно потому что на С нет "своей" объектной модели, туда можно запихать любую

не надо пи...ть, просто покажи хаскелевскую

>> А вот Вы попробуйте запихнуть, например, жабскую объектную модель в плюсы - не сваливаясь в полностью безобъектный код в сишном стиле?

java вообще-то - подмножество плюсов, это так к сведению для дураков.

>> Во-первых, С++ - это не "область" - это язык.

Художественная литература что-ли ? проза или поэзия ?

>> И дело совсем не в модных веяниях - дело в качестве самого языка.

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

PS
задолбало, задолбали дураки

anonymous
()
Ответ на: комментарий от svu

вдогонку

почему Вы решили что 'на С нет "своей" объектной модели,' ?
а Вы знаете, что ООП это не метод вычисления, а способ представления ?
что для ООП нет не ООП языков ?

PS
хорошо выучить чужую глупую фразу и потом по дурацки все время ее повторять ?

anonymous
()
Ответ на: комментарий от svu

>> Что Вы будете делать, например, с различиями при инициализации объекта?

сначала переведи на русский
потом сядь и подумай что это такое -
class java::lang::Object : public _JvObjectPrefix
{
protected:
virtual void finalize (void);
public:
// Order must match order in Object.java.
jclass getClass (void);
virtual jint hashCode (void);
void notify (void);
void notifyAll (void);
void wait (jlong timeout, jint nanos);
virtual jboolean equals (jobject obj);
Object (void);
virtual jstring toString (void);
void wait (void);
void wait (jlong timeout);

......

anonymous
()
Ответ на: комментарий от baka-kun

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

Впрочем, это не отменяет защищаемой мысли - производительность при использовании любого тулкита будет зависимость от начального уровня знаний разработчиков. Переход mfc->qt не принципиально сложнее перехода mfc->gtk (если уж такое тяготение к плюсам у конкретного коллектива - gtkmm, официальный байндинг). И в для гуевых прикладух (размера small-to-medium, как обычно в шаревари) в любом случае наилучшую ожидаемую производительность будут давать скриптовые ОО языки.

svu ★★★★★
()
Ответ на: комментарий от anonymous

> svu, ты написал хоть один компилятор для OO языка ?

Во-первых, мы говорим не о компиляторах, а о языках (предвидя вопрос - да, и ОО языка своего я не разработал). Во-вторых, мне, пожалуй, нравится Ваша идея. Пожалуй, на ЛОРе станет очень тихо, если о ДЕ будут рассуждать только те, кто значится в окошке "About" какого-нибудь ДЕ. А о дистрибутивах - Марк с Патрегом.

> java вообще-то - подмножество плюсов, это так к сведению для дураков.

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

svu ★★★★★
()
Ответ на: комментарий от anonymous

Восхитительно! Теперь произведите от этого дела класс A, определите там toString, вызовите в конструкторе toString (например, выведите в cout), произведите от А класс B и переопределите toString. Под занавес - создайте объект класса B. А потом ответьте на вопрос - что напечатается в плюсовой реализации, и что - в жабской.

svu ★★★★★
()
Ответ на: комментарий от svu

Виноват, не закончил мысль. Что я хотел показать - вопрос экономии времени в случае очень похожих технологий - вопрос глубоко вторичный и на него влияет множество факторов. Тогда как вопрос лицензии ИМВХО более важен. Особенно резко я это почувствовал, когда услышал от ибмовских консультантов, что им принципиально запрещено использовать в проектах (не внутренних ибмовских проектах, а на сайтах заказчиков) любой жплевский код. Боятся вируса, ох как боятся...

svu ★★★★★
()
Ответ на: комментарий от svu

Эх, очередная священная война.

У меня вопрос к svu. Какой набор средств предпочтительнее использовать при разработке некоторой библиотеки для Linux? Вопрос для меня не праздный, т.к. достаточно долго занимаюсь созданием ядра OCR и в качестве языка выбрал C, не в последнюю очередь из-за простоты дальнейшего использования моей библиотеки из других языков. Разумеется, используется glib2, однако до GObject пока не добрался... И вы знаете, периодически хочется все бросить и переписать на C++. Хотя, я не уверен, что код станет намного проще. Лаконичнее - да. А то надоедает писать конструкции вида:

OcrEngine *engine;
OcrImage *image;

engine = ocr_engine_new("russian");
g_assert(engine != NULL);

image = ocr_image_new_from_file(argv[1]);
if(!image) {
//
}
//

И т.д.

syomin
()
Ответ на: комментарий от syomin

Если отрезать в одно предложение по-ЛОРовски, то "конечно же, на С" ;)

Если развернуто (и без моего традиционного экстремизма%) - то, конечно, зависит от многих обстоятельств. В сущности, библиотека OCR это не тулкит, не является "платформообразующей" - так что пуркуа бы не па замутить это дело на плюсах, если вы себя столь уверенно в них чувствуете (но лучше бы не надо, если это Ваш первый или второй проект)? Возможен компромиссный вариант - сделать библиотеку на плюсах, а API к ней чисто сишный (хотя это и изврат, в общем-то).

Насчет конкретностей: рекомендую таки воспользоваться gobject. Возможно, применить препроцессор gob. Должно сократить некоторое кол-во кода. От проверок инициализации все равно деваться некуда - будь то отлов эксешпнов или что еще...

Вкратце как-то так.

Да, позвольте уточнить, - почему для библиотеки OCR так важны байндинги на других языках?

svu ★★★★★
()
Ответ на: комментарий от svu

> что напечатается в плюсовой реализации, и что - в жабской.

Methods called from constructors should generally be declared final. If a constructor calls a non-final method, a subclass may redefine that method with surprising or undesirable results.

сам_себе_злой_буратин ?

<<одно время в плюсах был разнобой, пока "специательно" не задекларировали поведение, к объектной модели это имеет несколько отдаленное отношение, и, даже, подтверждает их "похожесть">>

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

> Пожалуй, на ЛОРе станет очень тихо, если о ДЕ будут рассуждать только те, кто значится в окошке "About" какого-нибудь ДЕ. А о дистрибутивах - Марк с Патрегом.

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

PS
вообще-то спорить с Вами - не интересно. Вы не достаточно компетентны что-бы высказать что-либо интересное. Жаль только одного - Ваша некомпетентность может быть воспринята как истина, это действительно огорчает.

anonymous
()
Ответ на: комментарий от svu

Не, в одно предложение не интересно.

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

Байндинги к другим языкам хочется иметь по причине того, что писать приложение для конечных пользователей я не планирую. Возможно, кто-то напишет такое приложение, возможно на python'е, или C# или чем-то еще высокоуровневом. К тому же, можно сделать и WEB-сервис такой...

Про GObject подумаю. Фактически, нужно обвязать два класса - OcrImage и OcrEngine. Объекты остальных классов используются только внутри библиотеки.

syomin
()
Ответ на: комментарий от anonymous

> Methods called from constructors should generally be declared final. If a constructor calls a non-final method, a subclass may redefine that method with surprising or undesirable results.

Дада, очень продуманно все сделано. Т.е. мало того, что сам метод final - так еще и не дай бог не вызвать из него не-final метод (и далее вниз по стеку, что характерно)? И так вообще держать в голове всю возможную последовательность вызовов - каждый раз, добавляя новый вызов в конструктор. Очень вдохновляет. И - главное - ну просто абсолютно совместимо с жабой (которая, конечно же, "подмножество").

> сам_себе_злой_буратин ?

При чем тут "сам себе"? В двух языках РАЗНЫЕ и НЕСОВМЕСТИМЫЕ представления о поведении виртуальных функций при вызове из конструктора (даже непрямом, через другие функции). И это не единственная разница в объектных моделях.

> хотите отрицать наличие реализации явы совместимой с плюсами ?

Какая каша в голове ("реализация ... совместима с плюсами(языком!)")... Вы еще вспомните, что интерфейс jni определен в т.ч. и для плюсов - и на этом основании сделайте вывод, что объектная модель жабы совместима с плюсовой. Извольте придерживаться исходного тезиса о соотношении языков (и их объектных моделей) - и не скатываться к реализациям.

> но учить людей делать дистрибутивы, не сделав ни одного - хамство.

А вот теперь покажите, где я _учил_ кого-то, как делать ОО языки ("критика" != "поучение"). Или заберите свои слова обратно, с извинениями.

svu ★★★★★
()
Ответ на: комментарий от syomin

Даже если Вы не планируете делать end-user приложение, я не думаю, что для авторов соотв. приложений (а таких авторов вряд ли будет ОЧЕНЬ много, как для случая какого-нибудь тулкита) Ваш плюсовый интерфейс (если допустить, что он будет хорошим;) станет ТАКОЙ уж проблемой. Хотя, конечно, да, чисто сишный был бы в этом случае лучше, это я Вам как svu не могу не отметить;) В общем, если есть возможность - лучше бы оставаться на С, но обязуюсь не начинать священную войну против Вас, если это будут плюсы;)

svu ★★★★★
()
Ответ на: комментарий от svu

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

syomin
()
Ответ на: комментарий от syomin

Засылайте, посмотрю на досуге. Хотя бы на мой лоровский ник at gnome org. Скорой реакции не обещаю;)

svu ★★★★★
()
Ответ на: комментарий от svu

в первом параграфе s/совместимо с жабой/совместимо с плюсами/

svu ★★★★★
()
Ответ на: комментарий от svu

>> Methods called from constructors should generally
> Дада, очень продуманно все сделано.

ну лажанулись в яве. зачем в истерику впадать ?
следует определить, что такое совместимость объектных моделей, а то вы ее путаете с эквивалентностью реализации.
совместимость объектных моделей двух языков LA и LB это - если
cуществует объект a класса A в языке LA то он может использовать (содержать и/или вызывать методы и/или наследоваться) любой объект b класса B в языке LB
ну а теперь покажи что для С++ и Java это невозможно

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

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

anonymous
()
Ответ на: комментарий от syomin

А куда-нибудь в более общедоступное место вы не могли бы выложить свою библиотеку? А то в вашем старом посте ссылка не работает.

geekkoo
()
Ответ на: комментарий от anonymous

> ну лажанулись в яве. зачем в истерику впадать ?

Это не лажа. Это преднамеренная деталь объектной модели. Увы, часто удобная (несмотря на рекомендацию - которая выглядит как "извинение"). И порой в С++ люди попадают впросак именно потому, что ожидают (подсознательно) вызов виртуального метода производного класса, забывая о том, что где-то в стеке уже лежит frame конструктора. Я не буду утверждать, какой из подходов правильный, я только указываю на то, что они РАЗНЫЕ.

> совместимость объектных моделей двух языков LA и LB это

Интересное определение. Из какого источника, если не секрет?

В данном случае несовместимость выражается в разном поведении. В том, что формально одинаковая конструкция (сочетание классов-методов-конструкторов) будет давать два различных поведения. И в том, что используя соответствующие объектные структуры С++ Вы не сможете повторить поведение жабского кода - Вам придется забыть про конструкторы и начать создавать собственные функции init/term.

В сущности, Ваше понятие совместимости - это возможность подогнать одно под другое при помощи напильника. Да, при некоторых усилиях это возможно (в случае с Java/C++ точно, в случае других ОО - скорее всего тоже, но утверждать не буду). То, как определяю совместимость я в этой дискуссии - это однозначное отображение свойств и поведения одной модели в другую.

"НедоОО" (возможно, чрезмерно резкий термин) связан не с совместимостью или несовместимостью ОО модели плюсов с жабской или какой-то еще другой, а с тем, что плюсы очевидно пытались стать компромиссом между "плоским" языком С и ОО подходом. И, как всякий компромисс, обладают недостатками и с той, и с другой стороны - с одной стороны, язык С развивается в направлении, которое конфликтует с плюсами (на что ругается уже сам Страуструп), с другой - ОО в плюсах получилась "недоделанной" (именно потому что совместимость с С была объявлена священной коровой).

svu ★★★★★
()
Ответ на: комментарий от svu

И как насчет того, чтобы извиниться за обвинение "учить делать дистрибутивы, не сделав ни одного"? Или Вы готовы предоставить цитату, где я учу людей делать ОО языки?

svu ★★★★★
()
Ответ на: комментарий от svu

> Это не лажа. Это преднамеренная деталь объектной модели.

которую потом объявили как не пользуйтесь и которая может привести к непредсказуемому поведению ?

какая-то злостная преднамеренная деталь

> Увы, часто удобная

???? т.е. вы сознательно вносите непредсказуемость в ваш код ?
т.е. грабли всем и побольше и побольше ?

> И порой в С++ люди попадают впросак именно потому, что ожидают (подсознательно) вызов виртуального метода

я вообще-то был удивлен явовскому поведению, и, если честно, оно меня напугало

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

> Вы не сможете повторить поведение жабского кода - Вам придется забыть про конструкторы и начать создавать собственные функции init/term.

могу, но компилятор скажет что-то типа "использование объекта тогда, когда его конструирование не было завершено"
правду ведь скажет ? :) (но пропустит :) пистолет в руках, нога внизу)

> В данном случае несовместимость выражается в разном поведении.

проблема в том, что у вас нет средств, если только не ломать объектную модель, определить "_с наружи_" какое поведение у данного объекта данного класса

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

это эквивалентность

> НедоОО" (возможно, чрезмерно резкий термин) .. с тем, что плюсы очевидно пытались стать компромиссом между "плоским" языком С и ОО подходом ... с другой - ОО в плюсах получилась "недоделанной" (именно потому что совместимость с С была объявлена священной коровой).

несколько не так, в с++ имеется объетная модель с++ (построенная на принципах - минимальная модель), и вычислительная модель С (построенная на принципах - минимальная вычислительная модель), в силу ряда причин не было произведено отображение объектной модели на вычислительную (правильно - одна из них совместимость с С). В силу того, что "язык С развивается в направлении, которое конфликтует с плюсами", в последующих стандартах следует ожидать отказ от совместимости с С.

вернее всего говорить, что вычислительная модель с++ не когерентна с объектной моделью с++

anonymous
()
Ответ на: комментарий от svu

извини за некорректное слово
слово _учить_ в фразе: "учить делать дистрибутивы, не сделав ни одного" было не корректным, правильно звучит:
"критиковать производителей дистрибутивов, не сделав ни одного"

anonymous
()
Ответ на: комментарий от anonymous

в догонку

ява так-же грешит "вычислительная модель не когерентна с объектной моделью", единственный без греха -smalltalk

а построив объектную модель над С, вы такой когерентности не добъетесь

anonymous
()
Ответ на: комментарий от anonymous

> которую потом объявили как не пользуйтесь и которая может привести к непредсказуемому поведению ?

Поведение предсказуемо, с т.зр. языка - вызов метода дочернего класса. Другое дело, что с т.зр. разработчика базового класса это может быть "неожиданностью".

> т.е. грабли всем и побольше и побольше ?

Зависит. Как правило - нет. Но из всякого правила могут быть исключения (коль скоро язык-то дозволяет?;). И вообще мы не об этом - а о той самой разнице.

Опять-таки, если весь из себя финальный метод m1 (используемый часто, в т.ч в конструкторе) вызывает из себя виртуальный m2 - что Вы (точнее автор рекомендации) предлагаете делать, создавать его копию m1f (использующий финальный m2f, который будет копией m2)? Или ваще городить какой-нибудь огород с интерфейсами? При том что семантически будет вполне приемлемо вызвать m2 даже в конструкторе (например, он ваще не использует данные производного класса - бывает же такое)?

> я вообще-то был удивлен явовскому поведению, и, если честно, оно меня напугало

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

> компилятор скажет что-то типа "использование объекта тогда, когда его конструирование не было завершено"

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

> это эквивалентность

Ок, пусть будет она. В таком случае ваше утверждение о _совместимости_ (в Вашем определении) становится практически бессмысленным - любая (почти?) объектная модель объявляется в реальности совместимой с плюсовой, поскольку плюсы всегда могут "скатиться" на уровень плоского С и сделать все врукопашную.

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

Во, это будет совсем интересно! Вот до этого я хочу дожить! Если при этом в плюсах еще и запретят объекты на стеке строить, а только в heap-е - будет ваще супер! Тогда (ну и еще пара мелочей) мне придется забыть про "недоООП" в применении к плюсам навсегда. Ага, и байткод туда еще (шутка;)

svu ★★★★★
()
Ответ на: комментарий от anonymous

> "критиковать производителей дистрибутивов, не сделав ни одного"

Именно это меня и порадовало. О дистрибутивах спорить только Патрику с Марком. А о ДЕ - только их авторам (хотя бы в этих спорах я могу принимать участия). Мне кажется, ЛОР очень быстро станет безлюдным.

Да, критиковать гораздо (на порядки) легче, чем создавать. Но пока что человечество не приняло универсальной ценностью идею "прежде чем критиковать, создай свое лучше". И пока оно так - Ваше пожелание останется пожеланием.

Извинение принято, хотя оно прозвучало несколько странно.

svu ★★★★★
()
Ответ на: комментарий от svu

> в любом случае наилучшую ожидаемую производительность будут давать скриптовые ОО языки.

не обязательно ОО языки, я все интерфейсы (и не только) на Perl'e пишу, пишется на порядок быстрее, чем на С/С++

сам Perl трудно назвать читым ОО языком, хочешь - используешь объекты, хочешь -- нет, в нем вообще ОО не выделяется, просто "поддерживается" :)

vadiml ★★★★★
()
Ответ на: комментарий от syomin

> Про GObject подумаю. Фактически, нужно обвязать два класса - OcrImage и OcrEngine. Объекты остальных классов используются только внутри библиотеки.

я думаю, что лучше всего, что бы помимо glib библиотека зависимостей не имела, тогда к ней легко будет прицепить UI на любом языке и с использованием любой граф.библиотеки (Gtk/Qt/tk)

vadiml ★★★★★
()
Ответ на: комментарий от vadiml

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

svu ★★★★★
()
Ответ на: комментарий от vadiml

Пока в зависимостях только glib2 и libtiff. Я хотел сделать загрузку / сохранение изображений с помощью GdkPixbuf, но из-за того, что там нет поддержки полутонового (grayscale) цветового пространства или возможности загружать картинку по частям, отказался от этой идеи. Загружать изображение целиков в RGB, а потом преобразовывать в grayscale накладно с точки зрения затрат памяти.

syomin
()
Ответ на: комментарий от svu

> Поведение предсказуемо, с т.зр. языка - вызов метода дочернего класса.

вообще-то это как минимум - нарушение принципов ооп - я вынужден знать детали реализации. и всегда расширяя класс просматривать всю иерархию - на предмет: "не дай гоcподи задеть что либо"

> Опять-таки, если весь из себя финальный метод m1 (используемый часто, в т.ч в конструкторе) вызывает из себя виртуальный m2 - что Вы (точнее автор рекомендации) предлагаете делать, создавать его копию m1f (использующий финальный m2f, который будет копией m2)?

просто не ожидал от явы такого откровенно ляпа. Если бы я делал яву - я бы изменил поведение.

> При том что семантически будет вполне приемлемо вызвать m2 даже в конструкторе (например, он ваще не использует данные производного класса - бывает же такое)?

семантически нет - вы вызываете метод несуществующего еще объекта
то, что вы описываете - это частный случай (называется - повезло)

> Если уж мы перешли на личные примеры - я сам в молодости пару раз наступал именно на плюсовые грабли

насколько я понял, проблемы с плюсами у людей бывают из-за недопонимания того, почему С - "абстрактный(переносимый) ассемблер", когда вы поймете почему он так называется, сразу станет понятным и поведение плюсов, кстати до сих пор не могу понять, что может быть не понятного в такой вещи как указатель :)

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

в сишном. могу воспроизвести вызов методов потомка из родителя. На каком этапе ? - первом, компиляции.

> Особенно если вызов виртуальной функции осуществляется не прямо из конструктора, а где-то во глубине стека?

всю иерархию придется модифицировать

> (в Вашем определении) становится практически бессмысленным - любая (почти?) объектная модель объявляется в реальности совместимой с плюсовой,

не не любая - хаскелевскую, например - невозможно

> поскольку плюсы всегда могут "скатиться" на уровень плоского С и сделать все врукопашную.

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

> Если при этом в плюсах еще и запретят объекты на стеке строить,

хм, сделать так-же нелогично как в яве ?
не будет такого :) хотя бы потому что у плюсов есть две формы оператора new :) И это не противоречит объектной модели :) даже наооборот следует из нее :), а в яве, например, - здесь дыра в объектной модели. Кстати ни один императивный язык не может быть построен без такой штуки как стек (функциональный кстати так-же, но могут быть нюансы :)

ну я бы, например, отказался бы от void* так как наличие такой вещи
ломает объектную модель. или изменил бы ее на форму some*, что наверное лучше. модифицировать union, заменить typeid на typeof ...

> Ага, и байткод туда еще (шутка;)
кстати, чем ассемблер не байт код ? (шутка :)

anonymous
()

надоело мне высказывание C проще экспортировать в скриптовые языки чем c++
давайте произведем разбор полета
в качестве скриптового языка возьмем python

экспорт модулей - в обоих случаях пишем одно и то-же
экспорт функций - в обоих случаях пишем одно и то-же
экспорт объектов:
ни у С ни у с++ не аналога PyObject
в обоих случаях пишем обертку чуть ли не кальку друг друга
экспорт методов:
аналогично чуть ли не эквивалентные обертки

ну и ?
зачем врать что C - проще ?
если для с++ есть например boost.python который позволяет автоматизировать трансляцию PyObject<->MyObject
???

anonymous
()
Ответ на: комментарий от anonymous

> просто не ожидал от явы такого откровенно ляпа. Если бы я делал яву - я бы изменил поведение.

С точностью до наоборот. Это как раз таки был ляп Страуструпа - нарушение полиморфизма внутри сишного конструктора. На эту тему должно быть много написано у создателей Java или в туториалах. Еще играет значение, что у переменных в Java есть всегда значения по-умолчанию. Поэтому явовский код работает очень предсказуемо внутри конструкторов независимо от того, что вы тут написали. Спорить здесь на ЛОРе бессмысленно. И не стоит кидаться такими голословными утверждениями. Просто svu очень интеллигентый человек, и я очень часто поражаюсь его терпению ;)

SDE
()
Ответ на: комментарий от SDE

> С точностью до наоборот. Это как раз таки был ляп Страуструпа

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

--- у вас кишка тонка критиковать страуструпа
--- смешно, всякая шваль мнит себя способной критиковать вещи даже объем которых она даже представить не может,
--- моська лающая на слона

> - нарушение полиморфизма внутри сишного конструктора.

а вот это - идиотизм: конструктор не может быть полиморфным
конструктор создает именно _этот_ объект - это его задача, смысл его существования, если хотите.

> На эту тему должно быть много написано у создателей Java или в туториалах.

да написанно - извинение

> Еще играет значение, что у переменных в Java есть всегда значения по-умолчанию.

вы плюсы знаете ? так каково хрена вы критикуете то, о чем представление не имеете ?

> Поэтому явовский код работает очень предсказуемо внутри конструкторов

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

> Спорить здесь на ЛОРе бессмысленно. И не стоит кидаться такими голословными утверждениями. Просто svu очень интеллигентый человек, и я очень часто поражаюсь его терпению ;)

у нас обоих есть желание поболтать

anonymous
()
Ответ на: комментарий от anonymous

> вообще-то это как минимум - нарушение принципов ооп - я вынужден знать детали реализации

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

> просто не ожидал от явы такого откровенно ляпа.

Просто у нас разные ожидания. В плюсах понятно, почему так нельзя - действительно конструкторы вызываются по мере создания объекта (и vtbl формируется "между вызовами конструкторов"). В жабе объект с умолчательными значениями формируется сразу, до вызова первого конструктора - соотв. и логика работы конструктора другая. Я не считаю это ляпом - это просто другая логика (и, пожалуй, мне более понятная - наверное, потому что я наступал на грабли в плюсах а не в жабе;).

> в сишном. могу воспроизвести вызов методов потомка из родителя. На каком этапе ? - первом, компиляции.

Как Вы собираетесь это реализовывать? Фактически, все методы должны получить добавление в сигнатуру - флаг, указывающий наличие виртуальных вызовов внутри (рекурсивно, разумеется). И вумный линкер должен следить за этим флагом для всех функций, вызываемых из конструктора. И ругаться, если он установлен. Не много ль геморрою? И ради этого менять стандартный униховый линкер? Нафиг-нафиг.

> не не любая - хаскелевскую, например - невозможно

Ок, именно для этих случаев я написал "почти". Честно скажу - с хаскелем знаком исключительно шапочно, так что верю на слово.

> Кстати ни один императивный язык не может быть построен без такой штуки как стек

Совершенно согласен. Но ИМХО в стеке место только переменным ("указателям") - но не объектам. В плюсах из-за этого тоже бывают грабли при поддержке, причем очень часто. Наивысший взлет - мышиная возня с передачей объектов по значению и возвратом их же. Это ж титаническая работа с кучей конструкторов-деструкторов! И если программер случайно о ней забыл (или забыл написать закорючку &) - он огребает.

Да, замечание про void* - тоже очень правильное. И Вы еще негодовали на мое "недоОО"!;) Опять же, рефлексию полноценную, и уже без оглядки на совместимость с С добавили бы...

> кстати, чем ассемблер не байт код ? (шутка :)

Если ассемблер кросс-платформенный - не вижу разницы с байткодом;) Что-нибудь типа http://www.bestuff.com/html/mirrors/javaa/

svu ★★★★★
()
Ответ на: комментарий от anonymous

Похоже, что ты просто не понимаешь как работают конструкторы в Java (они вызываются как обычные методы _после_ создания объекта). А хамить не стоит, тем более, незнакомому человеку. Дальнейший разговор с хамом не имеет смысла.

SDE
()
Ответ на: комментарий от svu

> Зачем??? Если есть некий метод в базовом классе, с ним ассоциирована какая-то семантика. и т.д.

пример:
существует класс Car с методом move (position)
существует класс наследник Car : CarWithTrailer который переопределяет метод move что бы еще и прицеп двигать
все ясно и отчетливо, до тех пор пока Car не воспользуется в конструкторе методом move - каким прицепом он будет двигать ?
а теперь вопрос откуда я знаю что в конструкторе Car не используется какой либо другой метод не зная о его (конструкторе) реализации ?
это ляп явы

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

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

> Как Вы собираетесь это реализовывать? Фактически, ....

что то вы намутили кошмарное, что мне мешает просто позвать конструктор ?

> Наивысший взлет - мышиная возня с передачей объектов по значению и возвратом их же. Это ж титаническая работа с кучей конструкторов-деструкторов!

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

> Но ИМХО в стеке место только переменным ("указателям") - но не объектам.

а указатели не есть объекты ? хотите продырявить объектную модель ?

> И если программер случайно о ней забыл (или забыл написать закорючку &)

случайно о ней забыл ? он типа идиот ? это совершенно разные семантические действия - передача самого объекта и передача его копии

а int в яве предается по значению или по ссылке ? дырка в объектной модели ?

> Да, замечание про void* - тоже очень правильное. И Вы еще негодовали на мое "недоОО"

наличие void* не изменяет объектной модели, наличие void* запрещает typeof, чего и так нет, что бы добавить typeof надо как минимум изменить линкер, а значит изменить операционную систему




anonymous
()
Ответ на: комментарий от SDE

> они вызываются как обычные методы _после_ создания объекта

так кто-же конструирует объект ? коструктор ? семантическая дырка в яве ?

anonymous
()
Ответ на: комментарий от svu

> Если ассемблер кросс-платформенный - не вижу разницы с байткодом;)

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

anonymous
()
Ответ на: комментарий от anonymous

> до тех пор пока Car не воспользуется в конструкторе методом move

А зачем в конструкторе делать move, Вам же нужно только построить автомобиль? Зато если в конструкторе захочется logger.info("Creating" + this.toString()) - получится вывести информацию о конечном объекте (со значениями полей по умолчанию), а не о каком-то недостроенном огрызке.

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

> кстати, в плюсах же способ инициализации внутреннего состояния вы можете выбрать ....

Возможно, это появилось после моего прощания с плюсами. Где почитать?

> что то вы намутили кошмарное, что мне мешает просто позвать конструктор ?

Что-то я потерял нить. Я правильно понял, что Вы хотите компилятором отслеживать вызовы виртуальных методов в конструкторе (или в любом методе, вызываемом прямо или непрямо из конструктора)? Или мы о чем-то другом?

> он типа идиот ?

Ерраре гуманум ест.

> а указатели не есть объекты ? хотите продырявить объектную модель ?

Слово "указатель" у меня в кавычках. На самом деле - это переменные. Конечно, на уровне языка - никаких указателей. Так вот в стеке место только переменным, но никак не объектам.

> а int в яве предается по значению или по ссылке ? дырка в объектной модели ?

Примитивные типы - да, дырка. Автобоксинг вешает на эту дырку картинку - но дырка остается...

> что бы добавить typeof надо как минимум изменить линкер, а значит изменить операционную систему

В общем, тогда плюсы плавно перелезут в до-диез.

svu ★★★★★
()
Ответ на: комментарий от anonymous

> я ассемблер могу выполнить на любой платформе .... так почему ассемблер не байткод ?

Если у Вас ТАКОЙ ассемблер - тогда, конечно, он эквивалентен байткоду. Только старый добрый асм x86 вряд ли на эту роль сгодится...

svu ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.