Страниц: [1] 2 3 ... 10
 1 
 : Ноября 21, 2017, 10:09:43 am 
Автор pavel123__ - Последний ответ от mike
работет ftp://qnx.org.ru/

 2 
 : Октября 24, 2017, 06:33:23 am 
Автор Absolut - Последний ответ от da-nie
А никто не знает, как заставить моментикс в QNX 6.3 без SP3 прекратить анализировать код в редакторе (я так понимаю, именно из-за этого и все тормоза при работе)? Дело в том, что у меня в проекте добавились файлы и их теперь больше трёхсот. А эта IDE сходит с ума. Это проявляется в том, что она перестаёт компилировать, выводить сообщения об ошибках, импортировать новые проекты. Приходится стирать папку workspace - тогда заново начинает работать. Но с тормозами (я так понимаю, она базу анализа кода создаёт что ли?). Вчера два часа всего прожила от инициализации до сбоев.

 3 
 : Октября 23, 2017, 12:59:18 pm 
Автор pavel123__ - Последний ответ от lesav
Возможно будет полезным

http://lesav.ru/qnx/

 4 
 : Октября 18, 2017, 06:55:23 pm 
Автор da-nie - Последний ответ от da-nie
Цитировать
До тех пор пока вы планируете использовать это оборудование только совместно со своими программами и игнорировать версионность (развитие программ и оборудования) - до тех пор вы будете правы.

А так оно, обычно, и происходит. Покупая оборудование даже одного производителя (я сейчас говорю о высокоточном и сложном оборудовании с ценой из многих нулей - что в массовом сегменте я не знаю), все модификации работают только со своими компонентами и поставляются как единое целое. Заменять компоненты без доработки производителем нельзя. Часто такое оборудование имеет протоколы обмена для дистанционного управления - там часто даже не заморачиваются с проверкой целостности команд/данных. Как пример, приборы фирмы Agilent (а это классные приборы с  часто удивительными возможностями) - обычный COM-порт и текстовый протокол. Если цифра будет искажена, мы об этом не узнаем. Поэтому тут нюанс в том, что есть "как оно было бы универсально" и то, "как это сделано почти всегда на самом деле с учётом не нужной избыточности".

Цитировать
Вам вряд-ли понадобятся unit-тесты. Подозреваю что этот подход идет в разрез с вашими представлениями о разработке (если вас не беспокоит версионность протокола, и возможность проверки пост и пред -условий).

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

Цитировать
Проверяем общий результат - даем оценку о том удачное изменение или нет.

Вот с этим-то у меня и проблема. Например, есть последовательность действий, в которой важны внешние показания датчиков,текущие операции, время операций. Программа написана так, что эта последовательность ей самой и порождается в зависимости от ситуации (и набора ситуаций). Это напоминает, как человек из здравого смысла пытается не по шаблону решить задачу. То есть, самих ситуаций может быть сильно дофига (я их даже не уверен, что смогу все перечислить). Сейчас я не могу проверить, что все возможные случаи программа отрабатывает правильно.
В примерах этих самых тестов всегда тестируют некий примитив с элементарными действиями, но по факту на практике всегда имеется сложная логическая цепочка, которую протестировать будет очень непросто.

Цитировать
Unit-тесты не имеют никакого значения если вы не планируете развивать код, не подходите к проблеме через проектирование, или же решение проблемы должно быть найдено в кратчайшие сроки (с минимальным количеством людей).

Дело в том, что после очередного рефакторинга хорошо бы выполнить проверку в автоматическом режиме, что и позволяют Unit-тесты. Smiley А том получается так, что я кардинально перестроил отношения классов и теперь не уверен, что не забыл в каком-либо классе о каком-либо нюансе.

 5 
 : Октября 18, 2017, 02:11:36 pm 
Автор da-nie - Последний ответ от lastcross
Цитировать
Ну, inttype.h уже давно в Си компиляторах типа Keil и IAR лежат. Нет только с плавающей точкой и bool.
Речь о том, что теперь не нужно беспокоится будет ли поддерживать конкретный компилятор или нет эти типы. Достаточно знать что компилятор полностью поддерживает с++11 чтобы не беспокоится о том, что где-то нужно что-то подключить, задефайнить или изменить в коде. Т.е. наличие этих типы - гарантированы стандартом языка.
А так, разумеется у каждого компилятора/библиотеки были возможности использовать типы с конкретным размером байт.

