- 1
- 2
- 3
- 4
- 5
- 6
UINT aScrollMode = 0;
m_pScrollH->GetInfo(&aScrollMode, 0, 0);
if (!(aScrollMode & M_INVISIBLE))
{
...
}
Кресты / Говнокод #2022
0
Рефакторю довольно большой проект (5 Мб исходников). Единственный способ спросить у контрола (любого из имеющихся) привожу выше.
Запостил: 
Konstantin.Grebenschikov,
(Updated )
Делаем динамик каст контрола к классу содержащему эту функцию и возвращаем результат проверки.
Это еще очень хороший код, я успешно разгребал более худшие.
Отличие битовых полей от структуры - увеличение сложности и, вероятно, оптимальности кода в плане быстродействия в пользу оптимальности в плане используемой памяти. Причем жестко зашитое в код.
Отличие структуры от объекта - наличие контролируемого поведения.
Использование битовых полей вместо объектов - сумма вышеперечисленного.
Если только ты имеешь в виду наличие большого количества полей (десятки-сотни). Тут я согласен.
Практически любое битовое поле легко преобразуется в структуру. Парадокс в том, что в ООП структуры встречаются крайне редко. Как только однородные данные оказываются сосредоточенными в одном месте (info контрола в данном примере), становится видно, что их удобно наделить поведением. Хотя бы проверкой согласованности внутреннего состояния.
например, сравните с тем, что было наверху:
if ( m_pScrollH->GetInfo().Visible() )
{
...
}
Проще?
Единственный случай, когда мне приходилось применять битовые поля, и это было оправданным, подготовка структуры данных для пересылки другому устройству.
Покрайней мере VS 2008 это сделает хуже меня, даже без прибегания к ассемблеру(применением логических операций) Измерял.
struct bbb
{
void (*f)(void);
};
int main()
{
struct bbb s, *pd;
s.f=f;
pd=&s;
pd->f();
}
Чистый С.