Зачем использовать макрос в объявлении класса
Я читаю исходный код leveldb, esp. по поводу мьютекса.
Я нашел эту декларацию:
class SCOPED_LOCKABLE MutexLock {
public:
explicit MutexLock(port::Mutex *mu) EXCLUSIVE_LOCK_FUNCTION(mu)
: mu_(mu) {
this->mu_->Lock();
}
~MutexLock() UNLOCK_FUNCTION() { this->mu_->Unlock(); }
private:
port::Mutex *const mu_;
// No copying allowed
MutexLock(const MutexLock&);
void operator=(const MutexLock&);
};
и я обнаружил, что SCOPED_LOCKABLE определяется как пустой, так зачем использовать его в объявлении класса?
Решение
В определениях классов или функций, если разработчику необходимо добавить дополнительную характеристику, он использует MACROS, а не жесткое кодирование в каждом определении класса или функции. Это хорошая практика для программирования. потому что однажды, если вам нужно изменить эту характеристику, вы должны изменить только в одном месте, а не везде код.
Некоторое использование макросов в определении класса
#ifdef CONTROLLER_EXPORTS
#define CONTROLLER_API __declspec(dllexport)
#else
#define CONTROLLER_API __declspec(dllimport)
#endif
class CONTROLLER_API CConfiguration{
} ;
Вы можете получить еще несколько полезных подсказок, связанных с окнами, здесь. http://msdn.microsoft.com/en-us/library/dabb5z75(v=vs.80).aspx
Даже вы можете использовать модификаторы доступа, как это, потому что некоторое время для тестирования вам может понадобиться временно изменить уровень доступа.
#define PRIVATE private
#define PUBLIC public
class A{
PRIVATE:
int m_a;
PUBLIC:
int m_b;
}
Тогда в чем именно твоя проблема? это может быть любая полезная характеристика, определенная как выше. вот один пример, который я получил от мерзавца
#define SCOPED_LOCKABLE __attribute__ ((scoped_lockable))
Другие решения
Это может быть определено как что-то другое в другой среде. Иногда это может повлиять на связь.
Это также может указывать на то, что для правильной настройки заголовков библиотеки необходимо включить другие заголовки.