Программизм

> Странные цифры. Мне кажется, что Вы забыли, что рассматриваются гуепрограммы, а не все программы.

А что из перечисленного по Вашему не может/не должна делать гуишная программа?

>непонятно

Всё просто. Линкуется - не морда, не линкуется - морда. cdrecord - программа, xmpp - библиотека.

>Хм, а зачем в мессенджере exp10?

Это пример платформозависимой функции

>Быстрее GUI работает - запускается быстрее - вообщем самая натуральная морда для мощных консольных программ.

Посмотрел скрины. Если судить о сложности (количестве кода), то оно гораздо проще k3b, поэтому и быстрее. k3b уже успел обрасти всякими свиристелками, потому и медленнее.

>> Парсинг производится последовательно, потому тут особых тормозов не будет. Другое дело то, что интерпретатор небыстро загружается.

> Но всё равно их будет больше, чем исполнение готового бинарного кода.

Да. Но для гуёвой мордочки для cdrecord/wodim, которой является широко используемый в дискуссии k3b, эти затраты несущественны.

> В с++ тоже есть конструкции try{}, catch{}, assert() и отладчик, например gdb.

Знаю. И давно try-catch научился ловить сегфолты?

> В общем затраты в любом случае будут те же.

Всё зависит от уровня риска. Со скриптами можно рисковать сильнее.

>> Странные цифры. Мне кажется, что Вы забыли, что рассматриваются гуепрограммы, а не все программы.

> А что из перечисленного по Вашему не может/не должна делать гуишная программа?

> программы работающие с железом
На примере того же комплекса k3b, подпрограммой, работающей с железом будет cdrecord. Причём, такое разделение позволит написать для воинствующих тулкитофобов две одинаковые по функциональности мордочки.

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

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

> cdrecord - программа, xmpp - библиотека.

xmpp - это протокол :)

>> Хм, а зачем в мессенджере exp10?

> Это пример платформозависимой функции

Ну так она реализована в glibc, так что для писателей прикладного софта она выглядит как платформенно-независимая.

>И давно try-catch научился ловить сегфолты?

У меня лет 10 назад, это плохо ? ;)

> Да. Но для гуёвой мордочки для cdrecord/wodim, которой является широко используемый в дискуссии k3b, эти затраты несущественны.

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

> Знаю. И давно try-catch научился ловить сегфолты?

gdb нормально их ловит. Вот только в случае простенькой мордочки их и не должно быть по определению. Память выделяется в конструкторе, а освобождается в деструкторе или автоматом, как это сделано в qt.

>На примере того же комплекса k3b, подпрограммой, работающей с железом будет cdrecord.

k3b также работает с железом, минуя cdrecord.

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

Это уж кому как нравится, на выбор программиста, так сказать.

> xmpp - это протокол :)

А это что? http://code.google.com/p/libxmpp/

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

И горе тому, кто захочет скомпилить этот код под freebsd :)

> Вполне можно проигрывать звук через mplayer, запущенный в фоне.

А можно через libxine, который линкуется с программой.

>> И давно try-catch научился ловить сегфолты?

> У меня лет 10 назад, это плохо ? ;)

Примерчик можно?

>> Да. Но для гуёвой мордочки для cdrecord/wodim, которой является широко используемый в дискуссии k3b, эти затраты несущественны.

> Для одной программы, а если это куча программ, вроде kde, то затраты будут заметны.

Не вижу, откуда это может взяться. Или же британские учёные уже вывели многопоточного пользователя?

>> Знаю. И давно try-catch научился ловить сегфолты?

> gdb нормально их ловит.

В run-time?

> Вот только в случае простенькой мордочки их и не должно быть по определению. Память выделяется в конструкторе, а освобождается в деструкторе или автоматом, как это сделано в qt.

А выход за пределы массива кто должет отслеживать? qt? Или c++?

>> На примере того же комплекса k3b, подпрограммой, работающей с железом будет cdrecord.

> k3b также работает с железом, минуя cdrecord.

Это минус авторам k3b. Причём здоровенный.

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

> Это уж кому как нравится, на выбор программиста, так сказать.

Конечно на выбор, но существует общепринятый в некоторой среде принцип "unix way".

>> xmpp - это протокол :)

> А это что? http://code.google.com/p/libxmpp/

Это либа для работы с протоколом.

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

> И горе тому, кто захочет скомпилить этот код под freebsd :)

Горе тому, кто использует freebsd :)

>> Вполне можно проигрывать звук через mplayer, запущенный в фоне.

> А можно через libxine, который линкуется с программой.

! unix_way

> Знаю. И давно try-catch научился ловить сегфолты?

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

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

