SPTK - C++ библиотека для кросс-платформенной разработки

> Кроме того, SPTK для бизнес-задач оптимальна. Код программы проще и короче. Сопровождение таких программ проще и дешевле. Вам это не надо? Значит у вас нет deadlines для проектов и есть огромная служба поддержки. Тогда SPTK не для вас.

Действительно, не для меня. Не доверяю успешность своих проектов библиотекам, авторы которых разговаривают так, как будто снисходят до нас, грешных. И отделываются общими фразами об уменьшении объема и стоимости.

> Действительно, не для меня. Не доверяю успешность своих проектов библиотекам, авторы которых разговаривают так, как будто снисходят до нас, грешных. И отделываются общими фразами об уменьшении объема и стоимости.

Видите ли, когда в одной молодой американской компании заменили их CRM на базирующуюся на SPTK, кол-во людей в их службе поддержки сократилось в 5 раз, из 7 программистов осталось 2. Быстродействие системы возросло примерно в 3-4 раза. Если вам не нужны аналогичные результаты - значит вы действительно грешны :)

Вообще - я не очень понимаю причины спора. Вы хотите иметь медленные громоздкие проекты на коммерческом тулките? Да ради бога. Хотите иметь компактные и быстрые - тоже пожалуйста. Я всегда выбираю второй путь.

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

Насчет снисхождения. Довольно много постов здесь, в том числе и ваши, содержало просто словесный понос. Было сказано и что темы дерьмо (но никто не предложил и не показал лучшие), и тулкит дерьмо (но не обьяснено почему), и автор здесь не нужен (но 800+ человек все-таки пришли на сайт). Так почему вы хотите, чтобы к вам было нормальное отношение?

Напишите одну и ту же программу на QT, на GTK, и на SPTK. И сравните. Я сделал это для пары проектов, на QT, GTK, и FLTK. После чего и был написан SPTK. Я потратил время не от любопытства - мне нужно было делать большой проект, и нужно было обеспечить и компактность, и сопровождаемость. SPTK это обеспечивает.

> Видите ли, когда в одной молодой американской компании заменили их CRM на базирующуюся на SPTK, кол-во людей в их службе поддержки сократилось в 5 раз, из 7 программистов осталось 2. Быстродействие системы возросло примерно в 3-4 раза. Если вам не нужны аналогичные результаты - значит вы действительно грешны :)

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

Если вы написали свою CRM, которая оказалась удобнее предыдущей -- здорово. Только вот степень влияния SPTK на ее успешность выглядит слишком завышенной.

> Вообще - я не очень понимаю причины спора. Вы хотите иметь медленные громоздкие проекты на коммерческом тулките? Да ради бога. Хотите иметь компактные и быстрые - тоже пожалуйста. Я всегда выбираю второй путь.

Спора пока нет. Есть мои безуспешные попытки выудить из вас хотя бы тезисное перечисление причин, по которым SPTK может оказаться удобнее своих конкурентов. Пока в сухом остатке только:

* SPTK -- целостный тулкит, в одном флаконе которого намешено все, что было нужно _вам_ (т.е. графика, XML, Excel);

* качественная поддержка Excel.

Так же вы декларируете, что SPTK легко расширяем.

Ok. Теперь взглянем на это все с моей точки зрения: * целостность -- отсутствие достаточного набора примитивов синхронизации для многопоточного программирования. Т.е. я себе не представляю, как с помощью SPTK реализовать поддержку producer/consumer взаимодействия с помощью очередей сообщений. Нет ни windows-like event-ов, ни posix-овых condition variable. Упс... А ведь у конкурентов все это есть, и ничего дописывать не нужно; * качественная поддержка Excel -- мимо, мне не нужна; * легкое расширение. Например, поддержка новых БД может быть добавлена самим пользователем SPTK. Я конечно дико извиняюсь, но toolkit мне нужен именно для того, _чтобы я сами ничего не писал_. Опять упс...

Теперь о медленных и быстрых программах. Я уже не первый год программирую чтобы понять, что проектные решения и алгоритмы оказывают гораздо больше влияние на быстродействие и ресурсоемкость программы, чем используемые фреймворки и даже языки программирования. Более того, несколько раз наблюдал, как Java-программы обгоняли C++ программы.

