Как я и сказал выше - всегда нужно чем-то жертвовать при «универсализации»…
Нормальный механизм для таких дел в ООП - наследование.
Определяем базовый класс безо всяких флагов. Для этого в файле shButton.h:
- Удаляем оба
#if ... #endif - Заменяем слово
privateна словоprotected
Затем, в том же файле, ниже уже определённого класса, определяем новый, который наследуется от уже определённого и реализует всё, связанное с флагами:
Код
class shButtonFlag : public shButton {
protected:
uint8_t btn_flag = 0;
public:
// Конструкторы явно наследуем
shButtonFlag(void) : shButton() {}
shButtonFlag(uint8_t pin, uint8_t inputtype = PULL_UP, uint8_t btntype = BTN_NO) : shButton(pin,inputtype,btntype) {}
/**
* @brief считать флаг кнопки
*
* @param _clear если true - после считывания установить флаг в 0
* @return uint8_t
*/
uint8_t getButtonFlag(bool _clear = false)
{
uint8_t result = btn_flag;
if (_clear)
{
btn_flag = 0;
}
return (result);
}
/**
* @brief установить флаг кнопки
*
* @param _flag устанавливаемое значение
*/
void setButtonFlag(uint8_t _flag)
{
btn_flag = _flag;
}
};
Собсна, всё. теперь, если нам нужен вариант с флагами, в .ino пишем
shButtonFlag btn(BTN_PIN);
а если нужен вариант без флагов, то
shButton btn(BTN_PIN);
Всё работает и никаких проблем не возникает.
Блин… Ну это ж слишком просто )))
Нет, для себя я так и делаю, даже с той же кнопкой практически в каждом проекте наследую и добавляю нужное. Собственно, идея добавить флаг в кнопку потому и появилась, что последнее время почти везде их использую.
А тут выложенная в открытый доступ библиотека - усложнять двумя классами вроде как-то не слишком гуманно ))
А в той же “часовой” библиотеке флагов наберется с десяток, как не больше, да в разных сочетаниях. Тут никаким наследованием не отделаешься…
Вот бы в конструкторе можно было методы новые определять и тп ))))
Зачем? Можете привести пример, как бы это помогло?
я видел библиотеки с 5-7 уровнями наследования
используйте template
Нафиг, нафиг ))