AQ29 писал(а): Вс авг 09, 2026 13:34:53
Пока в разработке, так что ни у кого нет. Не собирался обсуждать среду, но затянуло.
Ааа, самопал... Ну тогда фигня, даже не обсуждаемо
Хосспидя, я так и предпологал, что чето там не так, поскольку на существующие макроассемблеры не совсем похоже. И слово "вменяемый" тут вообще никак не подходит. Обычный набор макросов в проприетарном стиле. Применимость - нулевая, полезность и преимущества - крайне спорные, если не сказать нулевые. Имеет ценность только для автора.
Макросы - это вообще очень устаревшая тема, пережиток прошлого. В современных языках от макросов вообще отказываются ввиду их неповоротливости. Например, в С++ вместо макросов - constexpr, consteval.
А то, что вы подразумеваете под макросами, в С/С++ называется функциями. Причем, функции более предпочтительны, поскольку имеют входные и выходные параметры, которые могут изменяться во время работы.
Пример функции:
Код: Выделить всё
int Sum(int a, int b)
{
return a + b;
}
c1 = Sum(2, 3);
c2 = Sum(c1, 10);
c3 = Sum(c1, c2);
То есть, функция Sum принимает не только заданные при написании константы, но и изменяющиеся во время работы переменные.
AQ29 писал(а): Вс авг 09, 2026 13:34:53
Кстати, в СИ есть видимость макросов?
Есть. Но как я уже говорил, макросы в современных языках считаются устаревшим делом и не рекомендуются для новых разработок. Чтобы вы там ни говорили, как бы вы там не убеждали, но такова реальность. Макросы уже давно стали пережитком прошлого и в современной продвинутой практике фактически не применяются.
Остались только динозавры типа вас, которые так и не смогли идти не то чтобы в ногу со временем, но хотябы не слишком отставать.
AQ29 писал(а): Вс авг 09, 2026 13:34:53
придётся писать комментарии, хоть и есть слово set, но это будет гашение.
Вы просто не знакомы с современными языками, поэтому даже и не представляете, с помощью чего это реализуется
"Видишь суслика? - Нет. - А он есть!"
RedLed::On(); GreenLed::Off(); PowerLed::Toggle(); и при этом без разницы, как подключен светодиод, ибо при его описании можно задать, инвертируется выход или нет. using RedLed = Pin<GpioA::Pin3, Polarity::Invert>; using GreenLed = Pin<GpioD::Pin14, Polarity::Normal>
AQ29 писал(а): Вс авг 09, 2026 13:34:53
В ассемблере при небольшой правке тоже можно получить скрытые ошибки, но вероятность гораздо меньше.
Скорее, наоборот. В ассемблере, в силу его привязанности к железу, даже небольшие правки могут иметь большую вероятность повреждения работы кода.
А в языке Си компилятор сам всё устаканит на уровне размещения кода и используемых инструкций. Поэтому, вносить правки на Си гораздо легче, чем на ассемблере. Это давно известный факт, подтвержденный многими годами работы многих программистов.
AQ29 писал(а): Вс авг 09, 2026 13:34:53
Плохо представляю, как в СИ проверяют программу после правок. ... тестировали полгода, и что, после небольших правок опять тестировать полгода
По полгода никто не тестирует. Полгода рынок ждать не будет. Все куда проще. Если в проге есть ошибка, она проявит себя сразу же, а не через полгода. Нужно просто знать, как правильно тестировать.
При правильном тестировании не надо ждать, когда какая-то ошибка проявит себя при случайном стечении обстоятельств. Нужно как раз при тесте и вызвать все возможные обстоятельства.
Для этого, безотносительно языка программирования, пишутся так называемые unit-тесты. Это концепция проверки на правильность функционирования, на соответствие результата выполнения юнита ожидаемому от него результату. А так же на "поломатость" некоторой единицы программы (юнита, модуля) после внесения изменений.
На примере гипотетического юнита, возвращающего сумму двух 16-битных чисел со знаком: проверяют, что во всем диапазоне входных чисел возвращается то, что ожидается. То есть, проверяется поведение на специфических, характерных условиях: 2 + 3 = 5, -2 + 3 = 1, 2 + (-3) = -1, 0 + 0 = 0, 32000 + 1000 = 32767 (сложение с насыщением по 16-битному знаковому), и то же в отрицательную сторону.
Таким образом проверяется, что сложение положительных и отрицательных чисел работает верно, а так же при переполнении разрядной сетки возвращается максимально возможное в этой разрядности число.
А для проверки внесенных в готовый юнит изменений есть регрессионные тесты - проверка на деградацию (поломку) кода. Новая версия сравнивается со старой и обнаруживается расхождение поведения.
Для проведения этих проверок есть специальные утилиты генерации и запуска тестов, поэтому проверки на деградацию выполняются автоматически. С конкретным языком программирования юнит-тесты не связаны. Юнит-тестирование - это часть работы. И после внесения изменений запускаются ранее написанные юнит-тесты, они сразу же покажут поломку, если таковая имеется.
AQ29 писал(а): Вс авг 09, 2026 13:34:53
Для ускорения скопировал макрос, вставил нужные строчки, изменил название – это
...это крайне вредный принцип работы. Копипасты - вредны в программировании. Если вам что-то приходится копипастить, значит, вы неверно организовали работу. Почему? А потому что если потом вам пришлось отредактировать (добавить, убавить, улучшить) один фрагмент, то эти изменения придется вручную так же копипастить и во все остальные места, куда было раньше скопипащено. Постоянные правки в разных местах одного и того же сильно замедляют работу и вносят потенциальные ошибки.
Именно из-за таких копипаст ваше тестирование затягивается на полгода. Вместо того, чтобы оттестировать один юнит в одном месте, вам приходится тестировать каждое скопированное вхождение этого юнита во всех местах.
Из-за неверной концепции вы сами себе усложнили задачу.
Поэтому еще раз повторю - копипасты - зло и вред!
