Меджикивис Из всего рассмотреного выводим - VB "вам в руки". А про "качество компилируемого им кода" не надо - Delphi, Builder и др. RAD дают более "тяжелый и медленный" PE код. Кроме того, никто не отменял DLL, которые можно создавать в чем угодно (c/c++/asm). Тип лицензии на исп-мое ПО не рассматриваем, т.к. не "на продажу".

Если использовать Qt Designer, то программирование не сильно отличается от Бильдера. Просто идеология местами сильно отличается. Если осваивать "с нуля", то больших проблем быть не должно. Qt более "плюс-плюсный", чем Бильдер. Очень любят в Qt шаблонные классы. Это, правда, на любителя.
После того, как Нокия допилила Qt Designer большой надобности а Эклипсе нет.

пробовал когда-то FLTK - не понравился из-за проблем с юникодом, убогости встроенных виджетов и постоянного пребывания в состоянии альфы.
Если нужно что-то простое кросс-платформенное то есть Tk с биндингами к большинству языков (с Tcl, Питоном и Руби идет из коробки, есть биндинг к Луа). Содержит простой, но гибкий менеджер упаковки .pack, до которого большинству GUI-библиотек как до китая...
Еще можно посмотреть в сторону Java/Swing и Scala (если нужна кросс-платформенность с возможностью работы на всех платформах без перекомпиляции).

Сообщение отредактировал zöner - Apr 18 2012, 14:23

Python - наше всё

Спасибо на добром слове. Вообще-то под "качеством" кода я подразумевал не только скорость и объем.

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

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

Весьма хорош с этой стороны код, даваемый PureBasic. Я не знаю, как он этого добивается, но работает на любой PC и практически под любой Виндой (семерку не проверил только). Но программирование ГУИ в текстовом виде - это копать лопатой вместо экскаватора. Все циклы ожидания прерываний писать в ручную в явном виде - это же УЖОС реально. Сам не заметил, как забросил эту прелесть))))) Хотя под него есть среда под названием PureFORM, она всё это автоматизирует, но все равно создание и управление объектами через функции невероятно громоздко и запутано огромным количеством непонятных параметров, которых совсем не очевидно, откуда получить. (Вот это-то меня в нем и добило.) А ведь серьезно хотел на него пересесть.








А Scala - это что такое? (Я не только не пробовал, но даже не слышал.) Кросплатформенность мне не нужна, просто интересно.

А что же? Неужели вас интересует красота бинарника? Не обижайтесь, я по доброму


Так любая программа, так или и иначе будет использовать ресурсы ОС. От языка программирования это не зависит. В противном случае, компилятор бы выдавал stand-alone код, т.е. бинарник, который ну разве что после биоса можно сразу запускать.
Аккуратный разработчик программы должен эти моменты сам регулировать. Если Ваша программа зависит от офиса, то нужно делать проверку версии, или еще что-то. Скажем, к примеру, программа, которая работает с коммуникационным портом и только (терминал), глубоко чихает на наличие офиса.

Удивительно, но код после MinGW + QT у меня тоже работает везде: XP 32, XP 64, Win 7. Что я сделал неправильно?


Прошу прощения, но Вы не в теме. Эти ужасы остались в прошлом. Когда под ДОС писали GUI без использования уже имеющихся в те времена специализированных средств (я тогда Си/си++ не занимался, писал на Object Pascal 7 for DOS).

Меджикивис, от всего сердца советую, посмотрите современные средства разработки. Те ужасы, которые Вы перечисляете - в прошлом. Есть, конечно, проблемы, но они есть всегда и везде.

Что посоветуете начинающему декстоп-кодеру с перспективой перехода к более-менее серьезному подходу?

Сначала меня интересует его переносимость (как выше уже писал). Красота - во вторую очередь...


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


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

Типа прога должна проверить версии библиотек и в случае чего выдать пользователю сообщение "Обнаружено несоответствие версии библиотеки ХХХХ.DLL, запуск программы невозможен". Чем это пользователю принципиально приятнее, чем автоматическое сообщение "Обращение к несуществующему элементу в xxxx.dll, программа будет закрыта, ОК" ?
Сейчас Вы скажете, что надо "Файл XXXX.DLL неправильный. Заменить? Yes/Exit" Заменяем - начинает глючить Офис (или еще что-нибудь). Кому эти все проблемы нужны?


Она же работает не с одним КОМом. На форме наверняка есть текстовые поля, которые делает какая-нибудь дээлэлка. Вот и связь с Офисом. А если поставлены другие программы, тоже работающие с КОМом - тут уж точно жди накладок.
В случае плохого компилятора.

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


Прошу прощения, но это Вы не в теме. Поработайте с Pure Basic (для WIN), тогда и убедитесь, я правду написал о нем, или нет.

Пожалуйста ссылочки, где можно посмотреть. Буду премного благодарен.
Кроме Си и его разнообразных вариантов.

ЗЫ:
Дельфи (из паскалеподобного семейства) смотрел. В общем ничего против не имею, но по сумме всех впечатлений предпочел все-таки VB.

а я по старинке за Delphi 7 отдам свой голос
Qt меня убил нетрадиционным (с точки зрения дельфиста) построением иерархии классов для визуальных компонентов... я так и не смог к ним привыкнуть, наверное, просто старый стал

Еще для Delphi просто бескрайнее море уже готовых компонентов практически на все случаи жизни - от работы с портами до удаленной работы с базами данных, причем есть отличные официально бесплатные библиотеки, например, JEDI JVCL. то есть в сущности на уровне "любителя" 99,9% задач решаются практически только кликами мышкой - что любителю и надо

как с этим делом у Qt?

Ну чтож, все что мне надо было (GUI в первую очередь, потом уже работа с TCP/IP) в QT есть. А вообще на любителя)


Да нормально. Чего нет, сами пишем. В конце концов, нет универсальной библиотеки, где "все" есть.


Ну так о чем разговор тогда?
У Вас уже есть предпочтения, и наши советы Вам не подходят.
Зачем спрашивать тогда?

Не циклится на синтаксисе.
Помнить, что нервные клетки восстанавливаются, а тренировками даже наращиваются.
Отдавать предпочтение фреймворкам, а не языкам.
Я бы советовал .NET

Если .NET,
то все-таки C++ или C#????
поправьте, если ошибаюсь:
C# - чисто .NET, свой синтаксис, отличный от C++; CLR и все вытекающие последствия при использовании неуправляемого кода и т.д
Visual C++ .NET - можно писать как при использований CLR так и без прокладки, скорость работы кода выше, чем у C#.
Соотвественно нужно иметь больший уровень мастерства, чтобы писать на C++, чем C#?


И да,
конечно Visual Studio, мы за легальный софт

Выделенное - весьма спорное утверждение.
Примерно такое же, что "С++ медленнее и жирнее, чем С, ибо оверхед..."

А я бы именно на C# глядел. Именно по причине кроссплатформенности (не только win/lin, но и web/android/etc.).

Ваши - не подходят, а чьи-нибудь может и подойдут :-)
Я к примеру про FlowStone и слыхом не слыхивал, но мне подсказали. Здесь же много различных специалистов есть. Не все же только на Си или Дельфи.

Предпочтения - есть. Но не думаете же Вы действительно, что я испробовал всё на свете.
Multi multa sciunt, nemo omnia.



Сообщение отредактировал Меджикивис - Apr 19 2012, 08:10

Тогда в чем преимущество C++ перед C#?
А если не пользоваться CLR для C++ (консольная утилита win32 на С++ и консольная утилита на C#) тогда кто выиграет C# или C++?