Вопросы по С/С++ (СИ)

[Аlex]

[uquote="a5021",url="/forum/viewtopic.php?p=3483497#p3483497"]Оная вложенность заслуженно считается плохим тоном.[/uquote]Кем, Вами считается ?
По мне, так то, что Вы написали, считается дурным тоном. Кровь из глаз пойдёт у читателя этого кода

[Мурик]

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

Если компилятор не соответствует стандарту и ведет себя не предсказуемо - втопку его.
Я использовал GCC в коде выше. Он для МК достаточно агрессивно оптимизирует, но ведет себя предсказуемо и если "сказать Фу", на код не кидается и не "выгрызает" его.

[a5021]

[uquote="Аlex",url="/forum/viewtopic.php?p=3483562#p3483562"]Кем, Вами считается ? [/uquote]
Советую учебничек полистать какой-нибудь. Там обычно пишут что-то вроде: "Deeply nested conditionals make it just about impossible to tell what code will run, or when." Возьметесь оспаривать?

По мне, так то, что Вы написали, считается дурным тоном.

Обоснуете?

Кровь из глаз пойдёт у читателя этого кода

Сильно уж читателе-зависимый критерий. У иных кровь захлещет от любого мало-мальски профессионального представления.

[Аlex]

Возьметесь оспаривать?

Нет конечно. Ибо - лень

Обоснуете?

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

[a5021]

[uquote="Аlex",url="/forum/viewtopic.php?p=3483597#p3483597"]Написание любого плохочитаемого кода априори является дурным тоном.[/uquote]
Согласен. Хуже может быть только голимый субъективизм и бездоказательность в утверждениях.

PS. Еще одна забавная штука попалась на глаза: код, который нарушает все правила, но тем не менее работает. Это GCC 5.4.1. x86, где новомодных замыканий просто не может быть в принципе, но они там таки есть.

[ARV]

Еще одна забавная штука попалась на глаза: код, который нарушает все правила, но тем не менее работает.

пишите так, и люди будут плевать вам вслед.

Добавлено after 3 minutes 33 seconds:

но тем не менее работает. Это GCC 5.4.1

тем не менее, не работает: https://ideone.com/557ULM GCC 6.3
писать компиляторо-зависимый код, т.е. код, эксплуатирующий багофичи отдельных версий компилятора - разве можно придумать что-то более ужасное?

[viiv]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3483490#p3483490"]Господа, программируйте как хотите, но тут заложена потенциальная проблема. Умеете обходить, хорошо, но вспомните сколько тем "не заходит в ветку под отладкой" и им подобных от нубов. Лучше такое не пропагандировать.[/uquote]

Никакой проблемы нет. Не выдумывайте.
Как должен вести компилятор при

Код: Выделить всё

  if (reset() && (delay(100), 1) && init() && (delay(100), 1) && run_cmd(MOVE_FORWARD)) {
        // do smth
  }

четко определено. Нет никаких неоднозначностей. И совершенно не важно возвращает ли delay () значение или не возвращает. Если в этом случае компилатор "викинет" delay (), то руки надо отрывать автору delay (), данная конструкция здесь вообще не при чем.

ЗЫ. Я противник подобных конструкций лишь потому, что при просмотре кода приходится задерживаться на этих строках больше чем они заслуживают - не всегда с перврго раза понятно, зачем автор так извратился. Хотел от вложенных if-ов уйти? Так есть return Ж-)

Код: Выделить всё

if (! reset())
    return;
delay(100);
if (! init())
    return;
delay(100);
if (! run_cmd(MOVE_FORWARD))
    return;

// do smth

[a5021]

[uquote="ARV",url="/forum/viewtopic.php?p=3483758#p3483758"]пишите так, и люди будут плевать вам вслед.[/uquote]
Плохо вам. Вы не улавливаете курьезности ситуации.

код, эксплуатирующий багофичи отдельных версий компилятора - разве можно придумать что-то более ужасное?

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

[ARV]

Плохо вам.

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

[Мурик]

тем не менее, не работает: https://ideone.com/557ULM GCC 6.3
писать компиляторо-зависимый код, т.е. код, эксплуатирующий багофичи отдельных версий компилятора - разве можно придумать что-то более ужасное?

Проверил на STMке с GCC 5.4 и GCC 7. Работает нормально. Результат соответствует.

[a5021]

[uquote="ARV",url="/forum/viewtopic.php?p=3483948#p3483948"]я никогда сам так не делаю[/uquote]
Да не убивайтесь вы так. Курьез был опубликован для тех, кто понимает.

[uquote="viiv",url="/forum/viewtopic.php?p=3483832#p3483832"]Я противник подобных конструкций лишь потому,[/uquote]
Лишь потому, что не привыкли. Не собираетесь же вы скобки, которые часто используют для улучшения читабельности, обвинять в том, что читабельность они ухудшают, как это сделал один из ваших предшественников?

[viiv]

