Pingvin писал(а):
Тоже схлопотали полбу граблями?!
Структуры хотели потоком передавать?
Не прокатит.
Какими граблями, о чём Вы?
Я, вообще говоря, не первый день программирую
"Сериализация" - классическая задача, возникающая почти в каждом проекте. Кросс-платформенная сериализация/десериализация - задача уже нетривиальная, имеющая множество решений. Это почти всегда "ручное формирование пакетов". Я просто решил эту задачу некоторым подходящим для данной ситуации образом.
А передавать структуры "как есть" между программами, написанными на C/C++ на одной и той же платформе - можно. Но только осторожно
Главное, понимать, что при этом происходит. Само собой это не применимо к Q_OBJECT для Qt, да и ни к какому другому полиморфному объекту. Само собой, для структуры должна быть отключена упаковка ( #pragma pack(push, 1) и т.п.), структура не должна даже содержать указателей и т.п. - ещё можно немало нюансов привести.
Pingvin писал(а):
Поэтому нужно пакеты формировать "ручками", а для этого и нужен транспортный протокол.
О чем я ранее писал, но понимания не нашёл.
Так у меня есть протокол передачи бинарных данных + вся инфраструктура для удобной работы с ним (это где-то 1500 строк С++-кода с комментариями, и это только для формирования/парсинга пакетов, без пересылки). Там всё более-менее по уму сделано. Он даже кроссверсионную совместимость поддерживает, как вверх, так и вниз
Например, чтобы послать оружию команду на воскрешение с дефолтным таймаутом и другими параметрами пакета, нужно написать одну строчку:
Код:
RCSPStream::remoteCall(rifleAddress, ConfigCodes::Rifle::Functions::rifleRespawn);
Но это протокол уровня представления, а что Вы называете "транспортным протоколом", и как это относится к сериализации, я не совсем понимаю (
https://ru.wikipedia.org/wiki/%D0%A1%D0 ... %D1%8C_OSI )
Pingvin писал(а):
С типами я тоже накалывался, хоть и на Qt пишу.
Но у меня все нормально с транспортом, слава Богу.
Могу 64 кБт плюнуть в одном пакете.
Аватарки и эмблемы так и передаю - одним пакетом.
С Андроид приложением администратора игры и приложением-клиентом для смартфона все базовые вещи так же решены.
Осталась рутина...
На мой взгляд, передача данных - это больше похоже на рутину... А вот как потом из этого сделать изящную игровую систему - тут придётся думать.
Pingvin писал(а):
P.S. Безумно рад, что не приходится тратить время на изучения Java, не потому что не хочу, просто время дорого.
Я потратил дня 4 на вялое изучение Java, и сейчас знаю достаточно для разработки. Всё остальное - по ходу придёт. Ведь Java проще, чем C++, но во многом похожа.
Изучать приходится не джаву, а Android. Без этого на любом языке не обойтись. Activity, Intent, Service, Handler, да просто блютус-стек - это всё только Android-specific. Ни знание C++, ни знание Java сами по себе не помогут, будет одинаково сложно. Разве что на Java управление ресурсами существенно проще, и обертки не нужны.
Также, разработка одного и того же кода на Java происходит быстрее, чем на C++ почти всегда. Другое дело, что производительность кода не та, и 3d-шутер на java как-то не очень писать
Pingvin писал(а):
Alexies писал(а):
...При разработке под микроконтроллеры есть существенная проблема: создание Unit-тестов нетривиально. А вот под Андроид я, само собой, тесты использую: это существенно ускоряет разработку и поиск ошибок. Товарищи, используйте тесты (если это не очевидно и так), это очень помогает!
Вы это сейчас с кем разговариваете?
Можно как-нибудь попроще объяснить?
Что за тесты?
Это я риторически, ко всем программистам мира обращаюсь
Я про обычные Unit-tests...
Юнит-тест - это вспомогательная программа, которая тестирует некоторые компоненты (функции или классы) основной программы.
Смысл - ускорение отладки за счёт нахождения ошибок на раннем этапе, а также и регрессионное тестирование.
Для этого есть разные подходы, на C++ (на "большом" компе, не на МК) я использую Google Test Framework, он простой. На МК, насколько я понимаю, какого-то общепринятого пути нет, приходится изобретать велосипеды.
Для джавы есть родной JUnit.
Вход
Регистрация
FAQ
Поиск
