IT в России и мире в реалиях мирового кризиса

Цитата: barracuda1 от 28.12.2016 06:55:22А что вам мешает сменить приват на паблик? (да и другие методы доступа есть)

Доступ останется симметричным. Будет открытым для чтения и для записи.


В "правильном" кодировании доступ к данным в ООП рекомендуется делать через методы. Для остального есть структуры, к ООП не относящиеся. Это распространенная мешанина в мозгах у сишников - использование подходов и стиля С в С++. Каждый инструмент требует соответствующего обращения.

Цитата: Lapsha от 28.12.2016 07:15:41Доступ останется симметричным. Будет открытым для чтения и для записи.


В "правильном" кодировании доступ к данным в ООП рекомендуется делать через методы. Для остального есть структуры, к ООП не относящиеся. Это распространенная мешанина в мозгах у сишников - использование подходов и стиля С в С++. Каждый инструмент требует соответствующего обращения.

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

PS: Просто задачи передо мной - обработка видео "на лету"

На ваш взгляд такой доступ к данным приемлем при необходимости обеспечить FullHD качество с дополненной реальностью в реальном времени?

Цитата: barracuda1 от 28.12.2016 07:49:02На ваш взгляд такой доступ к данным приемлем при необходимости обеспечить FullHD качество с дополненной реальностью в реальном времени?

Это сильно зависит от общей конфигурации железа, на котором все исполняется. Главным образом связки ЦПУ и графического ускорителя.


Но для реального времени, да еще и HD, да еще и манипуляцией битами в runtime, я не думаю, что применение Jit-среды исполнения с GC вообще хороший выбор.
Плюс юзание GDI вместо прямой работы с видеобуфером (OpenGL или DirectX в конкретном случае Win). Drawing - это ж API для работы с GDI (GDI+), не так ли? Я не копенгаген в Шарпе.

Сами вызовы функций выглядят вполне некоряво. Но и только.

Цитата: slavae от 28.12.2016 08:56:45Как ни посмотрю на эти разыменования, аж дрожь пробирает )

Цитата: Lapsha от 28.12.2016 09:01:14Это сильно зависит от общей конфигурации железа, на котором все исполняется. Главным образом связки ЦПУ и графического ускорителя.


Но для реального времени, да еще и HD, да еще и манипуляцией битами в runtime, я не думаю, что применение Jit-среды исполнения вообще хороший выбор.
Плюс юзание GDI вместо прямой работы с видеобуфером (OpenGL или DirectX в конкретном случае Win). Drawing - это ж API для работы с GDI (GDI+), не так ли? Я не копенгаген в Шарпе.

Сами вызовы функций выглядят вполне некоряво. Но и только.

К сожалению взять битмап могу только так,  так как передается из другого плагина написанного на шарпе (кстати приведенный код это С++)
Далее DirectX в связке с OpenCV (кстати во многом использующим ГПУ) и Point Cloud Library (PCL)

Цитата: barracuda1 от 28.12.2016 09:12:27кстати приведенный код это С++

Сбили с толку заглавные буквы в названии подключаемых библиотек: IO, Drawing. Сильно "неклассический" с-шный и с++-шный стиль. С .NET не работаю и не работал, там же все унифицировано для всех сред исполнения, насколько я знаю.

Цитата: Lapsha от 28.12.2016 09:21:11Сбили с толку заглавные буквы в названии подключаемых библиотек: IO, Drawing. Сильно "неклассический" с-шный и с++-шный стиль. С .NET не работаю и не работал, там же все унифицировано для всех сред исполнения, насколько я знаю.

Это CLRные библиотеки, using namespace System :: Drawing :: Imaging;
раньше тоже с ними никогда не работал, а вот пришлось

Цитата: barracuda1 от 28.12.2016 07:49:02Так то да, но изначально вопрос ставился о времени обработки данных.
К примеру в шарпе сборщик мусора может и хорош (как меня некоторые уверяют), но на мой взгляд тратит уйму времени по сравнению с прямым доступом к массиву

PS: Просто задачи передо мной - обработка видео "на лету"

На ваш взгляд такой доступ к данным приемлем при необходимости обеспечить FullHD качество с дополненной реальностью в реальном времени?

Видео в реальном времени надо обрабатывать прямо на GPU, например с помощью OpenCL, если конечно имеется такая возможность и выделенная видяха.

Цитата: Lapsha от 28.12.2016 05:32:39Это тривиально реализуется заданием private модификатором соответствующего свойства плюс public/protected  модификаторами соответствующего getter/setter метода(-ов). Если только readable - отсутствие открытого сеттера.
Самые основы правильного кодирования на языках ООП.
Модификаторы readable/writable - ненужная перегрузка лексики.

