LINUX.ORG.RU

Сложный выбор


0

0

Начинаю работать над проектом (тут надо бы слабать некую АСУ), не могу определиться с языком программирования: Java или C++?

У обоих языков вижу недостатки и преймущества, но не могу выбрать, на чём писать.

Java: + Простота написания кода + Простота документирования кода (да, я знаю для для плюсов есть doxygen, но здесь это нативно) + Мне очень нравится NetBeans IDE + Легко сделать расширяемость через плагины (хотя к проге C++ можно прикрутить lua или бидон) - Полная жопа с JNI (мне в любом случае придётся это использовать, не вижу другого способа взаимодействия с железом)

C++: + Простота поддержки нативного кода + Более высокая скорость работы (я помню про тест, где Java быстрее, но это не тот случай, когда код на яве будет работать быстрее) - Нет нормальной IDE, хотя Eclipse CDT очень даже неплох. Плагин C++ для NetBeans ужасен и неюзабелен - Сложно выбрать между GTK+2/Qt/wxWidgets. Пока придерживаюсь wx. Под него есть нормальный дизайнер интерфейса?

Часть кода уже написана на Java, но мне не составит проблем перенести это на C++.

Мне не важна кроссплатформенность, мне важно как можно быстрее и качественнее доделать то, чем занимаюсь.

Помогите, пожалуйста, с выбором. Заранее спасибо.


Re: Сложный выбор

> тут надо бы слабать некую АСУ

Имеется в виду АСУТП?

> Полная жопа с JNI (мне в любом случае придётся это использовать, не вижу другого способа взаимодействия с железом)

Я так понимаю, что это не Винда, и OPC-сервера нет. Вместо трахания с JNI можно поближе познакомится с CORBA - сделать работу с железом на Си++ в отдельном процессе и интерфейсится с ним через CORBA. Таким образом ты остаешься в привычной NetBeans, и пишешь на Си++ только необходимый минимум без заморочек с JNI (интерфейсится из Java к CORBA _гораздо_ проще).

tailgunner ★★★★★ ()
Ответ на: Re: Сложный выбор от tailgunner

Re: Сложный выбор

> Имеется в виду АСУТП?

Угу.

> Я так понимаю, что это не Винда, и OPC-сервера нет.

Конечно не венда :) Была б венда - здесь бы не спрашивал ;)

> Вместо трахания с JNI можно поближе познакомится с CORBA - сделать работу с железом на Си++ в отдельном процессе и интерфейсится с ним через CORBA.

Тогда надо будет трахаться с CORBA в C++. :) А вообще, идея интересная, можно где-нибудь посмотреть примеры?

> Таким образом ты остаешься в привычной NetBeans, и пишешь на Си++ только необходимый минимум без заморочек с JNI (интерфейсится из Java к CORBA _гораздо_ проще).

Охотно верю что проще, но мне очень интересно посмотреть код примера работы с CORBA в сиплюсплюс и яве.

EViL ()
Ответ на: Re: Сложный выбор от EViL

Re: Сложный выбор

>> Я так понимаю, что это не Винда, и OPC-сервера нет.

>Конечно не венда :)

Теоретически, OPC-серверы есть и под Линукс. Я сам не видел, но люди говорят :)

> Тогда надо будет трахаться с CORBA в C++.

По моему опыту, это гораздо приятнее, чем трахаться с JNI :)

> можно где-нибудь посмотреть примеры?

> очень интересно посмотреть код примера работы с CORBA в сиплюсплюс и яве.

Насколько я помню, в Сети их навалом. К omniORB идет вполне вменяемая документация. А примеры работы с Java есть в JDK (опять же - насколько я помню).

Кстати, если железо, с которым ты должен общаться, работает через RS232/RS485/RSещекакойнибудь, то с ним можно общаться из Java (IIRC java.comm, или просто открыть /dev/tty*).

tailgunner ★★★★★ ()
Ответ на: Re: Сложный выбор от tailgunner

Re: Сложный выбор

Тыкс... Я вспомнил через какое место в C/C++ работают со строками и юникодом, поэтому решил продолжать писать на Java.

>> Тогда надо будет трахаться с CORBA в C++.

> По моему опыту, это гораздо приятнее, чем трахаться с JNI :)

Хорошо, я посмотрю.

> Насколько я помню, в Сети их навалом. К omniORB идет вполне вменяемая документация. А примеры работы с Java есть в JDK (опять же - насколько я помню).

Насколько я знаю, GNOME работает с CORBA через какое-то ORBit (жевачка :)). Какую библиотеку (или что там) следует использовать?

> Кстати, если железо, с которым ты должен общаться, работает через RS232/RS485/RSещекакойнибудь, то с ним можно общаться из Java (IIRC java.comm, или просто открыть /dev/tty*).

Неее.. Не стану я писать работу с железом на Java. Сейчас я общаюсь с девайсом через COM-порт (RS-232?). В идеале, хочу сделать универсальную работу с COM, LPT, USB-портами.