но меня одно только потревожило... я за емакс:)

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

Время парсинга кода, умноженной на колиство программ.

> В run-time?

легко

> Это минус авторам k3b. Причём здоровенный.

Как сказать, это продиктовано тем, что cdrecord не имеет нужной функциональности, поэтому её приходится расширять.

> А выход за пределы массива кто должет отслеживать? qt? Или c++?

Оператор if, или, если заранее не известен размер, realloc и QList решают.

>Конечно на выбор, но существует общепринятый в некоторой среде принцип "unix way".

Юниксвэй это понятие растяжимое. В любом случае быстрей работать с библиотекой, чем дёргать программу через pipe.

> Это либа для работы с протоколом.

Я и имел в смысле либу.

> Горе тому, кто использует freebsd :)

Ни кто не мешает протестировать и написать что вроде этого:

#ifdef Q_OS_FREEBSD m_max += 9 * (int) pow(10,i); #else m_max += 9 * (int) exp10(i); #endif

> ! unix_way

А это плохо? Уж куда проще работать с библиотекой, чем перехватывать вывод через stdout

>> Знаю. И давно try-catch научился ловить сегфолты?

> Чтоб не было сегфолтов надо грамотно писать код, делать проверки и расставлять ассерты на все входящие параметры, чтоб проблема могла быть обнаружена еще на стадии тестирования,

Да.

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

Не защита от сегфолта, а реакция на него. Показать окошко "извините, всё упало" гораздо более user-friendly, чем просто пропасть с экрана(напоминаю, что разговор идёт про гуеподелки).

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

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

Время парсинга кода, умноженной на колиство программ.

>> В run-time?

> легко

И как же?

>> Это минус авторам k3b. Причём здоровенный.

> Как сказать, это продиктовано тем, что cdrecord не имеет нужной функциональности, поэтому её приходится расширять.

И зачем тянуть это в гуй? Там, где проводится считывание образа диска, они тупо переписали dd, определение скоростей - тупо переписанный eject. И если у cdrecorda нет нужной функциональности, почему бы не добавить её именно в cdrecord, а не вписывать в гуй?

>> А выход за пределы массива кто должет отслеживать? qt? Или c++?

> Оператор if, или, если заранее не известен размер, realloc и QList решают.

Одна из версий игрушки knetload вываливалась у меня, ругаясь на какую-то ошибку, связанную с qlist. Вроде как раз "array index out of bounds". Криворуксоти все программисты подвержены(в разной степени), и никакие крутые qlist-ы от ней не спасут.

>>Конечно на выбор, но существует общепринятый в некоторой среде принцип "unix way".

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

Нет. Ознакомьтесь с вопросом: http://ru.wikipedia.org/wiki/%D0%A4%D0%B8%D0%BB%D0%BE%D1%81%D0%BE%D1%84%D0%B8...

> И как же?

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

> И зачем тянуть это в гуй? Там, где проводится считывание образа диска, они тупо переписали dd, определение скоростей - тупо переписанный eject. И если у cdrecorda нет нужной функциональности, почему бы не добавить её именно в cdrecord, а не вписывать в гуй?

На то есть куча причин, например поддержка того-же hal или распознавание болванок. Да и egect не всегда делает это правильно по мнению авторов.

> Одна из версий игрушки knetload вываливалась у меня, ругаясь на какую-то ошибку, связанную с qlist. Вроде как раз "array index out of bounds". Криворуксоти все программисты подвержены(в разной степени), и никакие крутые qlist-ы от ней не спасут.

А чем спасут контейнеры tcl ? или что там?

> Нет. Ознакомьтесь с вопросом:

Про скорость там ничего не написано, так же ffmpeg, mad, curl существуют в виде программ, однако в mplayer используются только их библиотеки (да и не только в нём)

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

И кто же её мешает включить в другие программы? лень?

>> И как же?

> Аналогично, выводится сообщение, что программа упала, и покажет последнюю функцию.

Не всегда. Я, бывало, память так портил, что стектрейс не выводился :)

Да и выведено это будет в stderr, а не в графическое окошко.

>> И зачем тянуть это в гуй?

> На то есть куча причин, например поддержка того-же hal или распознавание болванок. Да и egect не всегда делает это правильно по мнению авторов.

И вместо того, чтобы улучшить eject или вынести функциональность в отдельный утиль, они сделали это в гуе. Виват, велосипедоизобретателям!

>> Одна из версий игрушки knetload вываливалась у меня, ругаясь на какую-то ошибку, связанную с qlist. Вроде как раз "array index out of bounds". Криворуксоти все программисты подвержены(в разной степени), и никакие крутые qlist-ы от ней не спасут.