Через жопу не надо -- нужна возможность четко и просто различать члены по паре бит-флагов RO, WO в защищенной области. При этом никто не мешает геттеристам лепить  в открытой области свои геттеры и сеттеры. Одно другого не касается.
Тем не менее, насчет get Вы просто рассмешили. get -- это из баз данных и пусть там и остается. Оно, кстати, там группируется с put, а не set. Геттер не должен содержать подстроку "get". Нормальный геттер-стиль предполагает именование закрытых объектов с префиксом, а их получение просто именем, например так

class foo_t {
  uint32_t $signature;
  uint32_t $data_sz;
public:
  signature() {return $signature;}
  data_sz() {return $data_sz;}
}

а стиль get_foo() set_foo() напоминает peek() poke() (блеванул....)

Цитата: barracuda1 от 28.12.2016 06:55:22А что вам мешает сменить приват на паблик? (да и другие методы доступа есть)

В подавляющем большинстве случаев нужен приват по записи и паблик по чтению. И чтобы это было четко видно и понятно. И было бы очень хорошо, чтобы это grep'илось в одну простую команду.

Цитата: adolfus от 28.12.2016 23:43:55В подавляющем большинстве случаев нужен приват по записи и паблик по чтению. И чтобы это было четко видно и понятно. И было бы очень хорошо, чтобы это grep'илось в одну простую команду.

В подавляющем большинстве все эти приваты вообще не нужны, и существуют только "от дурака".
При условии, конечно, писать программу внятно и внимательно.

Цитата: Valery от 22.12.2016 00:26:17На любых серверах x86/x64 я коррекции ошибок тоже не встречал. Возможно, сервера маленькие были. Буду рад ликбезу.

Любая серверная память, где в названии есть аббревиатура "ECC". Причём сейчас используется ECC+контроль чётности, поэтому ошибка будет только если в 64 битах ячейки произошли сразу 2 ошибки, ошибка в одной ячейке автоматически исправляется.
А вот если будет 2 ошибки, обычное поведение для материнской платы сервера сообщить, что произошла "uncorrectable memory error" и сделать ресет ОС.

Цитата: DarkRaider от 26.12.2016 12:55:25Я понимаю душевную боль и тоже его недолюбливаю, но "работа тем сложнее чем меньше в ней понимаешь", да и качество первоначального кода не факт что нормальное. Вот и приходится "отлаживать месяцами".  Уверяю, что проблем с отладкой чужих проектов на других языках не меньше.




1) Действительно, системы реального времени бывают 2х типов: QNX и сотоварищи (их много, в том числе самоправленных разными концернами) и WIndows-style (WinCE).   Из них полноценные - только первые, так как CE - это система для написания "графических интерфейсов",   концепция у ней такая...   чтобы "не тормозила коммуникация с пользователем".

2) "терминальная часть" - это в описанном случае утилита командной строки, которая конвертирует "прожект" в G-коды и передаёт их в станок. А "Мегасапр" на жабе - это вполне себе самостоятельное приложение. Про него и речь. 

3) Ввиду того, что наблюдаю пром. оборудование довольно часто  - не все станки на RTOS. Достаточно их и просто на никсах.  Всё таки область использования RTOS тоже довольно специфична и не везде оно нужно.

1) на одного грамотного программиста С++ придется ~ 100 полуграмотных С++ и 1000 чайников от С++. Если делать проект как свободный художник с неограниченным временем- можете использовать любой инструмент.
Но если у вас стоит задача написать систему типа корабль "Буран" и сузить временные рамки -то.... пример F-35. (А Буран - это образец как надо, а F-35 как не надо) Почему первый взлетел а второй нет - подскажите? Тем более этому учат в российских ВУЗах... просто советский опыт считаете ненужным? Где набрать такое количество особо опытных работников для серьезных и крупных проектов - на дороге они не валяются, скопом не найдешь. Это золотые крупинки в громаде пустой породы.
А средненьких проще набрать - их больше. Вот под их уровень и должен быть инструмент, который дает на выходе сравнимый по качеству готовые программы. С++ как бы в это не вписывается, это очень сложный инструмент, не для всякого...
2) Сейчас такого понятия как "мягкая" и "жесткая" RTOS вроде как не существует. Так вот в жестким относились QNX и Co, а Линух, Dos, WinCE - к мягким RTOS. Различались они временем гарантированной обработки критических событий (я уже не помню, сколько это составляло).
3) У нас стоит огромное количество станков и я могу сказать, что ВЕЗДЕ исполняемые контроллеры работают исключительно на RTOS, токарные станки на DOSе, линия автоматическая многооперационная и многостаночная - на WinCE (и эта линия относительно свежаяя, электроника Сименс), есть один фрезерный на спец. Линуксе (однокомпьютерный), а те, что работают на  Windows XP в стойках находятся микроконтроллеры на RTOS, которые обрабатывают задающие G команды от "терминальной" (это я так назвал для удобства) ОС, которая может быть ЛЮБОЙ, ибо время обработки полученной информации от RTOS уже на этом этапе не критично.
А обработка сигналов в режиме реального времени очень даже критична и кроме RTOS этого не сделает никто (разве что это будет делать только чисто железным способом, а результат - на обычную ОС). Просто на сегодня удобнее сделать универсальный микроконтроллер с RTOS и подключать к нему блоки датчиков и исполнительных механизмов и обратной связью, чем городить специальные уникальные схемы управления (и такие автоматические линии/станки)  у нас есть - работают вообще на релюхах

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

