- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
#ifndef SAFE_RELEASE
#define SAFE_RELEASE(x) \
if(x != NULL) \
{ \
x->Release(); \
x = NULL; \
}
#endif
#define SAFE_DELETE(a) if( (a) != NULL ) delete (a); (a) = NULL;
#ifndef SAFE_ARRAY_DELETE
#define SAFE_ARRAY_DELETE(x) \
if(x != NULL) \
{ \
delete[] x; \
x = NULL; \
}
#endif
#define SAFE_FREE( p ) if( p ) { free( p ) ; p=NULL ; }
Я вот все никак не могу забыть старый код из доков макрософт по COM, а также из книги Андре Ла Мота.
Два макроса до сих пор висят среди доков на сайте мс (по коду догадаетесь какие):
http://msdn.microsoft.com/ru-RU/library/windows/desktop/dd743946(v=vs.85).aspx
guest 01.06.2013 09:54 # +6
http://msdn.microsoft.com/en-us/library/windows/desktop/dd940435(v=vs.85).aspx
tirinox 01.06.2013 13:03 # +1
bormand 01.06.2013 14:50 # +1
Лучше. Она хотя бы не так забагована, как макросы, перечисленные выше ;)
Soul_re@ver 01.06.2013 16:50 # 0
guest 01.06.2013 22:23 # 0
Elvenfighter 02.06.2013 04:42 # +2
LispGovno 02.06.2013 06:36 # +2
bormand 02.06.2013 07:04 # +2
bormand 02.06.2013 07:12 # +1
bormand 02.06.2013 07:18 # +1
LispGovno 02.06.2013 07:27 # 0
да, также как и в T * operator = (T *p) {
bormand 02.06.2013 07:33 # 0
guest 22.06.2013 11:39 # 0
LispGovno 02.06.2013 07:24 # 0
поддержки const корректности не хватает
T * operator = (T *p) { не безопасен с точки зрения исключений и не хваает такого же оператора, только копирования
bormand 02.06.2013 07:35 # 0
> поддержки const корректности
Логично
> не безопасен с точки зрения исключений
Зачем AddRef и Release будут кидать исключения? Они ведь даже не крестоблядские...
bormand 02.06.2013 07:39 # +2
LispGovno 02.06.2013 07:49 # +1
bormand 02.06.2013 08:23 # +3
Моя DLL, че хочу то и делаю. Соглашения о вызовах и исключениях не зафиксированы, поэтому я всегда могу написать свои и следовать им.
А вот COM это не та вещь, в которой допустимы вольности. Не нравятся правила COM'а - мути свою аналогичную технологию, но не создавай людям батхерты, называя это COM'ом.
К тому же "Exceptions aren't allowed to flow across a COM interface boundary. Because there is no binary contract for C++ exceptions, COM cannot marshal them from one thread to another.". Т.е. с COM объектом из соседнего процесса так уже не поработаешь.
P.S. Исключение в Release равносильно исключению в деструкторе.
LispGovno 02.06.2013 09:12 # 0
an0nym 02.06.2013 16:39 # 0
bormand 02.06.2013 17:20 # +1
AddRef увеличивает счетчик использований на 1.
Release уменьшает, и удаляет объект, если счетчик достиг нуля.
QueryInterface позволяет получить другой интерфейс по его GUID'у.
guest 07.06.2013 12:18 # +3
http://msdn.microsoft.com/en-us/library/windows/desktop/bb761722(v=vs.85).aspx
roman-kashitsyn 01.06.2013 10:21 # +4
guest 01.06.2013 10:26 # +1
bormand 01.06.2013 11:25 # +1
fxd
guest 01.06.2013 10:37 # 0
bormand 01.06.2013 11:21 # +3
Основы макроёбства - не жалеть скобок в выражениях и do { ... } while (0) в стейтментах, чтобы потом об этом не жалеть ;)
guest 01.06.2013 11:29 # 0
roman-kashitsyn 01.06.2013 11:35 # +2
bormand 01.06.2013 11:37 # +2
Сравни и Второе, естественно, смотрится привычней и интуитивней.
guest 01.06.2013 13:17 # 0
Лучше так:
bormand 01.06.2013 14:54 # +2
Нет, не лучше. Этот вариант забагуется на примере Романа, равно как и просто { ... }. Конструкцию с if(0){}else{...} юзают не в таком случае, а когда макросом пытаются эмулировать какой-нибудь foreach или особый if.
Емнип других способов замутить макрос, ведущий себя как вызов void функции кроме do { ... } while(0) и нет.
guest 01.06.2013 15:08 # 0
Пример использования if(0){}else для foreach и\или if ? if(0){}else - если это не работает, то зачем так делают?
bormand 01.06.2013 17:26 # +1
Оно работает, но семантика получается как у любой другой управляющей конструкции - if/for/while и т.п. Вот для эмуляции новых подобных конструкций оно юзабельно. Для эмуляции void функций - нет.
> Пример использования if(0){}else для foreach
В Qt'шной реализации foreach'а for завернут в if(0){}else чтобы переменные, описанные в for'е не вылезали наружу из-за ебанутого скопинга в msvc6. Если интересно, а искать исходники кютихи влом - могу выложить сюда этот кусочек.
guest 01.06.2013 22:26 # +1
Не, спасибо. Я видел. Тот щё гонокод. Хуже только BOOST_FOREACH
inkanus-gray 01.06.2013 19:36 # 0
А вообще же тот, кто уже обжёгся, ставит фигурные скобки при каждом удобном случае, даже вокруг единственного оператора: Разве так не надёжнее?
roman-kashitsyn 01.06.2013 20:13 # +3
bormand 01.06.2013 21:12 # +1
А я ставлю их в нетривиальных случаях - более одного уровня вложенности. Примерно так:
krypt 03.06.2013 23:15 # +2
А я потом понять не мог, почему у меня память течь начала, да и ещё в промышленных масштабах, по 3 мб на одну отрисовку
bormand 01.06.2013 21:10 # +2
Скобки то само-собой надежнее. Но согласитесь: лучше написать макрос (а лучше вообще не писать их лишний раз без причины ;) так, чтобы он адекватно работал во всех контекстах, чем объяснять в документации как именно нужно его юзать, и надеяться, что ее будут читать...
> А вообще же тот, кто уже обжёгся, ставит фигурные скобки при каждом удобном случае
Обжегшись на молоке дуют на воду... Проблема то в том, что макрос через жопу написан. А пофиксить пытаются последствия.
guest 22.06.2013 11:56 # 0
bormand 01.06.2013 11:19 # 0
P.S. Кстати макросы написаны неправильно, нужно больше do { ... } while(0).
roman-kashitsyn 01.06.2013 11:30 # +5
bormand 01.06.2013 11:42 # 0
Ужоснах какой-то. В чем смысл такой функции? Оптимизация путем устранения лишней проверки? Так один хер все в страхе будут проверять, и проверка вернется, правда вместо одного места она будет размазана по всему коду ровным слоем...
roman-kashitsyn 01.06.2013 11:46 # +2
3.14159265 01.06.2013 16:58 # +2
Это фича!
guest 01.06.2013 22:29 # +7
guest 22.06.2013 10:37 # 0