> А чем спасут контейнеры tcl ? или что там?

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

>> Нет. Ознакомьтесь с вопросом:

> Про скорость там ничего не написано, так же ffmpeg, mad, curl существуют в виде программ, однако в mplayer используются только их библиотеки (да и не только в нём)

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

P.S. Кстати, я вспомнил, что для Tcl существуют runtime компиляторы, так что аргументы про тормозность парсинга снижают свою значимость.

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

> И кто же её мешает включить в другие программы? лень?

Честно говоря, не знаю. Правда в кедах есть свой собственный обработчик SIGSEGV, который работает при крахе приложения. Правда при отрезанной debug info он не помогает.

> Не всегда. Я, бывало, память так портил, что стектрейс не выводился :)

Пример в студию!! :)

> Да и выведено это будет в stderr, а не в графическое окошко.

> И вместо того, чтобы улучшить eject или вынести функциональность в отдельный утиль, они сделали это в гуе. Виват, велосипедоизобретателям!

Иногда это невозможно реализовать из-за религиозных причин.

> Да и выведено это будет в stderr, а не в графическое окошко.

Заюзать фронтенд не проблема, да ещё при таких убеждениях :)

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

А try, catch чем не угодил?

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

Вот только он линкуется ещё и с gtk, так что если мне надо будет заюзать морду на qt, то gtk всё равно придётся ставить в нагрузку. Так что ни каким юниксвеем даже и не пахнет.

> P.S. Кстати, я вспомнил, что для Tcl существуют runtime компиляторы, так что аргументы про тормозность парсинга снижают свою значимость.

Всё равно это же время будет затрачено на загрузку приложения. Куча циклов будет уходить на компиляцию при _каждом_ запуске.

> Честно говоря, не знаю. Правда в кедах есть свой собственный обработчик SIGSEGV, который работает при крахе приложения. Правда при отрезанной debug info он не помогает.

В любом случае это не проблема, т.к. эта информация нужна только разработчику, да и пересобрать при желании можно.

>> Не всегда. Я, бывало, память так портил, что стектрейс не выводился :)

> Пример в студию!! :)

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

>> И вместо того, чтобы улучшить eject или вынести функциональность в отдельный утиль, они сделали это в гуе. Виват, велосипедоизобретателям!

> Иногда это невозможно реализовать из-за религиозных причин.

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

>> Да и выведено это будет в stderr, а не в графическое окошко.

> Заюзать фронтенд не проблема, да ещё при таких убеждениях :)

Пардон, фронтенд к графическому фронтенду?

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

> А try, catch чем не угодил?

Он умеет ловить сегфолты? Мне так и не показали примера, как try-catch в c++ поймает неинициализированный указатель или выход за пределы массива.

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

> Вот только он линкуется ещё и с gtk, так что если мне надо будет заюзать морду на qt, то gtk всё равно придётся ставить в нагрузку. Так что ни каким юниксвеем даже и не пахнет.

В зависомостях пакета есть gtk потому, что туда обычно включают gmplayer - gtk-шную морду. Пинайте мантайнеров своего дистриба, чтобы поделили на 2 пакета.

>> P.S. Кстати, я вспомнил, что для Tcl существуют runtime компиляторы, так что аргументы про тормозность парсинга снижают свою значимость.

> Всё равно это же время будет затрачено на загрузку приложения. Куча циклов будет уходить на компиляцию при _каждом_ запуске.

А при запуске динамически слинкованого приложения загрузчик тоде проводит некоторую интерпретацию, предзагрузку библиотек и т.д. Что, теперь юзать только статическую линковку?

Если современное гуеприложение на qt запускается и работает также медленно, как и tk-поделка, то зачем мне связываться с плюсами и qt, если я могу легко склепать такой же быстрый фронтенд на интерпретируемом языке?

>> Честно говоря, не знаю. Правда в кедах есть свой собственный обработчик SIGSEGV, который работает при крахе приложения. Правда при отрезанной debug info он не помогает.

> В любом случае это не проблема, т.к. эта информация нужна только разработчику, да и пересобрать при желании можно.

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

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

Два раза вызвать delete - это надо ещё умудриться :) Вот только gdb у меня такие ситуации отрабатывает. Впрочем для этого он и предназначен ::))

> Ну да, некоторые свинину не едят по религиозным причинам... Но вроде разбиение на отдельные утилиты признано кошерным :)

Если бы этих причин не было, то каждая программа линковалась бы с ядром на каждый чих, однако все стараются убрать как можно больше в user-space. ЗЫ у меня у меня 2-а привода LG и ТЕAK, и не в одном скорость нормально не определяется (я про eject).