EViL ()
Ответ на: Re: Сложный выбор от EViL

Re: Сложный выбор

> Я вспомнил через какое место в C/C++ работают со строками и юникодом

Мы работаем со строками через #include <string>. а не через то, о чем вы подумали :)

> Насколько я знаю, GNOME работает с CORBA через какое-то ORBit (жевачка :)). Какую библиотеку (или что там) следует использовать?

Гномам - гномовское, а людям - omniORB. По двум причинам: во-первых, если ты решишь пойти путем CORBA, то сразу за дверями тебя ждут грабли - в CORBA кошмарно неудобная Name Service. Но в omniORB есть очень удобная нестандартная возможность - адаптер omniINSPOA, в него можно заносить объекты сразу с именами, и он работает Name Service'ом за тебя. К объектам в этом адаптере потом можно обращаться из Java по URL corbaloc::хост:порт/имяобъекта. Во-вторых, к omniORB прилагается omniORBpy. Для тестирования - то, что доктор прописал, но это вполне настоящий ORB, на нем можно серверы писать без проблем.

> Сейчас я общаюсь с девайсом через COM-порт (RS-232?)

Да. оно. Но если тебе нужна поддержка USB, то тебе остается только Си++ (хотя из я слышал о биндингах libusb к Python :)).

tailgunner ★★★★★ ()
Ответ на: Re: Сложный выбор от EViL

Re: Сложный выбор

> Тогда надо будет трахаться с CORBA в C++. :) А вообще, идея интересная, можно где-нибудь посмотреть примеры?

http://www.cs.wustl.edu/~schmidt/TAO.html

хорошо работает и под *NIX и под Windows, вменяемая лицензия.

// wbr

klalafuda ★☆☆ ()
Ответ на: Re: Сложный выбор от klalafuda

Re: Сложный выбор

> http://www.cs.wustl.edu/~schmidt/TAO.html

> хорошо работает и под *NIX и под Windows, вменяемая лицензия.

...излажен под работу в реальном времени. Очень продвинутый и ОГРОМНЫЙ. Не имеет готовых сборок (по крайней мере, мне не попадались).

tailgunner ★★★★★ ()
Ответ на: Re: Сложный выбор от tailgunner

Re: Сложный выбор

> ...излажен под работу в реальном времени.

достаточно спорное утверждение и само по себе желание и стремление поддерживать RT CORBA ещё не показатель. впрочем, работает достаточно шустро и без особых нареканий.

> Очень продвинутый и ОГРОМНЫЙ.

ну огромный - это относительно. сам по себе ACE +ORB + POA, допустим, собираются где-то под мегабайт-полтора в .so. изрядную часть кода в дереве занимают различные примеры, готовые приложения, тесты регрессий и тд. и тп. в общем, неактуальная в реальной жизни хренотень.

> Не имеет готовых сборок (по крайней мере, мне не попадались).

а то надо? он прекрасно собирается как руками через свой config.h так и через штатный configure. народ в конференции публиковал что сделали сборки в rpm и AFAIR deb но я так понимаю большинству пользователей ACE/TAO это не актуально и все собирают сами под свои конкретные нужны.

// wbr

klalafuda ★☆☆ ()
Ответ на: Re: Сложный выбор от tailgunner

Re: Сложный выбор

> хорошо работает и под *NIX и под Windows, вменяемая лицензия.

> ...излажен под работу в реальном времени. Очень продвинутый и ОГРОМНЫЙ.

Мне не надо огромных супер-пупер-хреновин для передачи данных между двумя программами. Надо что-нибудь маленькое и простенькое.

Скачал таки omniORB, сейчас буду смотреть.

Уже нашёл офигенную статью про CORBA и Java: http://java.sun.com/j2se/1.4.2/docs/guide/idl/GShome.html

EViL ()
Ответ на: Re: Сложный выбор от klalafuda

Re: Сложный выбор

>> ...излажен под работу в реальном времени.

>достаточно спорное утверждение

Сужу по статьям разработчиков

> и само по себе желание и стремление поддерживать RT CORBA ещё не показатель

Ну, если это не показатель - тогда конечно

>> Не имеет готовых сборок (по крайней мере, мне не попадались).

>а то надо?

Желательно. Зачем собирать руками, если уже собрано?

tailgunner ★★★★★ ()

Re: Сложный выбор

Ну, java я для АСУТП вообще бы не рассматривал. (Замечу в скобках: опыт в АСУТП - 12 лет, в java - около года).

Если делать на C++ то встраивать скрипты, да... и если понадобится GUI, то его делать уже на скриптовом языке, а не напрямую из C++ кода. А лучше вообще вынести в отдельный процесс. Это если говорить про C++

P/S Хотя лично я на нем писать бы тоже не стал. Поскольку для задачь АСУТП зачудительно подходит erlang (GUI - через gtknode). Но это мой выбор - другим не предлагаю... :-)

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.