Цитировать
Когда работа идёт с оборудованием, этот протокол чем-то напоминает внутрипрограммный обмен - вы же почти никогда ("почти" - потому что есть случаи, когда передаёте - например, Win32API такое практикует именно по причине разных версий Windows и одних и тех же программ) не передаёте в функцию версию передаваемой структуры/объекта и её размер?

До тех пор пока вы планируете использовать это оборудование только совместно со своими программами и игнорировать версионность (развитие программ и оборудования) - до тех пор вы будете правы. Но как только возникнет необходимость использовать старую программу с новым оборудованием или новый софт который должен работать с двумя версиями аппаратуры. Или вы начнете распространять отдельно аппарат и отдельно прогу, предоставляя другим разработчикам на любом удобном языке работать с аппаратурой (считайте вы публикуете свой API к аппарату) - все станет не таким уж и радужным. В упомянутом вами WinAPI размеры передаются/передавались отчасти потому, что этим обеспечивается и версионность, валидация и совместимость с другими языками.

Цитировать
Кстати, спрошу ещё кое-что. Что бывают unit-тесты я давным-давно знаю. Но вот как их делать - без понятия.
Вам вряд-ли понадобятся unit-тесты. Подозреваю что этот подход идет в разрез с вашими представлениями о разработке (если вас не беспокоит версионность протокола, и возможность проверки пост и пред -условий).
Да, они увеличивают время разработки. Как правило требуют наличие несколько разработчиков в команде (над одним проектом).
Они нужны скорее не для выявления ошибок в работе программы. Они для выявления ошибок проектирования. Например, когда программа разрабатывается итерационно, покомпонентно. И с самого начала, с первой итерации, можно описать такие тесты которые бы проверяли корректность основных принципов при проектировании. И по мере добавления/расширения/модификации/исправления модулей эти тесты будут проверять насколько новые модули соответствуют этим тестам(принципам).
И тут даже не вопрос с сокетами/мютексами. Без них есть что тестировать в сложных проектах.
Пример автомобиль:
Запуск системы зажигания не должен приводить к движению автомобиля. Вот это "требование" по сути и является юнит-тестом. Его проверяют каждый раз например когда модифицируется любой из под-модулей системы зажигания. Изменили что-то в системе зажигания, запускаем юнит-тесты, среди которых и проверка на движение про запуск. Проверяем общий результат - даем оценку о том удачное изменение или нет. Unit-тест не отменяет дальнейшее тестирование и не гарантирует отсутствие всех ошибок (все перекрыть не возможно ими)
Цитировать
1) Unit-тест - это отдельная программа или они встраиваются в основное приложение (что странно, на мой взгляд)?

Цитировать
2) Если это отдельная программа, то делают на каждый тест одну программу или всё тестирует одна программа?
Можно так, можно этак зависит от того как у вас построен процесс тестирования

Цитировать
3) Вот есть у меня класс кодирования/декодирования принятых/отправленных данных. Чтобы его протестировать, нужно написать тест, который будет размером в пять таких классов (ведь то же самое кодирование/декодирование потребуется реализовать в программе теста). И нет никакой гарантии, что в тесте не будет ошибки. Да и как, например, убедиться, что все состояния покрыты тестом? Передаваться-то может просто тьма самых различных данных.
Тесты требуют много скучного декларативного кодирования. Классов вам писать может придется и один, но как минимум на каждый метод понадобится отдельный тест-метод (это в лучшем случае). Но с другой стороны - unit-тесты они могут быть расширяемые. Например, проверить только конкретную функциональность, позже другую и т.д.
"Хуже" всего то - что unit-тест жестко привязан к проектированию, ну как хуже - если у вас неудачное проектное решение .. то готовтесь не только перепроектировать решение но и переписать тесты (старые не подойдут)