Если сравнивать скорость Qt, FOX и Fltk, то Fltk быстрее всех, но FOX отстает совсем не намного. Qt по сравнению с ними, конечно, тормоз, но даже на нем у нас есть системы on-line мониторинга, которые отображают изменения сотен параметров с загрузкой моего Mobile Pentuim 1.5GHz всего на 35%. И это при том, что различные разработки с помощью Qt мы ведем уже в течении 4-х лет. Интересно бы узнать, в каком виде находился ваш SPTK в то время.

> Насчет снисхождения. Довольно много постов здесь, в том числе и ваши, содержало просто словесный понос. Было сказано и что темы дерьмо (но никто не предложил и не показал лучшие), и тулкит дерьмо (но не обьяснено почему), и автор здесь не нужен (но 800+ человек все-таки пришли на сайт). Так почему вы хотите, чтобы к вам было нормальное отношение?

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

> Напишите одну и ту же программу на QT, на GTK, и на SPTK. И сравните. Я сделал это для пары проектов, на QT, GTK, и FLTK. После чего и был написан SPTK. Я потратил время не от любопытства - мне нужно было делать большой проект, и нужно было обеспечить и компактность, и сопровождаемость. SPTK это обеспечивает.

Есть такой проект Ultimate++, который так же конкурирует с вами. Так его разработчики уже озадачились тем, чтобы _наглядно_ показать, в чем преимущество U++ перед Qt, wxWidgets и Java/SWing, например: http://www.ultimatepp.org/www$uppweb$vswx$en-us.html

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

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

Вы этого впечатления добивались?

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

Это - в анналы. Технология определяет все. Если вы этого не понимаете - дальнейший разговор просто бесполезен.

>* SPTK -- целостный тулкит, в одном флаконе которого намешено все, что было нужно _вам_ (т.е. графика, XML, Excel); >* качественная поддержка Excel.

Вы вообще понимаете примерные потребности бизнесс-программ? Да, это нужно мне. Это также нужно практически любой программе для бизнеса:

- работа с БД, XML, Excel, CGI - для роботов, репорт-генераторов, etc.

- работа с БД, XML, Excel, графикой, потоками - для интерфейсов.

Причем все это должно работать максимально просто. У разработчика не должно быть лишних затрат времени ни на что.

К примеру, http://www.ultimatepp.org/examples$SQLApp.html содержит примерно 400 строк. На SPTK это будет примерно 130 строк (db_list_view.cpp в примерах). Что, все еще не понятно?

> Ok. Теперь взглянем на это все с моей точки зрения: * целостность -- отсутствие достаточного набора примитивов синхронизации для многопоточного программирования. Т.е. я себе не представляю, как с помощью SPTK реализовать поддержку producer/consumer взаимодействия с помощью очередей сообщений.

Вы представляете себе, как это сделать в Windows/*nix/OSX? Отлично, добавьте класс очередь и вперед. Большинству людей, однако, он не нужен.

Примитивы добавляются по мере надобности. То, что есть - покрывает >95% задач. Если вам чего-то не хватает - добавьте. Но иметь в универсальном тулките ВСЕ потенциальные обьекты потоков - просто незачем.

> Нет ни windows-like event-ов, ни posix-овых condition variable. Упс...

Зато гарантируется одинаковое поведение в разных системах. Вам это не надо? Упс..

> А ведь у конкурентов все это есть, и ничего дописывать не нужно; * качественная поддержка Excel -- мимо, мне не нужна;

Этим уже все сказано. Ни одна система управления компанией не обходится без работы с Excel. CRM, HR, генератор отчетов.. Ни одна. Упс..

> * легкое расширение. Например, поддержка новых БД может быть добавлена самим пользователем SPTK. Я конечно дико извиняюсь, но toolkit мне нужен именно для того, _чтобы я сами ничего не писал_. Опять упс...

Поддержка БД в SPTK уже есть. Причем очень оптимизированная. Она включает в себя драйверы для ODBC и SQLite3. На сегодня это покрывает 100% промышленных баз данных. Если нужна любая экзотика, вот _тогда_ пишем драйвер. Упс..

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

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

> Вы этого впечатления добивались?

Я добивался одного: чтобы люди зашли и посмотрели сами. Те, у кого аналогичные потребности - разберутся сами. А те, кому это не надо - пожмут плечами. Я этого добился.