[uquote="a5021",url="/forum/viewtopic.php?p=3483993#p3483993"]Лишь потому, что не привыкли.[/uquote]
Хм. Как раз привык! И вполне нормально отношусь к такому в чужом коде. Если встречу, и не увижу ошибки, править такие тексты у меня даже мысли не возникнет, разве что добавть комментарий, что эта часть кода с "хитростью" работает правильно, так и задумывалось. Но,
1) как правило, мне не известна квалификация того, кто писал код, который я просматриваю. И к "хитростям" в коде отношусь осторожно. Бывает (и довольно часто), что "хитрости" применяют не до конца понимая, что они делают.
2) Надо "облегчать жизнь" читателям кода всеми доступными способами. Чем проще и "читабельнее" код, чем меньше в нем "хитростей", тем лучше.

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

[uquote="a5021",url="/forum/viewtopic.php?p=3483993#p3483993"]Не собираетесь же вы скобки, которые часто используют для улучшения читабельности, обвинять в том, что читабельность они ухудшают, как это сделал один из ваших предшественников?[/uquote]
Не, не собираюсь. Я приветствую все, что используются для улучшения читабельности!!!

[a5021]

[uquote="Мурик",url="/forum/viewtopic.php?p=3483965#p3483965"]]Проверил на STMке с GCC 5.4 и GCC 7. Работает нормально. Результат соответствует.[/uquote]
Только не очень понятно, как такое пролезло из C++ в C. Вложенных функций ведь нет в Си, насколько я в курсе, уж не говоря про "замыкательный" способ использования.

[ARV]

Вложенных функций ведь нет в Си, насколько я в курсе, уж не говоря про "замыкательный" способ использования.

что такое замыкательный способ использования, я не в курсе, но вложенные функции есть в расширениях GCC для Си.

[a5021]

[uquote="ARV",url="/forum/viewtopic.php?p=3484130#p3484130"]что такое замыкательный способ использования,[/uquote]
Почитайте про замыкания в си ++. Часть волнительных переживаний, что вы озвучивали ранее, глядишь и утихнет.

я не в курсе, но вложенные функции есть в расширениях GCC для Си.

Я, например, не знал. Но тогда ваши стенания с заламыванием рук вообще смотрятся, как никудышная актерская работа: "If you try to call it after a containing scope level exits, and if it refers to some of the variables that are no longer in scope, you may be lucky, but it’s not wise to take the risk. If, however, the nested function does not refer to anything that has gone out of scope, you should be safe."

Мануал на GCC говорит, что вызывать вложенные функции снаружи может быть безопасно. Имеется, что возразить мануалу?

[ARV]

Почитайте про замыкания в си ++

упаси бог, оно мне надо?!

Имеется, что возразить мануалу?

имеется.
1. я так никогда сам не делаю и другим не советую - см. ранее.
2. вложенные функции не должны быть видны за пределами {} "охватывающей функции", поэтому я сильно удивлен, каким образом происходит взятие их адресов в main... запутало одинаковое наименование вложенных функций и указателей. это меня лишний раз убедило, что так делается исключительно ради того, чтобы поставить на место зарвавшихся самоучек (см. ранее) - только гуру в этом не ошибется.

[a5021]

[uquote="ARV",url="/forum/viewtopic.php?p=3484144#p3484144"]упаси бог, оно мне надо?![/uquote]
Выходит, устраивать переполох без повода вам зачем-то надо.

1. я так никогда сам не делаю и другим не советую - см. ранее.

Все та же эгоцентричная модель мира. Вы в жизни никогда и не ошибались, наверное?

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

Собственные промахи вам приятнее объяснять коварством извне? Немного странно, конечно, но вполне объяснимо.

[isx]

Вечер добрый!
Хочу добавить универсальности своему коду на СИ, но никак не соображу как это сделать)
Есть строки, которые атомарно переключают пины микроконтроллера STM32F103, при этом если пин меньше 8, то нужно писать:

Код: Выделить всё

GPIOA->CRL = GPIO_BSSR_BSx

а если больше, то:

Код: Выделить всё

GPIOA->CRH = GPIO_BSSR_BSx

Можно ли как-то сделать макроопределение, чтоб оно определяло по номеру вывода какой регистр нужно использовать CRL или CRH?
Интересует именно макроопределение, так как после компиляции должна получиться простая строка типа:

Код: Выделить всё

GPIOA->CRL = GPIO_BSSR_BS1

иначе об атомарности можно забыть.

Как я это представляю:

Код: Выделить всё

#define GPIO_PIN_SET(PORT, PIN) // а тут должно быть условие типа if(PIN<8){тут что-то типа такого: GPIO##PORT->CRL= GPIO_BSSR_BS##PIN} else {тут что-то типа такого: GPIO##PORT->CRH= GPIO_BSSR_BS##PIN}

Главное, чтоб в коде строка

Код: Выделить всё

GPIO_PIN_SET(A, 9);

была преобразована компилятором в строку

Код: Выделить всё

GPIOA->CRH= GPIO_BSSR_BS9;

[WiseLord]

Запись в BSR и BSRR атомарна в любом случае, неважно, есть ли до этого какие-то проверки на номер пина или нет.

[isx]

Мне нужно чтоб при выполнении кода не было никаких лишних действий - чисто запись регистра и все!

Кстати, а вот такая портянка имеет право на существование? Компилятор вроде не ругается...

Код: Выделить всё

#define ISX_GPIO_PIN_SET (PORT, PIN)  #if PIN<8 GPIO##PORT->CRL = ISX_GPIO_BS##PIN #else GPIO##PORT->CRH = ISX_GPIO_BS##PIN