+5
- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
#include <iostream>
using namespace std;
void f(void){cout<<"f"<<endl;}
void f1(void){cout<<"f1"<<endl;}
bool secondIfIsTryed(){cout<<"secondIfIsTryed"<<endl;return true;}
#define asserts(Condition) {cout<<"Assert"<<endl;}
int main() {
if(true)
if(secondIfIsTryed() && false)
f();
else
f1();
if(true)
if(secondIfIsTryed() && false)
asserts(true)
else
f1();
return 0;
}
Помните того вечно сомневающегося знакомого, тест крестов, написанный которым я недавно приводил?
http://ideone.com/9Q61D1
В этот раз под его глуповатый, но пытливый взгляд попал макрос ассерта. Написан он конечно не так, как в этом тесте, но имеет код вида:
#define asserts(Condition) {/*...*/}
В итоге он сделал умозаключение: "Вокруг меня собрались голубцы" и надулся.
Запостил: 
LispGovno,
19 Июля 2013
Follow us!
начнет принадлежать внешнему ифу из-за этого ассерта. Ассерт самописный в проекте.
https://ideone.com/y52PvT
1) Не пиши макросы.
2) Если все-таки написал макрос - пиши его имя капсом.
3) Аргументы макроса оборачиваются в скобки.
4) Тело function-like макро оборачивается в скобки.
5) Тело statement-like макроса оборачивается в do { ... } while (0).
6) По возможности аргументы макро используются ровно 1 раз.
Вроде ничего не забыл. Нарушение любой из этих заповедей почти всегда приводит к грустным последствиям.
2) Если все-таки написал макрос - сотри.
2) Если не согласен см. п. 1
У меня в проекте есть statement-like макро, не обернтый в do { ... } while (0). Использовался сотни раз. Обернуть его в do { ... } while (0) теперь боюсь, так как боюсь что-нибудь сломать
Предлагаю для начала посмотреть много ли раз он юзается, и в каких контекстах. А там уже видно будет - рефакторить или не рефакторить.