Цитировать
4) Ряд вещей вообще непонятно как проверять - например, передачу через сокеты/CAN/USB - там всё завязано на функции ОС и работы с аппаратурой напрямую.
Вы можете раздробить проверку - проверять свой код (первично) и взаимодействие со сторонним (вторично). Т.е. остановится на том, что на такие входные данные ваш код формирует выходные данные для отправки API ОС. У вас есть набор заранее просчитанных входных и выходных данных. И как бы вы не меняли в дальнейшем код который трансформирует входные данные к выходным - юнит-тест всегда проверит что на эталонных код работает (а значит с большой долей вероятности можно сказать - трансформация происходит правильно).

Цитировать
5) Не получится ли тест программы сложнее и объёмнее самой программы раз в 5? По моим прикидкам, так и получится. Smiley
Как правило - кода будет больше, да. Притом значительно. Unit-тесты не имеют никакого значения если вы не планируете развивать код, не подходите к проблеме через проектирование, или же решение проблемы должно быть найдено в кратчайшие сроки (с минимальным количеством людей).

 6 
 : Октября 18, 2017, 12:14:47 pm 
Автор da-nie - Последний ответ от da-nie
Цитировать
Ну, с 11-го стандарта у языка все стало проще

Ну, inttype.h уже давно в Си компиляторах типа Keil и IAR лежат. Нет только с плавающей точкой и bool.

Цитировать
Вот с этим не согласен, но в вашем случае вам же решать.

Когда работа идёт с оборудованием, этот протокол чем-то напоминает внутрипрограммный обмен - вы же почти никогда ("почти" - потому что есть случаи, когда передаёте - например, Win32API такое практикует именно по причине разных версий Windows и одних и тех же программ) не передаёте в функцию версию передаваемой структуры/объекта и её размер?

Кстати, спрошу ещё кое-что. Что бывают unit-тесты я давным-давно знаю. Но вот как их делать - без понятия. В статьях, обычно, они как-то как сами собой разумеющиеся идут (моки и стабы там всякие и т.п.). Я, обычно, такими вещами не занимаюсь и делаю всегда интеграционное тестирование (потому что почти 100% ошибки не в конкретных функциях и классах, а в их взаимодействии между собой - скажем, не в том порядке захвачены мюьтексы в разных объектах и произошла взаимоблокировка. Ну или просто не предусмотрена некая ситуация в программе в принципе, а она случилась.). Отсюда вопросы:
1) Unit-тест - это отдельная программа или они встраиваются в основное приложение (что странно, на мой взгляд)?
2) Если это отдельная программа, то делают на каждый тест одну программу или всё тестирует одна программа?
3) Вот есть у меня класс кодирования/декодирования принятых/отправленных данных. Чтобы его протестировать, нужно написать тест, который будет размером в пять таких классов (ведь то же самое кодирование/декодирование потребуется реализовать в программе теста). И нет никакой гарантии, что в тесте не будет ошибки. Да и как, например, убедиться, что все состояния покрыты тестом? Передаваться-то может просто тьма самых различных данных.
4) Ряд вещей вообще непонятно как проверять - например, передачу через сокеты/CAN/USB - там всё завязано на функции ОС и работы с аппаратурой напрямую.
5) Не получится ли тест программы сложнее и объёмнее самой программы раз в 5? По моим прикидкам, так и получится. Smiley

 7 
 : Октября 18, 2017, 12:51:11 am 
Автор da-nie - Последний ответ от lastcross
Цитировать
Отвратительно. Для языка тесно связанного с низкоуровневым программированием (я имею в виду Си) иметь гарантии в стиле "не меньше" просто идиотизм. Жаль. В книжках, вроде как, чётко пишут разрядность чисел, упоминая вот то, что я перечислил. А оказывается, гарантии в стиле "не меньше".
Ну, с 11-го стандарта у языка все стало проще

Цитировать
Не всегда это нужно. Протоколы работы с оборудованием низкоуровневые и версионности не имеют практически никогда..

Вот с этим не согласен, но в вашем случае вам же решать.

 8 
 : Октября 17, 2017, 07:29:17 pm 
Автор da-nie - Последний ответ от da-nie
Цитировать
В том то и дело что НЕ ВСЕГДА.

Это я не верно интерпретировал, что у Подбельского написано. Там написано, что они все inline, но фраза несколько неудачно построена, и я решил что ограничения на обычные inline-функции на эти функции не действуют (за исключением рекурсии, конечно).

