ViKo 1 28 сентября, 2013 Опубликовано 28 сентября, 2013 · Жалоба Такой результат получится с любым исправным компилятором. Если есть под рукой GCC - посмотрите результат препроцессора. У меня под рукой нет. Поэтому сделаем препроцессинг вручную. if (0) if (1) ; { printf("Good style saves you\n"); }; Насчет GCC не скажу, но в Keil C-99 точка с запятой не отрывается от имени макрофункции. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 28 сентября, 2013 Опубликовано 28 сентября, 2013 · Жалоба Ruslan1, выше был пример. Но я повторю его, так как выше смешал два случая: #define aaa() { printf("XXX\n"); } if (1) aaa(); else printf("Yo are so wrong\n"); просто не скомпилируется. Это не интересно. Я спросил пример кода, где определенный так макрос будет работать некорректно. То есть когда оно работает, но некорректно. То есть компилятор молча пережевал и сгенерировал код, но код работает не так как задумывал программист. Варианты, которые детектируются любым компилятором как варнинги или ошибки не интересны, так как очевидно, что любой даже варнинг требует внимания программиста и документирования как допустимый или модификации кода для его устранения. Вот если Вы укажете компилятор, в котором приведенный Вами пример не сгенерирует варнинг или ошибку (и, само собой, работать будет некорректно)- я с Вами соглашусь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 13 28 сентября, 2013 Опубликовано 28 сентября, 2013 · Жалоба Это не интересно. Я спросил пример кода, где определенный так макрос будет работать некорректно. То есть когда оно работает, но некорректно. К чему такие придирки? Или если написано "чуть-чуть неправильно" - то так делать можно, а вот если "совсем неправильно" - уже нельзя? Очевидно, что простой блок в макросах способен вызвать проблемы, знать об этом и осознанно писать проблемные макросы - как минимум странно. С точки зрения повторного использования будет не важно, код не компилируется, или компилируется, но работает некорректно. Это влияет только на скорость выявления проблем. Все равно придется лезть в чужой (или в свой старый) макрос и его исправлять, или переписывать код так, чтобы после макроса не было точки с запятой. И зачем это нужно, если есть старый как сам C способ написания корректного кода? http://c-faq.com/cpp/multistmt.html О нем можно не знать, это нормально. Но знать и не использовать - в чем выгода? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
igorle 0 28 сентября, 2013 Опубликовано 28 сентября, 2013 · Жалоба Поддерживаю предыдущего оратора. И еще. "функции" без точки с запятой в конце, сбивают механизм автоматической индентации. Например, я сейчас напечатал в виме код, и он выровнял мне его так: if (1) aaa() bbb(); А это некрасиво. И это уже достаточный повод не делать этого. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 29 сентября, 2013 Опубликовано 29 сентября, 2013 · Жалоба Например, я сейчас напечатал в виме код, и он выровнял мне его так: Что такое "вим"? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 13 29 сентября, 2013 Опубликовано 29 сентября, 2013 · Жалоба Что такое "вим"? Адский текстовый редактор. (Самый?) мощный, но по-настоящему красноглазый. http://ru.wikipedia.org/wiki/Vim Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
A. Fig Lee 0 29 сентября, 2013 Опубликовано 29 сентября, 2013 · Жалоба А вывод один - обрамляйте любую макрофункцию, состоящую более чем из вызова одной функции, do {} while(0), и будет вам счастье. Не согласен. После if всегда надо пользовать фигурные скобки. Назвисимо от использования всяких define. Это улучшает читаемость и предсказуемость кода. Чем больше напихано в #define, тем сложнее их читать. То, что компилятор не скомпилирует не проблема. поправим. Проблема если скомпилирует не так как надо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 29 сентября, 2013 Опубликовано 29 сентября, 2013 · Жалоба После if всегда надо пользовать фигурные скобки. ... Это улучшает читаемость и предсказуемость кода. if(x) zzz(); По-моему, в подобном выражении фигурные скобки не улучшат читаемость. Скорее, наоборот. То, что компилятор не скомпилирует не проблема. поправим. Проблема если скомпилирует не так как надо. Если что-то надо править, то это все равно проблема. Она, конечно, меркнет на фоне второго варианта развития событий, но все же. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ig_z 0 29 сентября, 2013 Опубликовано 29 сентября, 2013 · Жалоба Не согласен. После if всегда надо пользовать фигурные скобки. Назвисимо от использования всяких define. Это улучшает читаемость и предсказуемость кода. Чем больше напихано в #define, тем сложнее их читать. То, что компилятор не скомпилирует не проблема. поправим. Проблема если скомпилирует не так как надо. Маладец! Герой! Аплодирую стоя, один прет против всех! Прям как макаревич в своих нетленках. Теперь нужно срочно наставить на путь истинный девелоперов линукс ядра, lwip, contiki и т.д. Залезть в их репозитории и поубивать ненавистные дувайлы :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться