=DeaD= писал(а):Есть еще QtCreator с кроссплатформенностью.
Есть. Подскажите, в чем сакраментальная разница между Qt и wxWindows. Что бы посоветовали использовать? Почему?
Кроссплатформенность не интересует.
Добавлено спустя 2 минуты 30 секунд:noonv писал(а):я использую VC++
работу с джойстиком можно организовать через SDL.
Согласен. Хорошая идея. Хотя и придется "тянуть" с собой еще одну библиотеку.
noonv писал(а):для работы с последовательным портом, у меня есть класс, который я использую в своём кроссплатформенном мини-фреймворке, который работает с OpenCV и затачивается именно для робо-приложений.
(недавно добавил туда класс и для получения видеопотока от MJPG-streamer)
если интересно - в ближайшее время постараюсь выложить
Очень буду обязан, если пришлешь лично или выложишь на форуме!
Добавлено спустя 2 минуты 58 секунд:elmot писал(а):И не надо! Отменить эмуляцию порта = это абсолютно не нужный костыль! И работать напрямую через TCP сокет - поддержка асинхронной работы с сокетами должна быть в чем угодно.
Я только за! Но заново изобретать очередной велосипед не хочу. Дай plz ссылку или пришли свои наработки. Сам считаю, что виртуализировать ком-порт только для того, чтобы из него взять данные - лишние шаги. Но нужен пример реализации. Иначе игра не стоит свеч. Угадывать протокол на основе линуксовых исходников ser2net занятие очень трудоемкое. Есть наработки или готовые решения? Буду очень рад!
Добавлено спустя 1 минуту 25 секунд:dccharacter писал(а):дададада
в Qt например ничем не отличается работа с ком-портом и с ТСП-сокетом. методы те же, формат данных тот же...
Спасибо. Сам, я так понимаю, пишешь под Win+OpenCV+Qt. Расскажи plz о своей реализации. Мне очень интересно. Заранее спасибо.
Добавлено спустя 15 минут 57 секунд:Angel71 писал(а):"структура программы через _опу"
так мило. а ничего, что в vs/qt/eclipse/borland... можно создавать пустой проект, добавить в него всё необходимое и создавать "структуру программы не через опу"?
а если еще вспомнить, что визард тупо копирует заранее созданый проект, можно за пол часика набросать свой и пользоваться.
В этом и вся прелесть. Надеюсь, что ты не будешь отрицать это? Если твой проект, например нацелен на работу с БД, то ты, как программист, не должен "замарачиваться" о создании диалоговых окон, о событиях отрисовки кнопок и о прочей ерунды, которую, например, навязывает MFC. Программист должен быть нацелен на работу з БД и только с ней.
Конечно, можно до хрипоты спорить, что WinAPI, например, позволяет реализовать почти всё, но какой ценой. И почему я должен позволять своим программистам в отделе разрабатывать с нуля в WinAPI то, что на Delphi набросать пара минут.
Angel71 писал(а):и да, выбирать среду разработки исходя из того, что там есть/нет одного-двух простеньких класса, которые при знании языка написать совсем не сложно... круть.
При знании асма можно написать всё! Решительно всё. Вопрос какой ценой.
А заставлять людей писать пару классов там - для джоя, пару классов там - для ком порта, и пару классов там для работы, например, с socket-ами, пустая трата времени! Всё давно написано раз сто. Незачем писать всё с нуля. Просто необходимо найти правильные готовые реализации, а самому на целится на главную задачу - алгоритм поведения робота в динамически изменяющимся пространстве.
И вообще, я, конечно, староват уже для абсолютно новых решений, но CLR выносит мне мозг. Обрабатывать события элементов интерфейса (типа кнопок и прочей ерунды) в MainForm.h файле - header file - это сила! На такое способен только Microsoft.
Вот поэтому я говорю: "структура программы через _опу"
P.S. Еще раз повторюсь, если бы OpenCV интегрировался в Builder C++, то я бы здесь вопросы эти на задавал. Там всё есть.
)
Всё бы решило.
