Member
Статус: Не в сети Регистрация: 25.11.2005 Откуда: краснодар
в общем есть поток в котором читается порт и оттуда берутся данные по nmea протоколу. будет еще один поток принимающий и отображающий данные по позиционированию в виде текста и точки на карте+данные по видимым спутникам итп(см стандартные навигацонные проги типа gisrussa). так вот я в раздумьях как логичнее универсализировать вход потока отображения данных и выход потоков чтения из порта(хочется сделать не только nmea). причем хочется сделать этот стандарт легкомодифицируемым т.е. чтобы по мере появления новых типов данных от приемника(например не только навигацию но и другие предусмотренные к примеру в nmea) можно было добавить их ко входу и выходу потоков не переписывая бОльшей части их кода(в идеале добавлением чегото типа дополнительного элемента массива(реализацию обработки этих новых данных внутри потоков пока не учитываем)).
Junior
Статус: Не в сети Регистрация: 09.09.2007 Откуда: Калуга-Москва
Как вариант можно поступающие данные преобразовывать в XML структуру, а затем передовать эти данные в поток отображения. При появления новых данных от приемника, надо будет добавлять новые узлы в XML структуру.
Приведу пример как я делал. У меня был сервер, который принимал GPS данные от объектов и отправлял клиентам, которые отображали эти данные.
Принимаю GPS данные и преобразую в XML структуру
Junior
Статус: Не в сети Регистрация: 24.12.2008 Откуда: Москва
Если уж С++, то логичнне использовать наследование. Появились новые данные - наследуемся от базового класа, добавляем новые мемберы и методы-обработчики
Member
Статус: Не в сети Регистрация: 25.11.2005 Откуда: краснодар
не. я на дельфях пишу. а xml пофигу на каком языке разбирать. методы не нужны. мне нужен просто объект(не в смысле тип object)-носитель информации чтобы можно было универсализировать входы-выходы потоков выдачи и приема данных. записать данные в этот объект это проблема потока который читает данные из порта и соотв прочитать их это проблема потока отображающего. сам промежуточный объект если и будет иметь методы то не связанные с чтением-записью носимых им данных а только обслуживающие для расширения-сужения набора носимых данных.
Junior
Статус: Не в сети Регистрация: 24.12.2008 Откуда: Москва
XML, конечно, хорошо и модно И логично использовать для сложных иерархичных структур, когда лень писать свой парсер.
Для простых данных можно обойтись и просто текстовыми строчками. Первый символ (или несколько символов) определяют тип данных в строке.
Member
Статус: Не в сети Регистрация: 25.11.2005 Откуда: краснодар
MaximQWERTY писал(а):
когда лень писать свой парсер.
если писать свой парсер то тогда вообще зачем делать универсальный вход и выход? тады мона сразу текст выдаваемый приемником отдавать потоку отображения-пусть сам разгребает. тока проблема в том что кроме nmea есть и еще протоколы связи с приемниками.
Junior
Статус: Не в сети Регистрация: 24.12.2008 Откуда: Москва
interface писал(а):
если писать свой парсер то тогда вообще зачем делать универсальный вход и выход?
Тогда встречный вопрос - чем свой парсер принципиально отличается от парсера, разбирающего XML? Ну и еще раз - для сформулированной задачи вполне достаточно передачи данных через типизованые текстовые строки.
Member
Статус: Не в сети Регистрация: 25.11.2005 Откуда: краснодар
MaximQWERTY писал(а):
Тогда встречный вопрос - чем свой парсер принципиально отличается от парсера, разбирающего XML?
тем что в случае xml уже есть стандарт а свой надо придумывать.
в общем решил пока сделать обычный объект с кучкой переменных и функциями импорта-экспорта xml.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения