ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Среда
17 июля
584697 Топик полностью
fk0, легенда (09.03.2015 18:55, просмотров: 199) ответил scorpion на Вам тут всем смяшно, а у меня сейчас трудный выбор - какую именно кроссплатформенную среду выбрать для научных программ. Работа с СОМ-портами и интернетом обязательна. Обязательно Си-шный код, 2D и 3D визуализация данных. Крайне желательна
Если тебе нужна "среда", то увы, не знаю. А вообще Tcl/Tk. Со средами там правда плохо (их есть и много разных, но лучше сразу забыть). Основной рабочий инструмент -- редактор текста, makefile, окошко консоли. Какие актуальные задачи могут быть: 1) графический интерфейс. Он может быть закодирован на чистом Tcl (без C), но конечно придётся освоить и приобрести навык программирования сколько-нибудь развесистых гуёв. Проблема в том, что программировать можно сильно по-разному, в отличии от C/C++ библиотек, где сама библиотека задаёт единственный верный путь. Для гуёв с более чем парой окон лучше сразу взять какую-либо объектную систему в помощь, например XOTcl (окно как объект -- внешние интерфейсы позволяют его воспринимать на уровне логики программы, а внутри делается собственно гуи). Возможно писать и на C/C++ через libtk, но трудно, легче, чем программировать под Win API на голом C, но всё равно путь тяжёлый и вряд ли рациональный. Только если для отдельных окон (нужно сделать свой виджет, нужна скоростная визуализация данных...) Здесь основная идея либо сделать pixmap положенный в окно и обновлять в нём картинку, либо взять у Tk окно и далее средствами ОС. На linux можно было просто сторонние программы интегрировать в окна Tk, на windows тоже теперь можно, через twapi. Можно gnuplot там запускать, если нужно или mplayer... Но вообще конечно GUI на Tk несколько бедненький, не такой как в Qt. И во многих местах весьма консервативен, например, ComboBox по-моему до сих пор отдельной библиотекой через пень-колоду делается. 2) работа с компортами и сетью: может писаться и на Tcl и на C/C++ с использованием функций libtcl (для кросплатформенности), как именно поступить зависит от ситуации. На tcl можно написать всё (как на языке), но возможно не стоит писать на нём больших программ (см. ниже). Для udp используется отдельная библиотека (ввиду чего, сложные и низкоуровневые сетевые вещи, возможно проще написать на C, благо между linux/windows значимых различий нет). С другой стороны SSL и т.п. -- всё из коробки может работать, HTTP тот же, и клиент, и сервер, и парсер HTML, и даже браузер (примитивненький) есть. 3) логика программы собственно. Её можно реализовать на Tcl, но здесь есть подводный камень -- Tcl является интерпретируемым языком и все ошибки в коде будут выловлены только в момент исполнения. Что вообще может быть реальным затруднением для больших (от нескольких тысяч строк) программ. Поэтому я бы приоритеты расставил так: C++, Tcl, C. Преимущество C++ в том, что можно чётко выделить интерфейсы, и в том, что он компилируемый. Если нет значимого опыта программирования на C++, то Tcl, потом C. К слову о питоне или джаве. Недолюбливаю и то и другое, но вынужден признать. Java сама по себе может быть альтернативой... Как и связка Python/Tk, например. Последнее, возможно, наиболее интересно: логика может быть реализована на Python, GUI на Python/Tk, что-то в виде скриптов на Tcl, от которого (при наличии Tk) всё равно уже не избавиться. Собственно C-код тут можно с Tcl связывать и из питона через Tcl использовать. Хотя, наверное, слишком развесисто и тяжело (надо владеть и Python'ом и лезть глубоко в дебри Tcl всё равно придётся). Плюс питона в компилируемости и наличии единой объектной системы (в Tcl их 100500 разных). 4) какие-то дополнительные библиотеки -- свободно интегрируются любые C/C++ и Fortran библиотеки. Для использования непосредственно из Tcl пишется код реализующий новые Tcl-команды на C/C++. Для этого можно использовать SWIG, но я бы не рекомендовал -- в нём потом чёрт ногу сломит, притом, что интеграция C и Tcl самая простая среди прочих языков (Java, Python, Perl...) Tcl ещё хорош, что уже имеет массу Tcl библиотек или биндингов к существующим C-библиотекам (базы данных, работа с сетью, WinAPI, огромная масса всего немного лишь уступающая CPAN). В том числе и визуалиции. Читать wiki.tcl.tk как основной источник информации. 5) Печать на принтер. Вопрос решаемый (в отличии от многих "linux/windows" тулкитов... я конечно не в теме уже, но из python, из Gtk раньше с этим трудно было). Есть способ отпечатать canvas из Tk в postscript -- это для linux. Для windows есть альтернатива: http://www.schwart …com/tcl-tk/tcl-tk.html Там правда местами есть ряд ньюансов, но всё ж позволяет получать и текст разными шрифтами, и графику. 6) огранизация инсталлятора и единого exe-шника. Инсталлятор можно взять nsys. Второе решается разными методами, в зависимости от того как всё устроено. Если "приложение" преставляет из себя всё же C/C++ код скомпонованный в libtcl и libtk, то нужно будет написать код (на C/C++) который откуда-то возьмёт скрипты и скормит их интерпретатору. Хоть из файловой системы, хоть из виртуальной файловой системы в базе данных типа metakit добавленной к концу exeшника (чтоб юзер руками не правил, если это критично). Если логика на Tcl, то есть готовое решение, которое в принципе делает то же самое -- Tclkit (позволяет все ресурсы и интерпретатор, и нужные библиотеки засунуть в один exeшник). Там, правда, тоже есть ньюансы, но всё поправимо. Но повторюсь. Увы. Единой IDE, чтоб в редакторе наговнокодить и нажать кнопочку "make installer" -- нет. Всё руками. Нет, есть конечно ActiveState Tcl, но за него во-первых деньги платить, во-вторых там могут быть специфические проблемы которые тривиально правятся, когда всё сам собрал из исходников (за себя говорю: были проблемы с неустановкой русской локали в Tclkit, были проблемы с печатью еврейскими шрифтами на принтере вместо русских), но в IDE ты уже не поправишь ничего.
[ZX]