>Пардон, фронтенд к графическому фронтенду?

Фронтенд к gdb, если уж так требуется вывод в окошке :)

> В зависомостях пакета есть gtk потому, что туда обычно включают gmplayer - gtk-шную морду. Пинайте мантайнеров своего дистриба, чтобы поделили на 2 пакета.

Оно и так поделено, вот только gmplayer есть симлинк на mplayer, а сам пакет содержит только скин к нему.

> А при запуске динамически слинкованого приложения загрузчик тоде проводит некоторую интерпретацию, предзагрузку библиотек и т.д. Что, теперь юзать только статическую линковку?

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

> Если современное гуеприложение на qt запускается и работает также медленно, как и tk-поделка, то зачем мне связываться с плюсами и qt, если я могу легко склепать такой же быстрый фронтенд на интерпретируемом языке?

Не факт, что медленно. Вот у меня наоборот, быстрее в силу объективных причин, которые я привёл выше.

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

Пользователю достаточно сообщить последовательность действий, вызвавший сегфолт, а остальное дело техники.

> Он умеет ловить сегфолты? Мне так и не показали примера, как try-catch в c++ поймает неинициализированный указатель или выход за пределы массива.

int main() { char *zero = NULL; try { zero[0] = 'a'; } catch() { std::cout <<"Catch!" <<std::endl; } return(0); }

А вообще, в случа гуйков QPointer решает.

А в для случая выхода за пределы массива есть QList и оператор if()

> Два раза вызвать delete - это надо ещё умудриться :) Вот только gdb у меня такие ситуации отрабатывает. Впрочем для этого он и предназначен ::))

Я никак в толк не возьму: Вы про момент отладки или про работу программы у конечного пользователя?

> gmplayer есть симлинк на mplayer

Кошмар :(

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

> Не факт, что медленно. Вот у меня наоборот, быстрее в силу объективных причин, которые я привёл выше.

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

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

> Пользователю достаточно сообщить последовательность действий, вызвавший сегфолт, а остальное дело техники.

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

> Он умеет ловить сегфолты? Мне так и не показали примера, как try-catch в c++ поймает неинициализированный указатель или выход за пределы массива.

> int main() ...

Посмотрим-с...

> А вообще, в случа гуйков QPointer решает.

QPointer - это жуткий костыль, призванный сделать работу с указателями на C++ похожей на Java. Если частенько приходится использовать QPointer или смартпоинтер - это первый звоночек о том, что неправильно выбран язык.

> Я никак в толк не возьму: Вы про момент отладки или про работу программы у конечного пользователя?

про отладку, конечно :)

> Кошмар :(

Суровая реальность, вот только tcl в этом случае тоже не панацея.

> Ну ладно, тут уж на теоретическом уровне ничего не решишь...

Тогда надо написать и померить...

> Вы никогда не сталкивались с "наведёнными" ошибками? Т.е. когда причина в каком-то совершенно не связанном действии. Такие ошибки несложно допустить, но отладить их на C или С++ порой весьма затруднительно.

Вот представьте себе, ни разу. Любая ошибка есть результат _определённой_ последовательности действий, а возмущения вакуума на исполнение программы влиять не могут. Конечно, я исключаю кривое железо, где на исполнение программы может повлиять температура.

> QPointer - это жуткий костыль, призванный сделать работу с указателями на C++ похожей на Java. Если частенько приходится использовать QPointer или смартпоинтер - это первый звоночек о том, что неправильно выбран язык.

А как отличить костыль от некостыля? Если досконально разобраться, то любое изделие ИТ "промышленности" является системой костылей и подпорок.

>> Я никак в толк не возьму: Вы про момент отладки или про работу программы у конечного пользователя?

> про отладку, конечно :)

ну а я про то, что будет у пользователя.

>> Кошмар :(

> Суровая реальность, вот только tcl в этом случае тоже не панацея.

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

>> Ну ладно, тут уж на теоретическом уровне ничего не решишь...

> Тогда надо написать и померить...

для всех возможных типов программ!? =8-)

>> Вы никогда не сталкивались с "наведёнными" ошибками? Т.е. когда причина в каком-то совершенно не связанном действии. Такие ошибки несложно допустить, но отладить их на C или С++ порой весьма затруднительно.

> Вот представьте себе, ни разу. Любая ошибка есть результат _определённой_ последовательности действий, а возмущения вакуума на исполнение программы влиять не могут.

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

> ну а я про то, что будет у пользователя.

Вопрос в том, кто мешает пользователю запустить gdb и отправить вызов функций автору? Если это не по силам, то вряд ли такой пользователь будет способен зайти на сайт и открыть баг в багзиле.

> он выведет красивое окошко, что что-то йопнулось. с подробным стектрейсом

gdb не устраивает из-за отсутствия окошка, ну тогда kdbg :)

> для всех возможных типов программ!? =8-)

Зачем для всех, достаточно для нескольких. Надеюсь уж найдётся пара-тройка уже готовых аналогов программ на qt c++, причём при одинаковой сложности обеих. Я также не учитываю, что tk виджеты гораздо проще.

> Повезло. Такие ошибки(особенно, если действий была уйма) очень и очень сложно править.

При написании гуи-поделок такая ситуация вообще не возникнет. Вот смотрю диалог настроек на Qt, так там даже нет ни одного delete. Найти причину падения гораздо проще, чем причину банального зависания.

>> ну а я про то, что будет у пользователя.

> Вопрос в том, кто мешает пользователю запустить gdb и отправить вызов функций автору? Если это не по силам, то вряд ли такой пользователь будет способен зайти на сайт и открыть баг в багзиле.

Лень. Мне постоянно мешает делать подобное. Потому скрипты фикшу ручками, а глючные бинарные поделки игнорирую, потому что особо не припирает.

>> он выведет красивое окошко, что что-то йопнулось. с подробным стектрейсом

> gdb не устраивает из-за отсутствия окошка, ну тогда kdbg :)

Мне лень запускать gdb. И подозреваю, что не только мне.

>> для всех возможных типов программ!? =8-)

> Зачем для всех, достаточно для нескольких. Надеюсь уж найдётся пара-тройка уже готовых аналогов программ на qt c++, причём при одинаковой сложности обеих. Я также не учитываю, что tk виджеты гораздо проще.

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

>> Повезло. Такие ошибки(особенно, если действий была уйма) очень и очень сложно править.

> При написании гуи-поделок такая ситуация вообще не возникнет. Вот смотрю диалог настроек на Qt, так там даже нет ни одного delete. Найти причину падения гораздо проще, чем причину банального зависания.

Рисовалка блок-схем - не гуеподелка? В ней вполне можно наделать багов с памятью, делая каждый блок объектом. Так что не стоит судить так категорично.

> Лень. Мне постоянно мешает делать подобное. Потому скрипты фикшу ручками, а глючные бинарные поделки игнорирую, потому что особо не припирает.

можно подумать, что все консольные программы эталон надёжности и не являются "бинарными поделками". Кто им мешает сегфолтнуться?

> Мне лень запускать gdb. И подозреваю, что не только мне.

Это не аргумент. С таким же успехом я могу сказать, что мне лень ставить что-то отличное от с++ qt :)

> Ну допустим, что найдутся недалеко разошедшиеся аналоги. Но как оценить производительность гуёвой поделки?

Время загрузки, пожирание памяти, скорость отрисовки.

> Рисовалка блок-схем - не гуеподелка? В ней вполне можно наделать багов с памятью, делая каждый блок объектом. Так что не стоит судить так категорично.

гуепаделка, а что же ещё? Есть более сложные проекты, которые не падают. Так что не вижу повода, почему рисовалка блок-схем _должна_ падать. Если только специально добиться этого эффекта :) ЗЫ: специально зашёл на qt-apps и скомпилил 10 программ с самым выскоим рейтингом, падений не обнаружил и это при том, что некоторые из них посложней простых фронтэндов.

> можно подумать, что все консольные программы эталон надёжности и не являются "бинарными поделками". Кто им мешает сегфолтнуться?

У неинтерактивных программ тупая линейная логика, а не event-driven, как в гуеподелках. Соответственно, разрабатывать и отладивать несравненно легче.

>> Ну допустим, что найдутся недалеко разошедшиеся аналоги. Но как оценить производительность гуёвой поделки?

> Время загрузки,

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

> пожирание памяти, скорость отрисовки.

А это как объективно оценить? С tk-программой вроде ясно, а как быть с qt-шной? Как считать динамические библиотеки?

> Рисовалка блок-схем - не гуеподелка? В ней вполне можно наделать багов с памятью, делая каждый блок объектом. Так что не стоит судить так категорично.

> гуепаделка, а что же ещё? Есть более сложные проекты, которые не падают. Так что не вижу повода, почему рисовалка блок-схем _должна_ падать.

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

> У неинтерактивных программ тупая линейная логика, а не event-driven, как в гуеподелках. Соответственно, разрабатывать и отладивать несравненно легче.

А как насчёт graphviz? там тоже тупая логика? А в qt есть сигналы-слоты для работы между интерфейсом и потоками. Событиями уже ни кто не пользуется.