Цитировать
Я понимаю что так проще и привычнее. Но до тех пор, когда протокол имеет фиксированную структуру/пакеты, пока нет версионности и пока не окажется что в разных протоколах нужны разные порядки сохранения/чтения данных.

Всё вы верно говорите, но случаи бывают разные. В данном случае такое делать просто нецелесообразно. Протокол после отладки больше не меняется никогда. Он жёстко зашивается в устройство и всё.

Цитировать
А это значит, что пользователь не может ни увеличить ни уменьшить их количество со временем и под конкретную конфигурацию.

Нет-нет, я настройки не передаю. Передаётся другое. Просто в этих настройках нужны константы и в другом тоже они же нужны.

Цитировать
Вся гарантия размеров типов в С++ сводится к этому

Отвратительно. Для языка тесно связанного с низкоуровневым программированием (я имею в виду Си) иметь гарантии в стиле "не меньше" просто идиотизм. Жаль. В книжках, вроде как, чётко пишут разрядность чисел, упоминая вот то, что я перечислил. А оказывается, гарантии в стиле "не меньше".

Цитировать
нужны протоколы, а протоколы должны быть более устойчивы к изменениям

Не всегда это нужно. Протоколы работы с оборудованием низкоуровневые и версионности не имеют практически никогда - она бесполезна. Как пример, протокол обмена по USB вот этого вот тепловизора. Всё жёстко задано и для тепловизора следующего поколения протокол другой.

 9 
 : Октября 17, 2017, 05:04:43 pm 
Автор da-nie - Последний ответ от lastcross
Цитировать
В смысле? Насколько я помню, все методы, реализованные в самом объявлении класса являются inline всегда
Вероятно я не точно выразился написав "нет никакой прямой связи"..
В том то и дело что НЕ ВСЕГДА. У каждого компилятора существуют свои ограничения и он на свое усмотрение мог взять и не встроить вашу функцию, даже если она реализована в хедере. Просто потому, что она вызывает внутри себя что-то виртуальное, содержит какие-то сложные циклы/условия.
Да, в целом существует требование на встраиваемость функций/методов если такое поведение ожидается получить между разными единицами трансляций - тело методов должно быть в хедерах. Но будет ли метод встроеным - решит компилятор в конечном счете, а не Вы. Вот и получается - что ожидание от inline всегда немного преувеличены.

Цитировать
В ранних стандартах порядок хранения в контейнерах не регламентирован. Это только сейчас так. Я понятия не имею, что умеет в QNX 6.3 компилятор и стандартные библиотеки.
Все то время в течении которого я программирую на с++ - все это время std::vector был последовательным контейнером который предоставлял доступ к единому/цельному куску памяти (аля массив).
Другое дело, что у вектора не всегда был метод data(), но вот с &vect[0] - всегда решал поставленную задачу.

Цитировать
А в структуре, которая передаётся как поток байтов, вектора внутри быть не должно - требуется ведь передать его содержимое, а не внутреннюю структуру вектора.
О том и речь, что ваша структура не только хранит/представляет данные, но она то по сути знает как данные должны передаваться.
Я понимаю что так проще и привычнее. Но до тех пор, когда протокол имеет фиксированную структуру/пакеты, пока нет версионности и пока не окажется что в разных протоколах нужны разные порядки сохранения/чтения данных.
Относительно вашего случая - вы уверены что на этапе компиляции размер настроек известен. А это значит, что пользователь не может ни увеличить ни уменьшить их количество со временем и под конкретную конфигурацию. Вы передаете настройки "на другую сторону", а значит на принимающей стороне работает программа собранная в соответствии и согласованная по размеру этой структуре настроек. Все это до тех пор, пока у вас есть доступ к синхронному обновлению бинарника программ для передатчика и приемника.
Мое замечание относится к тому, что не составляет труда определить методы внутри хотя бы того-же:
Код:
size_t SData::save(char *to);
size_t SData::load(char *from);
Упрощенно, но .. Внутри которых, как хотите так и читаете. И можете дописать/прочитать данные которые в структуре не хранятся явно, а можете предварительно проверить пред- и пост-условия (чтобы понять насколько пришедшие данные вообще cответствуют ожидаемым)

