1. Однозначно, но учтите на странице таких ситуаций море - а вообще не очень понятно зачем? При симуляции все значения - видны - подкрасьте отрицательное красным да и всё! Но, самое главное - не симуляция! По факту, проект - не собирается.
2. Не понятна "жалоба" на внутренне ПО. Теперь переход через 0 в запрете? Почему? Хотите сказать реле перегрузится? ОСТОРОЖНО! ТАК ДЕЛАТЬ НЕЛЬЗЯ!
3. Иногда использование особенностей перехода через 0 ОЧЕНЬ НЕОБХОДИМО, например 0 - 1 = $FF...FFF - Максимальное целочисленное число, или полная битовая маска - очень удобно иногда, особенно при построении логики путем умножения.
4. Отрицательные числа - вещь необходимая! Переполнение (переход через 0) - это целенаправленный вариант реализации типа int на word (что и задокументировано в овенлогике ((V1 + 0x100000000) – V2) )! Вообще, отнимать 1 добавляя $FFF...E к числу - ЭТО НОРМАЛЬНО для хорошего программиста, т.к. иногда проще менять константы чем делать кучу ветвлений!
5. НИКОГДА! НИКОГДА! НИКОГДА! НИКОГДА! НИКОГДА! Не меняйте в языке программирования (а овенлогик по сути графический язык) уже работающий задокументированный функционал - ваши покупатели проклянут Вас и не будут покупать вашу продукцию, т.к. не всегда есть возможность откатиться на версии 5-6 летней давности. А самое главное помните - самое ценное у любого программиста - его наработки, он достает оттестированный, облизанный макрос 10 летней давности и вставляет его в проект и уверен - он должен работать! И если его поведение поменяется - то ведь и станок можно загубить и не дай бог человека убить. Кто будет виноват? Поменяли функционал - меняйте название языка. А хотите складывать (вычитать) с контролем переполнения пожалуйста:
5. Если кто-то захотел сделать проверку переполнения - то для этого в ассемблере есть флаги, процессоры от этого как правило не "страдают". Добавьте НОВЫЕ МАКРОСЫ! ПУСТЬ ТАМ БУДЕТ ДВА ВЫХОДА (результат и переполнение)! МЫ ВАМ СКАЖЕМ ТОЛЬКО СПАСИБО. Главное в документацию их не забудьте добавить. В овенлогике катастрофически мало наборов базовых макросов (одна работа с реальными числами чего стоит), пусть растет их ЗАДОКУМЕНТИРОВАННОЕ число, а не меняются функции.
З.Ы. Коллеги помните! В любых более менее серьезных проектах, сперва создаётся документация (описываются интерфейсы, функции, параметры, поведение) и ТОЛЬКО потом делается функционал. Действия в обратном порядке - приводят к тупикам, грубым ошибкам и срывам сроков. Документация может быть плохой, на кусочке бумажки, в виде схемы, но должна быть!





Ответить с цитированием