> И как это отследить? Вызвать перед запуском date, потом в первой строчке программы? Увы, на современных машинах это делается настолько быстро, что так легко не заметишь разницу.

А если взять гуй посложней? Вот только пока я не обнаружил ничего сложного на tk :( Тот же tkdvd представляет собой одно окошко с кнопками.

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

Если при открытии одного файла портится другой, то это уже другой разговор. Значит этот горе-программист до конца не разбирается в работе своей программы. И нет гарантий, что эта поделка не очистит мне /home от "ненужных" файлов.

>> У неинтерактивных программ тупая линейная логика, а не event-driven, как в гуеподелках. Соответственно, разрабатывать и отладивать несравненно легче.

> А как насчёт graphviz? там тоже тупая логика?

Он хорошо отлажен.

> А в qt есть сигналы-слоты для работы между интерфейсом и потоками. Событиями уже ни кто не пользуется.

Чудные вы, анонимусы... Event-driven дизайн X-ов(да и оффтопичного оконного API) никуда не делся. Он только прикрыт qt-шными классами.

>> И как это отследить? Вызвать перед запуском date, потом в первой строчке программы? Увы, на современных машинах это делается настолько быстро, что так легко не заметишь разницу.

> А если взять гуй посложней? Вот только пока я не обнаружил ничего сложного на tk :( Тот же tkdvd представляет собой одно окошко с кнопками.

Советую посмотреть tkabber. И ещё есть достаточное количество проприетарных поделок, где гуй сделан на tk.

Но любой tk-гуй прост, так как гуй-это только гуй, функциональность из него вынесена. Причём вынести её можно хоть в c или c++ - библиотека tclx рулит.

> Если при открытии одного файла портится другой, то это уже другой разговор. Значит этот горе-программист до конца не разбирается в работе своей программы. И нет гарантий, что эта поделка не очистит мне /home от "ненужных" файлов.

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

> Он хорошо отлажен.

Как и куча других программ на с, c++ 85% которых являются мордами к какой-нибудь программе или библиотеке.

> Чудные вы, анонимусы... Event-driven дизайн X-ов(да и оффтопичного оконного API) никуда не делся. Он только прикрыт qt-шными классами.

Согласитесь, жёсткий реалтайм тут не нужен так что все вопросы вывода инфы на гуй можно решить с помощью сигналов-слотов. От такой низкоуровневой операции, как обработка событий, можно легко абстрагироваться. ЗЫ: есть рабочий пример, где имеется 3 независимых потока и происходит вывод информации на главное окно, причём не использовано ни одного mutex-а, а только сигналы и слоты.

> Но любой tk-гуй прост, так как гуй-это только гуй, функциональность из него вынесена. Причём вынести её можно хоть в c или c++ - библиотека tclx рулит.

А вдруг у консольной тулзы не хватит функционала? Вдруг надо будет реализовать его с помощью сторонней библиотеки?

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

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

> Советую посмотреть tkabber. И ещё есть достаточное количество проприетарных поделок, где гуй сделан на tk.

Хорошо, посмотрю :)

>> Он хорошо отлажен.

> Как и куча других программ на с, c++ 85% которых являются мордами к какой-нибудь программе или библиотеке.

На отладку программы на адекватном языке уходит меньше времени. ДЛя гуёв tk над tcl - самый адекватный язык на адекватном тулките. Будет что-то подобное, но компилируемое - с удовольствием использую его.

> есть рабочий пример, где имеется 3 независимых потока и происходит вывод информации на главное окно, причём не использовано ни одного mutex-а, а только сигналы и слоты.

Queued сигналы? Если так, то это самообман - там делается то же самое(mutexes), только без Вашего ведома.

Если без выстроения сигналов в очередь - то это типичная индусоподелка, которая работает в зависимости от уровня воды в Брамапутре :) Потому что race conditions, deadlocks и прочие прелести отсутствия синхронизации.

Кстати, вот ещё один момент, из которого могут вылезти "наведённые" баги: пренережение синхронизацией. И такую ошибку невероятно сложно поймать.

>> Но любой tk-гуй прост, так как гуй-это только гуй, функциональность из него вынесена. Причём вынести её можно хоть в c или c++ - библиотека tclx рулит.

А вдруг у консольной тулзы не хватит функционала? Вдруг надо будет реализовать его с помощью сторонней библиотеки?

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

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

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

> Потому что race conditions, deadlocks и прочие прелести отсутствия синхронизации.

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

>> Но любой tk-гуй прост, так как гуй-это только гуй, функциональность из него вынесена. Причём вынести её можно хоть в c или c++ - библиотека tclx рулит.

