Здравствуйте, retalik, Вы писали:

R>Так вот, моё традиционное мнение: дотнет даёт множество преимуществ в разработке, которые можно принять во внимание.

А библиотека wxWidgets (для C++) даёт тоже множество преимуществ в скорости и цене разработки.

1) GUI, удобнейшие и разнообразнейшие средства RAD:

Code::Blocks (http://www.codeblocks.org/),
DialogBlocks (http://www.dialogblocks.com/),
wxFormBuilder (http://wxformbuilder.org/?page_id=21),
wxDev-C++ (http://wxdsgn.sourceforge.net/),
CodeLite (http://codelite.org/),
wxGlade (http://wxglade.sourceforge.net/).

2) Быстрый и удобный класс wxString (поддержка Unicode: UTF8/16/32, конверсия между любыми character sets (KOI8-R, Windows-1251, Codepage 866 итд) есть и wxRegEx.

3) Большое количество кроссплатформенных классов для разных целей: работа с таймерами, потоками, процессами, архивами, сокетами, ftp, http, (опционально curl), логами, датой, быстрыми хэш таблицами, array, списками, коммандной строкой, системы помощи, xml, html, файловой системой, интерфейс — окна, диалоги, контролы, буффер обмена, drag&drop, работа с принтером/preview, Document/view framework, advanced user interface и многое другое из сторонних wx библиотек (wxCode — http://wxcode.sourceforge.net и http://www.wxcommunity.com/modules.php?op=modload&name=Downloads&file=index).

В плюсы wxWidgets пишем кроссплатформенность (Windows, Linux, MacOSX), малый размер генерируемого бинарника (консольные — от 200kb, графические проги занимают — от 1.5MB (с upx — 700kb)), высокая скорость выполнения, малые требования к ресурсам памяти, БЕСПЛАТНОСТЬ для коммерческих целей, открытость исходного кода.

R> Максимальный выигрыш, конечно, получается для серверных приложений (за счёт убойности ASP.NET, средств работы с данными и всяких сетевых штук типа веб-сервисов).

Если говорить об удобстве для программиста, то да, направление ASP очень сильно распиарено, по нему создано много туториалов, книг, позиционируется в университетах для изучения решений от майкрософт. Но с помощью удобной библиотеки wxWidgets — скорость написания программ уже сравнима со скоростью написания на C#. Поэтому даже есть большие сомнения в том, нужна ли вообще платформа .NET. Для C++ есть множеств библиотек для создания веб сервисов на самых различных уровнях абстракции и использования протоколов.

Если говорить о ресурсах, то здесь максимальный выигрыш дают консольные приложения C++/FastCGI для веба.
При правильном использовании технологий lighttpd/FastCGI/C++ , можно добиться значительной экономии ресурсов.
Например, можно вместо 10 или 100 серверов с ASP.NET арендовать всего 1 сервер c FastCGI/С++ для выполнения тех же самых задач.

А>В плюсы wxWidgets пишем кроссплатформенность (Windows, Linux, MacOSX),

можно я вмешаюсь? кроссплатформенность от QT, wxWidgets или Java в плане пользовательского интерфейса приводит к созданию программ типа "и не винда и не мак". у этих двух систем куча различий в плане интерфейса пользователя. не только кнопочки другого цвета, нет.

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

я портировал виндовый софт под мак, писал с нуля под него же, вывод такой: реально проще разобраться с obj-c и cocoa, чем пытаться сделать черти-что, зато сразу под все платформы. а уж учитывая сколько всего в cocoa уже встроено — проще виндовый код вообще с нуля переписать

Библиотека wxWidgets (http://www.wxwidgets.org/) позволяет разработчикам создавать приложения для Windows, Linux, MacOSX, используя общую базу программного кода.

wxWidgets может быть использован из таких языков программирования как C++, Python, Perl и даже из C#/.NET (!!!)

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

Журнал MaximumPC (http://www.maximumpc.com/) недавно опубликовал список 32 наиболее важных приложения для каждого нового персонального компьютера. И как минимум 5 из этих приложений используют wxWidgets:

Dropbox (http://www.getdropbox.com/),
TrueCrypt (http://www.truecrypt.org/),
FileZilla (http://filezilla-project.org/),
Digsby (http://www.digsby.com/),
Audacity (http://audacity.sourceforge.net/).

Список некоторых кроссплатформенных программ, которые используют библиотеку wxWidgets можно найти здесь: http://www.wxwidgets.org/about/screensh.htm

ov>я только что сходил на сайт wxWidgets, посмотрел скриншоты "маковских" программ — ужас. тихий. и, между прочим, мак-пользователи очень это чувствуют. и стараются не использовать "неродные" приложения. и авторы софта часто пишут, что софт сделан на маке и под мак, особо подчеркивая "натуральность" происхождения :)

А вы можете в качестве примера указать какие скриншоты там неправильные и что там не так?
Я так понимаю вы смотрели здесь

Да там действительно ад, например тулбар тут: http://wxwidgets.org/images/screens/waveidea-mac.jpg

Другое дело, что там скриншоты древних версий, сейчас wx вроде весьма достойна.

_>А вы можете в качестве примера указать какие скриншоты там неправильные и что там не так?
_>Я так понимаю вы смотрели здесь

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

скриншоты там кривые почти все. сразу бросаются в глаза чисто виндовые тулбары. начиная от виндового стиля кнопок и заканчивая тем, что выносить в тулбар кнопки new/open/save это чисто виндовая тема.

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

AV>Другое дело, что там скриншоты древних версий, сейчас wx вроде весьма достойна.
да какая бы достойная она не была, там ведь нету аналога CoreData, Cocoa Bindings, да и вообще контроллеров таких, как в Cocoa, механизмы для Undo/Redo готовые есть с сериализацией команд? вряд ли.

Cocoa для меня стала открытием. очень серьезный и навороченный фреймворк, при этом сделанный весьма просто. так что если надо писать под мак — я лучше с нуля сделаю все на obj-c/cocoa или же реализую часть функционала кроссплатформенно на С++, а под каждую платформу сделаю обертки на наиболее удобном фреймворке.

Здравствуйте, ov, Вы писали:

ov>скриншоты там кривые почти все. сразу бросаются в глаза чисто виндовые тулбары. начиная от виндового стиля кнопок и заканчивая тем, что выносить в тулбар кнопки new/open/save это чисто виндовая тема.

И с каких это пор кривизна рук отдельных разработчиков привыкших писать под виндовс, и выносяших привычные кнопки на тулбар, причисляется к кривезне библиотеки?

P.S. По теме "wxWidgets и Shareware разработки" (заметьте про кроссплатформенность ни слова — на wx писать шаровару можно, даже под винду есть смысл использовать, не хуже, а некоторые считают что и лучше чем MFC, при это кроссплатформенность, даже если она и немного кривовата, большой плюс.

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

B_>P.S. По теме "wxWidgets и Shareware разработки" (заметьте про кроссплатформенность ни слова — на wx писать шаровару можно, даже под винду есть смысл использовать, не хуже, а некоторые считают что и лучше чем MFC, при это кроссплатформенность, даже если она и немного кривовата, большой плюс.
с MFC вообще "сложно" тягаться по удобству

Здравствуйте, Аноним, Вы писали:


А>Журнал MaximumPC (http://www.maximumpc.com/) недавно опубликовал список 32 наиболее важных приложения для каждого нового персонального компьютера. И как минимум 5 из этих приложений используют wxWidgets:

А>Dropbox (http://www.getdropbox.com/),
А>TrueCrypt (http://www.truecrypt.org/),
А>FileZilla (http://filezilla-project.org/),
А>Digsby (http://www.digsby.com/),
А>Audacity (http://audacity.sourceforge.net/).

Лучше бы они опубликовали список из 32 приложений, авторам которых досталось больше всего долларов США за час работы. Это было бы больше в тему.

Здравствуйте, Begemot_, Вы писали:

B_>И с каких это пор кривизна рук отдельных разработчиков привыкших писать под виндовс, и выносяших привычные кнопки на тулбар, причисляется к кривезне библиотеки?

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

Вообще, библиотека wx — многоцелевая, быстрая и очень удобная. Под Windows работает очень хорошо. Можно перекомпилировать и запускать под Linux.

На счёт мака — тоже вполне работает, но пока только поддерживается Carbon API. Полноценная поддержка нового wxCocoa — на сколько я знаю, в стадии разработки.

B_>P.S. По теме "wxWidgets и Shareware разработки" (заметьте про кроссплатформенность ни слова — на wx писать шаровару можно, даже под винду есть смысл использовать, не хуже, а некоторые считают что и лучше чем MFC, при это кроссплатформенность, даже если она и немного кривовата, большой плюс.

Да, согласен. Я как раз один из тех, кто использовал MFC около 8 лет. Перешёл на wx и считаю, что wxWidgets действительно лучше чем MFC. По удобству, больше проработано нюансов, открытость-бесплатность, небольшой размер бинарника, высокая скорость, и дополнительный бонус — возможность запускать под Linux и Mac.

Qt тоже неплохой вариант, но там получается больше размер, и программа медленнее выполняется. Поэтому wxWidgets — более оптимальное решение для шаровары.

А>На счёт мака — тоже вполне работает, но пока только поддерживается Carbon API. Полноценная поддержка нового wxCocoa — на сколько я знаю, в стадии разработки.
эппл потихоньку уводит разработчиков от карбона. как бы в итоге вообще не отказались от него со времененм.
а в использование Cocoa из С++ я не верю. по крайней мере в человеческое использование. потому что С++ не позволяет ни создавать объекты по имени, ни обращаться к свойствам по имени, ни подписываться на уведомления об изменении свойств. С++ язык статический, а с Cocoa работают динамические языки типа obj-c, в первую очередь, ну и java с питоном.

так что даже если wxCocoa и будет, то это будет только одно название. реальной работы в cocoa-style не получится.

Здравствуйте, ov, Вы писали:

ov>эппл потихоньку уводит разработчиков от карбона.

На счёт эппл. Apple вообще не уважает труд разработчиков. Сплошное кидалово. У них постоянно меняются API, слабо поддерживается обратная совместимость, или вообще её нет. Свободный язык С++ уже их не устраивает, захотелось и здесь привязать к собственной среде. С Apple Store рассказывают, постоянные грабли. То не принимают после того как заплатили, то им вообще не нужны лишние конкуренты. Железо как всегда только от Apple. Пиар, фантики-бантики, постоянные ограничения и привязки. Как-то несерьёзно всё это.

Даже политика Microsoft на фоне сверхнаглости и жадности Apple выглядит куда более либеральной. Ну а Linux и свобода, это вообще почти слова-синонимы.

ov>>эппл потихоньку уводит разработчиков от карбона.
А>На счёт эппл. Apple вообще не уважает труд разработчиков. Сплошное кидалово. У них постоянно меняются API, слабо поддерживается обратная совместимость, или вообще её нет.
не меняются, а эволюционируют на самом деле, все очень четко и гладко проходит. некоторые методы объявляются deprecated, сразу же предлагаются новые методы, а старые через пару лет убираются. если автор проги за пару лет не удосужится их переделать — сам виноват, я считаю. впрочем, не так уж и много они меняют...

в плане обратной совместимости — да нормально там все. народ вполне успешно продает софт, работающий на OS X 10.2, 10.3. про 10.4 вообще молчу. преувеличиваешь ты, имхо.

А>Свободный язык С++ уже их не устраивает, захотелось и здесь привязать к собственной среде.
ты, сдается мне, Cocoa не видел. и не знаешь в чем его крутизна. на С++ этого просто не сделать в силу его статичности. obj-c очень своеобразный язык, но он офигенно подходит для реализации всех идей, заложенных в Cocoa.

Здравствуйте, ov, Вы писали:

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

Уже через год, на следующей конференции WWDC 2007, Стив Джобс, рассказывая о задержке выхода Mac OS X 10.5 и о ее новых возможностях, в своей презентации показал, что одной из новых возможностей будет являться поддержка 64-битности в Cocoa, а вот Carbon куда-то из презентации Джобса подевался. И тут подозрение разработчиков на Carbon их не обмануло — когда они стали выяснять, случайно ли пропал Carbon из презентации Джобса, оказалось, что неслучайно. Apple действительно в последний момент “выбросила” поддержку 64-бит из Carbon для финальной версии 10.5.

здесь


Помнится много шума было...

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

ну я ж говорил — уводят от карбона
а про смену АПИ я имел в виду изменения в Cocoa. с карбоном не сталкивался вообще, так что не могу судить как оно там меняется.

Здравствуйте, ov, Вы писали:

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

ov>ну я ж говорил — уводят от карбона
ov>а про смену АПИ я имел в виду изменения в Cocoa. с карбоном не сталкивался вообще, так что не могу судить как оно там меняется.

Из за отсутствия Cocoa в wxWidgets я не доделал sheets (по дефолту их вообще нет в wx).
Это вот такие штуки: http://img266.imageshack.us/img266/4937/picture2wd9.png
Засабмитил патч (http://trac.wxwidgets.org/ticket/9459), потом обратил внимание, что с карбоновским апи
они выезжают из середины тулбара. По гайду "sheets should emerge from a definite visual edge".
Чтобы позиционировать sheets, нужен делегат willPositionWindow а его аналога в карбоне нету.
Эпл ответил "Unfortunately we do not currently offer a supported method of doing this." Такие дела.

А>Полноценная поддержка нового wxCocoa — на сколько я знаю, в стадии разработки.
Вы наверное говорите о wxWidgets 2.9.0, которая должна в ближайшие дни зарелизиться.
Но в ветке 2.8 есть папки cocoa, они никак не относятся к Cocoa?

Здравствуйте, Аноним, Вы писали:

А>А библиотека wxWidgets (для C++) даёт тоже множество преимуществ в скорости и цене разработки....

А>В плюсы wxWidgets пишем кроссплатформенность (Windows, Linux, MacOSX), малый размер генерируемого бинарника (консольные — от 200kb, графические проги занимают — от 1.5MB (с upx — 700kb)), высокая скорость выполнения, малые требования к ресурсам памяти, БЕСПЛАТНОСТЬ для коммерческих целей, открытость исходного кода.

Решил вот попробовать, что за супер такой этот "wxWidgets". Скачал, отбилдил. Билдилась сама wxWidgets минут 5. Простенький пример из "samples" билдится 40 сек. Получаемый .exe в версии "release" весит и вправду 1.5MB, но тянет за собой MSVCR. Попытался, было, линковать её статически, но для этого надо перелопачивать все 20(!) проектов самой "wxWidgets". Скорость не супер, от клика на иконку до появления окна ~0.5 сек. Кроссплатформенность? — теоретически, конечно интересно, не более того.
В общем вывод такой, хоть плюйтесь господа, хоть нет, а лучше "дельфей" для написания Windows Gui пока не придумано. Для сравнения — примерно такое же приложение весит 400КВ, компилируется за доли секунд. Есть классы практически для всех, указаных топикстартером приложений. Переведены на паскаль все нужные хидеры. Удобство и скорость разработки не сравнятся с "плюсами". Так что, можно выделять новую (или старую) тему — "Delphi и Shareware разработки"

Здравствуйте, Аноним, Вы писали:

Блин, так быстро ушло пред.сообщение, что не успел подписаться, Аноним 585 если что, это я