Re: Проблемы написания кроссплатформенных приложений
Hello! В сообщении от Monday 05 January 2009 17:36:25 ivan demakov написал(а): но от некоторых вещей нам уже никогда не избавиться, как, например, от клавиатуры qwerty/йцукен ;-) Вот это-то как раз легко изменить - на смену механическим придут лазерные и проч. клавиатуры, а там можно будет клавиши изобразить любой формы и в любом количестве и с произвольным расположением. P.S. Только сдается мне, что и когда интерфейсы ввода станут ненужны и с компьютером можно будет разговаривать на естественном языке, программы лучше не станут. Ахиллесова пята прогресса - человек :-) Best regards, Alexey. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On Monday 05 January 2009 17:12:54 Покотиленко Костик wrote: впрочем, был такой тулкит от sun'а, который был реално удобен. щас он тоже есть в линуксе, xview называется. только не используется нигде. Интересно почему... почему не используется? это как раз понятно любому, кто хоть раз видел внешний вид программы с этим тулкитом ;-) очень причудливо, хотя я слышал мнение, что очень эргономично. но от некоторых вещей нам уже никогда не избавиться, как, например, от клавиатуры qwerty/йцукен ;-) -- Из одной системы нам еще долго на выбраться - из солнечной.
Re: Проблемы написания кроссплатформенных приложений
On 2009.01.01 at 09:27:15 +0200, Serhiy Storchaka wrote: Victor Wagner wrote: Покажите мне прямой тулкит на C++. Не требующий спец-препроцессора, как Qt или проприетарных расширений языка, как Borland OWL. Fltk я видел. Радиус кривизны заметно больше чем у wx, gtk или Qt, но все же. Посмотри FOX Toolkit. Меньше Qt, не использует спец-препроцессора, Неужели из него что-то осмысленное сделали? Когда они начинали работу - в прошлом веке ещё, я там было попробовал поучаствовать. Но уровень там был такой, что плюнул и ушел. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On 2009.01.01 at 06:44:59 +0600, ivan demakov wrote: впрочем, был такой тулкит от sun'а, который был реално удобен. щас он тоже есть в линуксе, xview называется. только не используется нигде. А что, кто-нибудь пробовал вычистить тамошние хидеры, чтобы все это нормально собиралось gcc с -pedantic -ansi -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
Victor Wagner wrote: On 2009.01.01 at 09:27:15 +0200, Serhiy Storchaka wrote: Victor Wagner wrote: Покажите мне прямой тулкит на C++. Не требующий спец-препроцессора, как Qt или проприетарных расширений языка, как Borland OWL. Fltk я видел. Радиус кривизны заметно больше чем у wx, gtk или Qt, но все же. Посмотри FOX Toolkit. Меньше Qt, не использует спец-препроцессора, Неужели из него что-то осмысленное сделали? Когда они начинали работу - в прошлом веке ещё, я там было попробовал поучаствовать. Но уровень там был такой, что плюнул и ушел. Посмотри. Сам говоришь, что время устаревания результатов поиска в интернете около полугода. А в то время, когда я имел с ним дело (уже в начале этого столетия), для этого тулкита оно составляло месяц-два. Даже если такой темп не продержался долго, разрастись за десяток лет он должен уже в разы. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
Hello! В сообщении от Thursday 01 January 2009 10:57:52 Boris Popov написал(а): Нет плохихих языков. Писать нормально нужно и будет всё ок. Например у нас хромает именно скриптовая часть в плане переносимости. С плюсами проблем нет. Нет проблем, говорите - а чем компиляете приложения под виндоус хп/висту в дебиане? Чем компиляете под винмобайл? Пакет pocket-gcc малость того, загнулся, а его мантейнеры вот что говорят: If you want a virtual machine, look into Bochs or VMware. That would allow you to run evc++. Так что сдается мне, вы просто не пишите кроссплатформенных приложений :-) Best regards, Alexey. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On 2009.01.01 at 12:41:04 +0200, Serhiy Storchaka wrote: Неужели из него что-то осмысленное сделали? Когда они начинали работу - в прошлом веке ещё, я там было попробовал поучаствовать. Но уровень там был такой, что плюнул и ушел. Посмотри. Сам говоришь, что время устаревания результатов поиска в интернете около полугода. А в то время, когда я имел с ним дело (уже в начале этого столетия), для этого тулкита оно составляло месяц-два. Даже если такой темп не продержался долго, разрастись за десяток лет он должен уже в разы. Разрастание, как правило, не приводит к выпрямлению изначально кривого. Вот искривиться изначально прямое при разрастании может, это да. Но чтобы кривое выпрямилось, таких случаев мне неизвестно. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
Victor Wagner wrote: Разрастание, как правило, не приводит к выпрямлению изначально кривого. Вот искривиться изначально прямое при разрастании может, это да. Но чтобы кривое выпрямилось, таких случаев мне неизвестно. А что там кривое? Примеры можно? А то кривизна может зависеть от точки зрения. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
Hello! GUI сам по себе НИКОГДА не является критичным по скорости, поскольку его скорость реакции определяется скоростью человека. И только объектно-ориентированный подход может затормозить современный компьютер до такой степени, чтобы человек ощущал замедленную реакцию интерфейса. И в самом деле - писал когда-то на wxWidgets (ага, объектный, С++), сложный интерфейс ощутимо тормозил на мощном по меркам трех-четырехлетней давности компе. На tcl/tk подобный интерфейс работает без ощутимых задержек. На самом деле, все логично - в тикле напрямую вызывается сишный код при обращении к функции, а в wxWidgets вызываются десятки и сотни функций-оберток, пока вызов дойдет непосредственно до нужного кода, притом эти обертки написаны зачастую хреновато. Собственно, яркий пример это ява-приложения, где объектный подход доведен до абсурда, значительная часть классов closed-source и мудрые ява-программисты, ничтоже сумняшеся, громоздят к ним обертки, потом следующие программисты дописывают свои обертки и костыли и так продолжается неизвестно сколько итераций. P.S. И нафига вообще нужен С++ для работы? Это же убожество, достаточно глянуть на многословность и запутанность стандарта. Для всех практических целей связка С и скриптовые языки намного лучше. Про переносимость С++ вообще молчу - много раз видел, как код может работать неправильно или неработать вовсе, поскольку компилятор что-то там заоптимизировал, а юзеры возмущенно кричат, что мол эскулайт, к примеру, кривой, поскольку они не могут его в своей любимой вижуал студии скомпилять (мда, помню одному такому посоветовал выучить С, а уж потом смотреть на С++, на что оппонент заявил, что мол он программит уже больше 30-ти лет и немеряно крут, а в итоге оказалось, лишние флажки оптимизации он в настройках вижуал студии понатыкал). Best regards, Alexey. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
Hello! Скриптовые языки, да, гораздо переносимее. Но у скриптовых языков есть недостаток - скорость. Она неплохая, но, как правило, не более того, и не для всех задач подходит. Вы серьезно считаете, что скорости сишного кода вам мало? Тикль напрямую вызывает функции, реализованные на С. Нужно ускорить кусок кода - пишете функцию на С и вызываете из тикля. В чем проблема-то? Что касается работы со строками, тут скриптовые языки в десятки и сотни раз обгонят С++ благодаря прекрасным алгоритмам - реализация строковой обработки давно уже отточена. Я так и знал, что будет про мух. Замечу, что я взял статистику не по самой, мягко говоря, распространённой ОС, мухи к нам залетают редко. Или это такой тонкий намёк, что 70% Дебиана - говно? Скорее, 80% дерьмо: mysql, java, php... и базирующиеся на них проекты - продолжать можно долго. И еще всякие apache и иже с ними. А вот ради оставшихся 20% и стоит пользоваться дебианом. А можно парочку успешных примеров (пусть маленьких)? А то у меня первая ассоциация - геморрой, и уж потом преимущества. Исключая гуи, которые написаны изначально как обёртки к тучам опций готовых консольных приложений. Если задача - две минуты потыкать во флажки/поля, а затем один-два-десять раз запустить cli-утилиту, да, проблем нет. А если функции нужно запускать часто, сотни-тысячи раз в секунду? Функции или приложения? Если вызывать внешние приложения с такой частотой, то межпроцессное взаимодействие съест ресурсов гораздо больше, чем приложение, выполняющее эти вызовы. GUI сам по себе НИКОГДА не является критичным по скорости, поскольку его скорость реакции определяется скоростью человека. Да-да. Именно поэтому я вижу тормоза гуя, как в своих программах, если я не озаботился продумыванием гуя (а иногда - даже когда озаботился), так и в чужих. Знаю, знаю, у меня тоже кривые руки. Простой пример: вывод из БД таблички в миллион и более строк. Многие жалуются, что гуи на этом тормозит. Но тормозит не гуи, а разработчик, ибо юзеру бессмысленно глядеть на этот миллион с гаком строк - что он с ними делать-то будет? А разумное количество строк, которое человек может воспринять, это порядка сотен или тысяч в зависимости от задачи, на таких объемах никаких тормозов интерфейса не будет (ладно, я верю, что можно написать и для этого случая тормозной интерфейс, если постараться). Ваш вариант - на чём писать гуй? Надо: текстовые поля, флажки, надписи, комбо-боксы (не знаю, как правильно по-русски), панельки там базовые, меню, таблички, менеджеры размещения, группирование элементов в группы, рисование на элементах. tcl/tk. Правда, в нем возможностей намного больше, но вы можете их не использовать :-) Best regards, Alexey. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On 2008.12.31 at 13:13:16 +0300, Alexey Pechnikov wrote: Скорее, 80% дерьмо: mysql, java, php... и базирующиеся на них проекты - продолжать можно долго. И еще всякие apache и иже с ними. А вот ради оставшихся 20% и стоит пользоваться дебианом. Ну насчет apache - не согласен. Если использовать его по назначению - как гибкий web-сервер для раздачи статического контента и запуска внешних cgi, а не пытаться встраивать в него мощные web-приложения и интерпретаторы скриптовых языков, то очень даже неплохой продукт. Опять же, если правильный mpm для данной ОС выбрать. Простой пример: вывод из БД таблички в миллион и более строк. Многие жалуются, что гуи на этом тормозит. Но тормозит не гуи, а разработчик, ибо юзеру бессмысленно глядеть на этот миллион с гаком строк - что он с ними делать-то будет? А разумное количество строк, которое человек может воспринять, это порядка сотен или тысяч в зависимости от задачи, на таких объемах никаких тормозов Разумное количество строчек в GUI это столько, сколько на экран влазит. О существовании в природе более других строчек из всего GUI должна знать только полоска прокрутки. А тот виджет, который их показывает, должен знать только как при необходимости добыть из некоего промежуточного хранилища (не обязательно непосредственно из БД) те строчки, которые юзер попросил показать. tcl/tk. Правда, в нем возможностей намного больше, но вы можете их не использовать :-) Правда, рекомендуется их все же знать. А то многие авторы Tk-приложений начинают сходу использовать всякие BWidget-ы и прочие incr Tcl, которые сходу обрезают 90% этих возможностей, например, создавая неудобочитаемую иерархию виджетов. В результате за легкое достижение красивости приходится платить сложностью расширения и отладки. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On 2008.12.31 at 13:07:56 +0200, Eugene V. Lyubimkin wrote: Хорошо, бум глядеть. Раз tcl/tk так хвалят... Тогда ещё вопрос, на какую версию смотреть, чтобы не быть потом обличённым фразой нафиг ты это говно Последняя версия 8.5.6. К сожалению, многие из присутствующих здесь любителей tcl, в частности я, вкус 8.5 еще не распробовали, поэтому не факт, что можно будет получить здесь оптимальные советы по использованию новых возможностей 8.5 мамонта взял, вылезай из анабиоза и юзай нормальные версии? Ну и примеры остаются в силе - что посмотреть из хорошего (код)? Tkabber? tkabber - код средней паршивости. Основная к нему претензия - достаточно плохая (само)документированность. Кроме того, это слишком большое и развесистое приложение, чтобы использовать его в качестве примера. Большие приложения можно так использовать только при условии кристально ясной и внятно документированной архитектуры и модульности. Поэтому до примера как надо tkabber несколько недотягивает. Начинать надо с родного widget tour и соответствующих приметов к tile (которое в 8.5 потихоньку вытесняет старый Tk). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
Hello! В сообщении от Wednesday 31 December 2008 14:04:23 Victor Wagner написал(а): On 2008.12.31 at 13:13:16 +0300, Alexey Pechnikov wrote: Скорее, 80% дерьмо: mysql, java, php... и базирующиеся на них проекты - продолжать можно долго. И еще всякие apache и иже с ними. А вот ради оставшихся 20% и стоит пользоваться дебианом. Ну насчет apache - не согласен. Если использовать его по назначению - как гибкий web-сервер для раздачи статического контента и запуска внешних cgi, а не пытаться встраивать в него мощные web-приложения и интерпретаторы скриптовых языков, то очень даже неплохой продукт. Мало кто использует апач как веб-сервер, чаще всего он играет роль сервера приложений. А если кто и использовал, то уже перешли на lighttpd/nginx. Если же не использовать лишние возможности апач, кому он нужен будет... P.S. Изобретателей русского апач с кривой перекодировкой контента на лету вообще убить мало - до сих пор есть отдельные личности, у которых несколько кодировок контента на одном ресурсе, притом и отдается контент не в юникоде. Best regards, Alexey. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On 2008.12.31 at 14:47:19 +0300, Alexey Pechnikov wrote: Ну насчет apache - не согласен. Если использовать его по назначению - как гибкий web-сервер для раздачи статического контента и запуска внешних cgi, а не пытаться встраивать в него мощные web-приложения и интерпретаторы скриптовых языков, то очень даже неплохой продукт. Мало кто использует апач как веб-сервер, чаще всего он играет роль сервера приложений. А если кто и использовал, то уже перешли на lighttpd/nginx. Если же не использовать лишние возможности апач, Ну, nginx вообще не умеет cgi. Только fast-cgi. Для классической модели web-сервера с ОТДЕЛЬНЫМИ элементами динамики это крупный недостаток. На lighttpd внимательно не смотрел, но с точки зрения гибкости управления правами ему до апача как до Луны пешком. Другое дело что в современном вебе классическая модель web-сервера действительно распространена мало. P.S. Изобретателей русского апач с кривой перекодировкой контента на лету вообще убить мало - до Ну надо сказать что единственный просчет Тутубалина в этом плане - он недоучел идиотизма web-мастеров. Там все можно настроить прямо. Лично я в свое время от использования mod_charset отказался еще в прошлом веке, когда можно было перестать учитывать существование IE 3.x. А до этого русский апач был спасением. Отказался я от него не потому, что перекодировка кривая, а потому, что у клиентов процессоров много, а у моего сервера - ну два, ну четыре. Поэтому нехай они свои процессоры грузят. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
Hello! Ну, nginx вообще не умеет cgi. Только fast-cgi. Для классической модели web-сервера с ОТДЕЛЬНЫМИ элементами динамики это крупный недостаток. На lighttpd внимательно не смотрел, но с точки зрения гибкости управления правами ему до апача как до Луны пешком. Зачем сложное управление правами для _статики_? Как раз для статики хватает юниксовых прав на файлы/директории. Best regards, Alexey. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On 2008.12.31 at 17:37:02 +0300, Alexey Pechnikov wrote: Hello! Ну, nginx вообще не умеет cgi. Только fast-cgi. Для классической модели web-сервера с ОТДЕЛЬНЫМИ элементами динамики это крупный недостаток. На lighttpd внимательно не смотрел, но с точки зрения гибкости управления правами ему до апача как до Луны пешком. Зачем сложное управление правами для _статики_? Как раз для статики хватает юниксовых прав на файлы/директории. Нифига не хватает. Если эту статику надо кому-то все-таки отдавать. httpd в отличие от ftpd, не умеет пришедшего пользователя авторизовывать как системного и работать с правами этого пользователя, а не www-data. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On Wed, Dec 31, 2008 at 12:11:03PM +0300, Alexey Pechnikov wrote: И в самом деле - писал когда-то на wxWidgets (ага, объектный, С++), сложный интерфейс ощутимо тормозил на мощном по меркам трех-четырехлетней давности компе. На tcl/tk подобный интерфейс работает без ощутимых задержек. На самом деле, все логично - в тикле напрямую вызывается сишный код при обращении к функции, а в wxWidgets вызываются десятки и сотни функций-оберток, пока вызов дойдет непосредственно до нужного кода, притом эти обертки написаны зачастую хреновато. Это показатель кривизны wxWidgets как тулкита, C++ тут не при чем. Такое же количество функций-оберток можно нарисовать и на C. Собственно, яркий пример это ява-приложения, где объектный подход доведен до абсурда, значительная часть классов closed-source На C/С++ тоже много closed-source кода. В яве полно OpenSource библиотек, при чем под business-friendly лицензиями. и мудрые ява-программисты, ничтоже сумняшеся, громоздят к ним обертки, потом следующие программисты дописывают свои обертки и костыли и так продолжается неизвестно сколько итераций. Пример? -- WBR, Dmitry signature.asc Description: Digital signature
Re: Проблемы написания кроссплатформенных приложений
On 2008.12.31 at 19:58:55 +0200, Dmitry Nezhevenko wrote: Это показатель кривизны wxWidgets как тулкита, C++ тут не при чем. Такое же количество функций-оберток можно нарисовать и на C. Покажите мне прямой тулкит на C++. Не требующий спец-препроцессора, как Qt или проприетарных расширений языка, как Borland OWL. Fltk я видел. Радиус кривизны заметно больше чем у wx, gtk или Qt, но все же. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On 2009.01.01 at 00:20:09 +0600, Mikhail Gusarov wrote: Twas brillig at 21:17:05 31.12.2008 UTC+03 when vi...@wagner.pp.ru did gyre and gimble: VW Покажите мне прямой тулкит на C++. Не требующий спец-препроцессора, VW как Qt или проприетарных расширений языка, как Borland OWL. WTL. Хоть заворачивает Win32, а не X11, но какая разница? А мне удастся собрать программу с WTL с помощью компилятора из дебиановского пакета mingw32? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
Hello! В сообщении от Wednesday 31 December 2008 22:31:00 Mikhail Gusarov написал(а): VW А мне удастся собрать программу с WTL с помощью компилятора из VW дебиановского пакета mingw32? Не исключаю (VC-шных расширений там не используется), но подозреваю, что никто не проверял, так что придётся немножко пофиксить. Впрочем, совместимость C++-ных реализаций - другой вопрос. Что же это за кроссплатформенный код, если он даже не компилируется на другой платформе? Давно уже перешел на mingw для создания виндовых приложений, и сишный код собираю без особенных заморочек. Извращение в виде вижуалстудии (особенно под wine :-)) просьба не предлагать. Best regards, Alexey. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On 2008.12.31 at 23:07:28 +0300, Alexey Pechnikov wrote: Не исключаю (VC-шных расширений там не используется), но подозреваю, что никто не проверял, так что придётся немножко пофиксить. Впрочем, совместимость C++-ных реализаций - другой вопрос. Что же это за кроссплатформенный код, если он даже не компилируется на другой платформе? Давно уже перешел на mingw для создания виндовых приложений, и сишный код собираю без особенных заморочек. А для GUI что? Ведь mingw32 несовместим с msvc по name mangling-у (впрочем разные версии msvc и разные версии gcc и между собой-то не совместимы). Соотвественно, всякие MFC которые состоят из DLL с плюсовым интерфейсом - пролетают. Разве только Tk использовать. Но для многих задач Tk - стрельба их пушки по воробьям. Хочется чего-то такого, чтобы не нужно было с собой тулкит в пару мегабайт таскать. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On Thu, Jan 01, 2009 at 12:25:14AM +0300, Victor Wagner wrote: On 2008.12.31 at 23:07:28 +0300, Alexey Pechnikov wrote: Не исключаю (VC-шных расширений там не используется), но подозреваю, что никто не проверял, так что придётся немножко пофиксить. Впрочем, совместимость C++-ных реализаций - другой вопрос. Что же это за кроссплатформенный код, если он даже не компилируется на другой платформе? Давно уже перешел на mingw для создания виндовых приложений, и сишный код собираю без особенных заморочек. А для GUI что? Ведь mingw32 несовместим с msvc по name mangling-у (впрочем разные версии msvc и разные версии gcc и между собой-то не совместимы). Соотвественно, всякие MFC которые состоят из DLL с плюсовым интерфейсом - пролетают. Разве только Tk использовать. Но для многих задач Tk - стрельба их пушки по воробьям. Хочется чего-то такого, чтобы не нужно было с собой тулкит в пару мегабайт таскать. Господа и товарищи! С НОВЫМ ГОДОМ! Ну где еще найдешь людей в новогоднюю ночь обсуждающих ньюансы программирования на C++ или Tk ;) -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
Hello! В сообщении от Thursday 01 January 2009 00:25:14 Victor Wagner написал(а): Что же это за кроссплатформенный код, если он даже не компилируется на другой платформе? Давно уже перешел на mingw для создания виндовых приложений, и сишный код собираю без особенных заморочек. А для GUI что? Ведь mingw32 несовместим с msvc по name mangling-у (впрочем разные версии msvc и разные версии gcc и между собой-то не совместимы). Соотвественно, всякие MFC которые состоят из DLL с плюсовым интерфейсом - пролетают. Разве только Tk использовать. Но для многих задач Tk - стрельба их пушки по воробьям. Хочется чего-то такого, чтобы не нужно было с собой тулкит в пару мегабайт таскать. Tk и использую. Плюс модуль ffidl для доступа к любым динамическим библиотекам в системе и свои бинарные расширения, скомпиленные с помощью mingw. Воробьи нынче в виндах такие, что самый мелкий на десяток мегабайт, так что тулкит на 2 мегабайта это мелочи. P.S. Помню развлечения с поиском хидеров для всех версий activesync, а теперь несколько строк на тикле и любая либа activesync (или другая нужная) подцепляется на лету. Красота. Best regards, Alexey. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On Wednesday 31 December 2008 13:58:53 Victor Wagner wrote: Изучите пару десятков высокоуровневых языков, будет у вас взгляд нескромный. Как правило, любой скриптовый язык, стандарт на который задан реализацией - Tcl, Perl, Python, Ruby - обладает куда большей переносимостью чем C++. Да и Scheme, хотя у нее десятки независимых реализаций - тоже. tcl исключить, да и perl тоже. python раздражает своими отступами и излишней обьктно-ориентировастью. с ruby не знаком. вот scheme - это хорошо, особенно если учесть что я сам один из авторов одной из реализаций :) что еще? haskel слишком заумен. ml мог бы, но почему то не стал. GUI сам по себе НИКОГДА не является критичным по скорости, поскольку его скорость реакции определяется скоростью человека. И только объектно-ориентированный подход может затормозить современный компьютер до такой степени, чтобы человек ощущал замедленную реакцию интерфейса. так то оно так, но qt всетаки не имеет альтернатив СЕЙЧАС. motif мог бы, но зарезал сам себя, своей идиотской политикой лицензирования, а когда опомнился, поезд уже ушел. был еще один тулкит, сами знаете какой, шедевр практически. для меня загадка почему он так и не стал популярен. ну напоследок, для меня как програмиста, не очень важен внешний вид, лишь бы все было единообразно. а вот простота программирования -- это все. -- Полдень. В облака поднимаясь, Жаворонки поют.
Re: Проблемы написания кроссплатформенных приложений
Hello! tcl исключить ну напоследок, для меня как програмиста, не очень важен внешний вид, лишь бы все было единообразно. а вот простота программирования -- это все. Сами себе противоречите :-) Если вы знаете что-то удобнее tk, будет интересно услышать. Best regards, Alexey. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On Thursday 01 January 2009 03:25:14 Victor Wagner wrote: А для GUI что? Ведь mingw32 несовместим с msvc по name mangling-у (впрочем разные версии msvc и разные версии gcc и между собой-то не совместимы). Соотвественно, всякие MFC которые состоят из DLL с плюсовым интерфейсом - пролетают. mfc -- растрелять Разве только Tk использовать. Но для многих задач Tk - стрельба их пушки по воробьям. Хочется чего-то такого, чтобы не нужно было с собой тулкит в пару мегабайт таскать. да что ж вы так tcl то любите?. я его просто ненавижу ps. вот и фортунка в тему :) -- жри макароны! гуляя в большой степи они там вкусны
Re: Проблемы написания кроссплатформенных приложений
01.01.09, 00:52, Stanislav Maslovski stanislav.maslov...@gmail.com: Не исключаю (VC-шных расширений там не используется), но подозреваю, что никто не проверял, так что придётся немножко пофиксить. Впрочем, совместимость C++-ных реализаций - другой вопрос. Что же это за кроссплатформенный код, если он даже не компилируется на другой платформе? Давно уже перешел на mingw для создания виндовых приложений, и сишный код собираю без особенных заморочек. А для GUI что? Ведь mingw32 несовместим с msvc по name mangling-у (впрочем разные версии msvc и разные версии gcc и между собой-то не совместимы). Соотвественно, всякие MFC которые состоят из DLL с плюсовым интерфейсом - пролетают. Разве только Tk использовать. Но для многих задач Tk - стрельба их пушки по воробьям. Хочется чего-то такого, чтобы не нужно было с собой тулкит в пару мегабайт таскать. Господа и товарищи! С НОВЫМ ГОДОМ! Ну где еще найдешь людей в новогоднюю ночь обсуждающих ньюансы программирования на C++ или Tk ;) Да-да. Я обратил внимание, что у тут активность выше, чем на новостных сайтах, жж и вики вместе взятых. ::: Продаю капли от покраснения глаз, оптом ::: -- wBR,George. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
01.01.09, 03:23, Mikhail Gusarov dotted...@dottedmag.net: Ну где еще найдешь людей в новогоднюю ночь обсуждающих ньюансы программирования на C++ или Tk ;) GS Да-да. Я обратил внимание, что у тут активность выше, чем на GS новостных сайтах, жж и вики вместе взятых. IRC тоже вполне жив. Вот они - рассадники. -- wBR,George. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
On Thursday 01 January 2009 04:06:38 Alexey Pechnikov wrote: Сами себе противоречите :-) Если вы знаете что-то удобнее tk, будет интересно услышать. не знаю. tk -- это хорошо. tcl -- плохо. впрочем, был такой тулкит от sun'а, который был реално удобен. щас он тоже есть в линуксе, xview называется. только не используется нигде. -- Дело простое. Засунуть поглубже а Сможешь ли вынуть?
Re: Проблемы написания кроссплатформенных приложений
Victor Wagner wrote: Покажите мне прямой тулкит на C++. Не требующий спец-препроцессора, как Qt или проприетарных расширений языка, как Borland OWL. Fltk я видел. Радиус кривизны заметно больше чем у wx, gtk или Qt, но все же. Посмотри FOX Toolkit. Меньше Qt, не использует спец-препроцессора, многоплатформеный. Даже в Дебиане есть. Дефолтный Look правда слегка страшноват, но матёрого Tk-шника это не отпугнёт. И я видел, как люди делали из него конфетку, слегка кастомизировав отрисовку и иконки. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Проблемы написания кроссплатформенных приложений
Нет плохихих языков. Писать нормально нужно и будет всё ок. Например у нас хромает именно скриптовая часть в плане переносимости. С плюсами проблем нет. 31 декабря 2008 г. 12:11 пользователь Alexey Pechnikov pechni...@sandy.ru написал: P.S. И нафига вообще нужен С++ для работы? Это же убожество, достаточно глянуть на многословность и запутанность стандарта. Для всех практических целей связка С и скриптовые языки намного лучше. Про переносимость С++ вообще молчу - много раз видел, как код может работать неправильно или неработать вовсе, поскольку компилятор что-то там заоптимизировал, а юзеры возмущенно кричат, что мол эскулайт, к примеру, кривой, поскольку они не могут его в своей любимой вижуал студии скомпилять (мда, помню одному такому посоветовал выучить С, а уж потом смотреть на С++, на что оппонент заявил, что мол он программит уже больше 30-ти лет и немеряно крут, а в итоге оказалось, лишние флажки оптимизации он в настройках вижуал студии понатыкал). -- Boris Popov
Re: Проблемы написания кроссплатформенных приложений
On 2008.12.30 at 22:46:39 +0200, Eugene V. Lyubimkin wrote: Victor Wagner wrote: корректная работа с Юникодом, можно слинковать с libqtcore4 - она весит 2 метра в архиве. А вот на плюсах кросс-платформные приложения лучше не писать. Другие варианты, на мой скромный взгляд, ещё хуже. Изучите пару десятков высокоуровневых языков, будет у вас взгляд нескромный. Как правило, любой скриптовый язык, стандарт на который задан реализацией - Tcl, Perl, Python, Ruby - обладает куда большей переносимостью чем C++. Да и Scheme, хотя у нее десятки независимых реализаций - тоже. Практика показывает, что многие с Вами не согласны. Дебиан предоставляет нам замечательную Еште дерьмо. Сто миллионов мух не могут ошибаться. А уж в случае программ с гуём, особенно если у них есть участки, критичные к скорости выполнения, то альтернатив плюсам совсем мало Альтернатива одна-единственная, но очвень мощная. НЕ ПИШИТЕ ВЕСЬ ПРОЕКТ на одном языке. GUI сам по себе НИКОГДА не является критичным по скорости, поскольку его скорость реакции определяется скоростью человека. И только объектно-ориентированный подход может затормозить современный компьютер до такой степени, чтобы человек ощущал замедленную реакцию интерфейса. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