Цитировать
По-моему, только int и long double могут иметь машинозависимую длину.
Вся гарантия размеров типов в С++ сводится к этому
Код:
1 == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long).
Про это можете почитать тут

Цитировать
Это будет редкий *дец. Smiley Структура состояния ...
...
Но... зачем?
Объяснение дано было выше - представление структуры в памяти программы вообще может не совпадать с представлением данных при передаче. Хотя бы по тому что для передачи данных - нужны протоколы, а протоколы должны быть более устойчивы к изменениям (модификациям программ). Как правило - новые программы должны работать/взаимодействовать со старыми данными (версиями программ). Так принято. Люди не любят терять наработанные данные только потому-что вам вздумалось изменить структуру представления внутри программы

 10 
 : Октября 16, 2017, 08:43:02 pm 
Автор da-nie - Последний ответ от da-nie
Цитировать
Кстати вообще нет никакой прямой связи что будет собираться встраиваемо а что нет. Метод может быть и встраиваемым даже если его реализация внутри cpp-модуля (яркий пример лямбды)

В смысле? Насколько я помню, все методы, реализованные в самом объявлении класса являются inline всегда (и, полагаю, даже если там функция в 1000 строк будет, она всё равно будет встраиваемой). А вот отдельная вынесенная реализация уже будет как удобно компилятору (если указать inline для такой функции, конечно).

Цитировать
Но могу предположить, что в упрощенном варианте ваш объект может хранить/ссылаться на разные наборы "констант"

Нет, это, к счастью, не потребуется. Smiley

Цитировать
Проблемы среды разработки - это только проблема среды разработки, а не языка.

Не спорю. Но забавно видеть, когда компилятор падает от написанного. Smiley

Цитировать
Если же вы хотели обеспечить контракт вызова - то следовало вероятно сделать конст-метод. Это когда const в конце объявления метода

Я знаю, как это делается. Smiley А зачем я возвращаю как const? Да просто это больше информация для компилятора  - так, на всякий случай.

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

Касаемо вектора - я где-то прочёл, что это не всегда так (я имею в виду, предложенный вами мне когда-то вариант с &vect[0]). В ранних стандартах порядок хранения в контейнерах не регламентирован. Это только сейчас так. Я понятия не имею, что умеет в QNX 6.3 компилятор и стандартные библиотеки.
А в структуре, которая передаётся как поток байтов, вектора внутри быть не должно - требуется ведь передать его содержимое, а не внутреннюю структуру вектора.
Я имею в виду:
Код:
struct SData
{
 unsigned long Size;
 struct SUnit
 {
  unsigned char Data[128];
 }
 vector<SUnit> vector_SUnit;
} sData;

Translate(&sData,sizeof(SData));

Translate(&sData,sizeof(SData)); - будет передан ведь вовсе не SUnit[заданное количество] внутри.

Цитировать
По-тому что, в ++ нет гарантий к размеру всех типов

По-моему, только int и long double могут иметь машинозависимую длину. Char имеет компиляторозависимый знак. Float мог быть произвольный - в старых компиляторах не по стандарту IEEE. Порядок же кодирования big или little-endian может меняться, это да. Остальные стандартные типы заданы жёстко (ну, может, double ещё схож с float). Про допкод не уверен, но, думаю, что он гарантируется.
Вообще, тут уже действует соглашение на протокол обмена по устройствам, где порядок данных описан как little-endian, допкод для переменных. Все устройства у которых это не так должны сами перекодировать данные.
Исключение составили разработчики из ЛОМО - они у нас отличились и вляпали свои числа в... прямом коде. Говорят, вояки всегда с ним работают. Заставить переделать не удалось. Ну и ладно - хоть один урод в списке аппаратуры комплекса непременно должен быть. Smiley

Цитировать
Кроме того - создав отдельный метод сереализации/десереализации - всегда можно контролировать правильный порядок байт (иногда есть большая разница как данные должны хранится оптимально и как передаваться/сохранятся по протоколу)

Это будет редкий *дец. Smiley Структура состояния устройств с подструктурами по типам принятых данных это около 500 строк. Их передача/приём с разложением на байты породит большущий код. Но... зачем?

Страниц: [1] 2 3 ... 10