> А вдруг у консольной тулзы не хватит функционала? Вдруг надо будет реализовать его с помощью сторонней библиотеки?

И опять недоответил:

И что? Главное - не перебарщивать с библиотеками и не тащить лишнюю функциональность в гуй.

> На отладку программы на адекватном языке уходит меньше времени. ДЛя гуёв tk над tcl - самый адекватный язык на адекватном тулките.

То же самое мне говорят ярые защитники java и mono. Так и кто же прав?

> Queued сигналы? Если так, то это самообман - там делается то же самое(mutexes), только без Вашего ведома.

А уж как там оно там делается, мне знать не обязательно. Главное работает. Если расписать процедуру парсинга и runtime компиляции, то голова тоже заболит он "перенапряга" :)

> Если без выстроения сигналов в очередь - то это типичная индусоподелка, которая работает в зависимости от уровня воды в Брамапутре :)

Очередь там как раз таки есть. queued - по английски "очередь".

> Потому что race conditions, deadlocks и прочие прелести отсутствия синхронизации.

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

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

Скорее реалист, и простых гуйков приходилось клепать приличное количество. Чтобы в программе из 200 строк сделать ошибку, которая бы не ловилась дебагером, надо постараться.

> И что? Главное - не перебарщивать с библиотеками и не тащить лишнюю функциональность в гуй.

Переборщить с библиотеками или консольными программами?

> Недописал: потому что всё перечисленное очень сложно отловить при отладке в дебаггере, это надо ловить по логике работы.

И чем мне тут поможет tcl?

>> На отладку программы на адекватном языке уходит меньше времени. ДЛя гуёв tk над tcl - самый адекватный язык на адекватном тулките.

> То же самое мне говорят ярые защитники java и mono. Так и кто же прав?

Я :)

А если без шуток, то ява-like языки претендуют на универсальность, соответственно пытаются объять необъятное, потому из них получается нечто большое, непонятное, зато с биркой ынтырпрайз. Вот на tk легко пишутся гуи. И всё.

>> Queued сигналы? Если так, то это самообман - там делается то же самое(mutexes), только без Вашего ведома.

> А уж как там оно там делается, мне знать не обязательно. Главное работает.

Главный аргумент быдлокодера.

> Если расписать процедуру парсинга и runtime компиляции, то голова тоже заболит он "перенапряга" :)

Знать, как оно делается надо. А не прочитать одну страничку в qt assistant, где расписано про типы сигнал-слотовых соединений и писать что-то на qt - верх невежества.

>> Если без выстроения сигналов в очередь - то это типичная индусоподелка, которая работает в зависимости от уровня воды в Брамапутре :)

> Очередь там как раз таки есть. queued - по английски "очередь".

Ну так я написал либо используется механизм "queued" или "без выстроения". If-else :)

>> Потому что race conditions, deadlocks и прочие прелести отсутствия синхронизации.

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

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

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

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

> Скорее реалист, и простых гуйков приходилось клепать приличное количество. Чтобы в программе из 200 строк сделать ошибку, которая бы не ловилась дебагером, надо постараться.

Поправьте тогда "вылеты" в amarok, раз имеете столько опыта, который я при Вашем анонимном статусе всё равно проверить не могу.

>> И что? Главное - не перебарщивать с библиотеками и не тащить лишнюю функциональность в гуй.

> Переборщить с библиотеками или консольными программами?

С веществами.

>> Недописал: потому что всё перечисленное очень сложно отловить при отладке в дебаггере, это надо ловить по логике работы.

> И чем мне тут поможет tcl?

Ничем. И никто от кривых рук не поможет, т.к. не надо писать многопоточность без синхронизации.

> А если без шуток, то ява-like языки претендуют на универсальность, соответственно пытаются объять необъятное, потому из них получается нечто большое, непонятное, зато с биркой ынтырпрайз. Вот на tk легко пишутся гуи. И всё.

Гуй-only программы - это сферический конь в вакууме.

> Главный аргумент быдлокодера.

Оскорбление оппонента - главный аргумент при отсутствии аргументов.

> Знать, как оно делается надо. А не прочитать одну страничку в qt assistant, где расписано про типы сигнал-слотовых соединений и писать что-то на qt - верх невежества.

Опять мимо. В qt-assistent не написано, как это происходит на уровне кода.

> Ну так я написал либо используется механизм "queued" или "без выстроения". If-else :)

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

> Незачем тогда было приводить пример про вывод на главное окно без синхронизации, раз всё это не нужно.

Дело в том, что синхронизация тутне нужна. Операции подачи сигналов на главное окно происходят асинхронно.

> Кстати, если выводится на сложный виджет с нетривиальной внутренней структурой, то race вполне может испортить его внутреннее состояние.

Такое никогда не может произойти, если виджет получает данные через слоты с queued connection.

> Поправьте тогда "вылеты" в amarok, раз имеете столько опыта, который я при Вашем анонимном статусе всё равно проверить не могу.

Амарок содержит куда больше 200 строк. Если надо что-то простое, то есть, например, http://qxplayer.org/ , который не падает.

> С веществами.

Опять нехватка аргументов сказывается....

>Ничем. И никто от кривых рук не поможет, т.к. не надо писать многопоточность без синхронизации.

Про ассинхронность, конечно, не в курсе.

>> А если без шуток, то ява-like языки претендуют на универсальность, соответственно пытаются объять необъятное, потому из них получается нечто большое, непонятное, зато с биркой ынтырпрайз. Вот на tk легко пишутся гуи. И всё.

> Гуй-only программы - это сферический конь в вакууме.

tkdvd - сферический конь в вакууме?

>> Главный аргумент быдлокодера.

> Оскорбление оппонента - главный аргумент при отсутствии аргументов.

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

>> Знать, как оно делается надо. А не прочитать одну страничку в qt assistant, где расписано про типы сигнал-слотовых соединений и писать что-то на qt - верх невежества.

> Опять мимо. В qt-assistent не написано, как это происходит на уровне кода.

На уровне кода знать и не надо. Достаточно знать hign-level. Напоминаю Ваши слова про то, что "мне этого знать не надо".

>> Ну так я написал либо используется механизм "queued" или "без выстроения". If-else :)

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

В исходном сообщении про тип соединения сказано не было. Я предложил на выбор 2 варианта: или это queued или это не queued. А Вас куда-то не в ту степь понесло, да ещё мне тыкать стали в перевод слова queued.

>> Незачем тогда было приводить пример про вывод на главное окно без синхронизации, раз всё это не нужно.

> Дело в том, что синхронизация тутне нужна. Операции подачи сигналов на главное окно происходят асинхронно.

Вы действительно считаете, что асинхронные операции не надо синхронизировать?

>> Кстати, если выводится на сложный виджет с нетривиальной внутренней структурой, то race вполне может испортить его внутреннее состояние.

> Такое никогда не может произойти, если виджет получает данные через слоты с queued connection.

Так он их через queued получает или нет? Я уже в течении нескольких сообщений пытаюсь у Вас это выяснить. И если через queued - то там используются mutexes. И об этом знать _надо_.

>> Поправьте тогда "вылеты" в amarok, раз имеете столько опыта, который я при Вашем анонимном статусе всё равно проверить не могу.

> Амарок содержит куда больше 200 строк.

Ну и что? Раз в гуепрограмме нельзя ошибиться, то почему авторы амарока допустили ненулевое количество багов?

> Если надо что-то простое, то есть, например, http://qxplayer.org/ , который не падает.

Безглючных программ практически нет.

>> С веществами.

> Опять нехватка аргументов сказывается....

Нет. Просто я, как ни старался, не понял, что за мысль была написана.

>>Ничем. И никто от кривых рук не поможет, т.к. не надо писать многопоточность без синхронизации.

> Про ассинхронность, конечно, не в курсе.

См. выше.

> tkdvd - сферический конь в вакууме?

Что то на нём маловато программ, да и выглядит оно не особо. Так что пока - конь ::))

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

Я знаю, что процессоры сделаны с использованием кремния. Значит я уже не быдлокодер?

> На уровне кода знать и не надо. Достаточно знать hign-level. Напоминаю Ваши слова про то, что "мне этого знать не надо".

Что бы _написать_ гуй мне необходимо и достаточно достаточно знать QObject::connect(). Это не highlevel? Или нужно что то ещё?

> Так он их через queued получает или нет? Я уже в течении нескольких сообщений пытаюсь у Вас это выяснить.

queued connection используется по дефолту, хотя можно включить direct connection и получить все прелести работы с мутексами ::))

> И если через queued - то там используются mutexes. И об этом знать _надо_.

Они может быть и используются внутри qt. Bот только под словом "знать" я понимаю учёт их в _своём_ коде.

> Ну и что? Раз в гуепрограмме нельзя ошибиться, то почему авторы амарока допустили ненулевое количество багов?

Да это не просто тупая гуепрограмма, а нечто более сложное. Я говорил про простое на 200 строчках.

> Безглючных программ практически нет.

Однако глюки разные бывают...

> Нет. Просто я, как ни старался, не понял, что за мысль была написана.

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