Предполагаю новый подход к функционалу ПО систем управления:

Интерфейсы СУ

Цитата: ps_ от 29.12.2016 22:56:01Насколько я знаю, hard RTOS ГАРАНТИРУЮТ определенное время обработки события
А soft RTOS просто пытаються сделать как лучше

Насколько помню прерывание должно быть зарегистрировано за время гарантированного минимального интервала между последовательными  прерываниями.
"зарегистрировано" - значит что система вновь вернулась в состояние готовности зарегистрировать следующее прерывание и как минимум сохранила все данные, доставленные предыдущим прерыванием. Таким образом производительность процессора должна обеспечивать выполнение без прерывания некоторого числа необходимых команд, регистрирующих прерывания, как-то - сохранение регистров состояния и запись данных прерывания в приоритетную очередь обработки.

Цитата: Superwad от 29.12.2016 13:43:12Это горький факт. Теоретически и на бумаге С++ - стандарт, (как, например, и стандартизирован формат документов MSOffice), но когда доходит до дела, то имеем, что библиотека откомпилированная С++ не вызывается из других программ как положено (не С++), то оказывается, что реальные форматы существующих MSОффисов им не соответствуют.
  Так что теория и жизнь - это разные вещи

Какие-то глупости Вы говорите. Стандарт ISO/IEC 14882 не касается результатов компиляции, а всего лишь синтаксиса языка и того, что каждый элемент его должен делать. Собственно, как и все остальные стандарты на языки программирования. Результатом компиляции является объектный модуль. Форматов объектных модулей несколько и все они жестко стандартизованы. Но формат объектных модулей никакого отношения к стандарту ISO/IEC 14882 не имеет. Объектные модули могут быть организованы в библиотеки, которые опять же имеют разный формат. Одним словом, не несите чепуху, а просто ознакомьтесь со стандартом. В конце концов есть хорошие книги
Другое дело, что некоторые компиляторы не поддерживают некоторые элементы стандарта или поддерживают частично. Этим особенно страдают компиляторы Микрософт. Поэтому у многих из тех, кто пользуется виндовсами возникает такое же впечатление, как у Вас. При этом с++ и с являются самыми переносимыми языками.

Цитата: Og Alex от 29.12.2016 15:02:55Предполагаю новый подход к функционалу ПО систем управления:

Интерфейсы СУ

Ссылка битая

Цитата: Superwad от 29.12.2016 13:31:43Где набрать такое количество особо опытных работников для серьезных и крупных проектов - на дороге они не валяются, скопом не найдешь. Это золотые крупинки в громаде пустой породы.

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

Цитата: Поверонов от 30.12.2016 12:49:05"зарегистрировано" - значит что система вновь вернулась в состояние готовности зарегистрировать следующее прерывание и как минимум сохранила все данные, доставленные предыдущим прерыванием. Таким образом производительность процессора должна обеспечивать выполнение без прерывания некоторого числа необходимых команд , регистрирующих прерывания, как-то - сохранение регистров состояния и запись данных прерывания в приоритетную очередь обработки.

Не обязательно. Есть контроллер прерываний. Есть иерархия прерываний.
Прерывания таймера, например, приоритетнее обработки прерываний клавиатуры.
Последний раз, когда я писал в институте обработчик прерываний (2 или 3-й курс, если мне не изменяет склероз), контроллер прерываний хранил в своем стеке от 16 до 255 прерываний (вот не помню просто). Естественно, во время обработки прерывания таймера еще раз обработка прерывания таймера произойти не может.

Так что, если не страдать глупостями, типа ООП в обработке прерываний и грамотно составлять программу с учетом рекурсий, то их не нужно даже блокировать - cli / sti если мне не изменяет склероз.

Цитата: small__virus от 01.01.2017 08:17:13Не обязательно.

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