POV (04.04.2025 11:46, просмотров: 264) ответил Andreas на Господа ПЛКшники и автоматизаторы, это реально такая хня в
промавтоматике-
- Вот, что интересно: на МК значительно проще прошивку написать. Но
нет, зачем-то народ пишет на псевдо-ЯП, которые мало того, что
убоги, так еще и сильно ограничивают творчество ☺ Eddy_Em(216 знак., 04.04.2025 12:28, ссылка)
- Сейчас модная хрень протискивается через все щели - стандарты функциональной безопасности - IEC 61508 и туча подобной фигни. Вот это гадость... Опять "пиво только членам профсоюза"(C). Голый компилятор как средство разработки по сути ставят вне закона - Vit(05.04.2025 09:43)
- В ограничении творчества весь смысл - гораздо меньше возможностей
выстрелить себе в ногу. Тоже заменял в ПЛК прошивку на свою и мой
код на C/C++ таки портит ОЗУ по неизвестному адресу, что в исходном
псевдо-ЯП было принципиально невозможно. AlexG(304 знак., 05.04.2025 05:50)
- Обычно либо выход за пределы массива, либо указатель не туда
указывает. Поэтому нужно не пользоваться указателями, все
переменные только uint32_t либо int32_t. А чтобы не напрягать стек,
все переменные должны быть глобальными, их можно паковать в
структуры. Сейчас в меня начнут кидать тапками 😂😂😂 - Бoмж(05.04.2025 20:43)
- Там было не так просто. Использовался указатель на метод объекта,
причем объекты были разных классов. C++ такое штатно не умеет (по
крайней мере, не таким способом и не в той версии) и работало это
путем черной магии и спецбиблиотеки. Как выяснилось, с побочными
эффектами. - AlexG(06.04.2025 05:35)
- Создание родительского класса с общим методом и наследование от
него — это как раз правильный объектно-ориентированный подход,
который решил бы проблему без "черной магии" и спецбиблиотек. Бoмж(1292 знак., 06.04.2025 16:48)
- всё было переписано по варианту 1.1. Способы 1.2 и 1.3 не выглядят сильно полезными чтобы связать два объекта во время выполнения. AlexG(172 знак., 06.04.2025 22:25)
- Создание родительского класса с общим методом и наследование от
него — это как раз правильный объектно-ориентированный подход,
который решил бы проблему без "черной магии" и спецбиблиотек. Бoмж(1292 знак., 06.04.2025 16:48)
- Еще и вступим в сговор и будем кидать только левые тапки. Ни одного правого :) Cкpипaч(91 знак., 05.04.2025 20:50)
- Тапок, брошенный по правилам языка Rust, не может причинить вреда. Тапок, брошенный по правилам языка Си, может уничтожить всё живое в радиусе 100 м. - SciFi(05.04.2025 20:47)
- Там было не так просто. Использовался указатель на метод объекта,
причем объекты были разных классов. C++ такое штатно не умеет (по
крайней мере, не таким способом и не в той версии) и работало это
путем черной магии и спецбиблиотеки. Как выяснилось, с побочными
эффектами. - AlexG(06.04.2025 05:35)
- Куда смотрят адепты Rust?:) - Vit(05.04.2025 09:36)
- Обычно либо выход за пределы массива, либо указатель не туда
указывает. Поэтому нужно не пользоваться указателями, все
переменные только uint32_t либо int32_t. А чтобы не напрягать стек,
все переменные должны быть глобальными, их можно паковать в
структуры. Сейчас в меня начнут кидать тапками 😂😂😂 - Бoмж(05.04.2025 20:43)
- Я лично наблюдал подобные (лицензионный еще советский клон сименса) ПКЛ на вазе - очень интересная вещь. Для адаптации к задаче не нужны программисты, нужен обученный "писать" в некоторой оболочке на ноуте циклограмму работы. И их таких обюученных полно. - POV(04.04.2025 12:35)
- Да! Кто-то запустил Doom на переходнике Apple Lightning -> HDMI. Ну а что? Проц не должен простаивать! SciFi(2 знак., 04.04.2025 12:35, youtube, картинка)
- Вот, что интересно: на МК значительно проще прошивку написать. Но
нет, зачем-то народ пишет на псевдо-ЯП, которые мало того, что
убоги, так еще и сильно ограничивают творчество ☺ Eddy_Em(216 знак., 04.04.2025 12:28, ссылка)
