int t:1 -- Что это?

[Артем]

Добрый день.

Вот встретилось следующее:

Код:

class MyClass
{
  public:
     void SomeFun();
  
  public:
   int flag :1;
 }

Что значит строчка:

Код:

int flag :1;

Битовое поле?
Зачем так определять? Есть ли выигрыш по сравнению с просто

Код:

int flag;

Или это НЕ битовое поле?

[Tuborg]

да это битовое поле. Выигрыш или проигрыш по скорости - зависит от компилятора, но в общем случае это проигрыш. Битовыми полями пользуюсь только если надо прочесть какую то структуру из файла/памяти... чтобы отдельно каждый элемент структуры не заполнять значениями проще просто грузить в структуру определённую битовыми полями

[Vlaor]

Может писалось по шаблону, и приплыло
Или как резерв на будущее.

[Sla]

Ребятки, вы просто "никогда" не работали с битовыми процессорами (читай битовыми командами)
ну, нет в х86 битовых команд (флаги я исключаю).
а, например в х51 такого добра - милости прошу. И компилятор прекрасно понимает, что надо работать с битом.
например, делаешь глобальный цикл, но в каждом втором нужно что-то сделать еще...
или проанализировать только один пин.

Выигрыш на х86 - только в понимании логики программы.
Но! конечно назвать флаг флагом мало, а че в облом было написать флаг_переполнения_сумматора
тогда бы, наверное,  и все вопросы отпали

[Антон (LogRus)]

У нас на работе используют штуку структурках флагов
struct bin_flags
{
 int eof:1;
 int good:1;
}
затем это дело засовываем в
union state
{
 bit_flags bflags;
 int flags;
}

собственно зачем?
затем что в один int засовываем до 32-х флагов
типа место экономим
а в юнион пихаем что бы структурку было проще копировать
и размер POD структуры менятся не будет до тех пор пока все биты в int не выберем

кстати лучше заменить int i:1; на unsigned int i:1;
в первом случае у тебя в i могут быть только 0 и -1 во втором 0 и 1
сам исправлял баги когда флаг int i:1; сравнивали с 1 и нефига не работало.

[Алексей++]

LogRus,

а я сразу так делаю ) :

union state
{
  struct
  {
    int eof:1;
    int good:1;
  }
  int flags;
}

[Артем]

 Спасибо всем за ответы.

Я тоже считал что использовани битовых поле необходимо либо для экономии места

один int засовываем до 32-х флагов

либо

если надо прочесть какую то структуру из файла/памяти...

Но в данном примере под этот "flag" все равно выделится 4 байта, а времени может занять больше из-за обрашения как к битовому полю. ИМХО.

Просто это мне встретилось в "очень солидном" коде, вот я и смутился.

Еще раз спасибо, что развеяли мои сомнения 

[Артем]

Вопрос из той же серии:

Код:

int fun (int* a)
{
  (void) a;
  int b = (*a);
  return b;
}

Что за мегасмысл скрыт в строчке "(void) a;" ?

[Антон (LogRus)]

LogRus,

а я сразу так делаю ) :

union state
{
  struct
  {
    int eof:1;
    int good:1;
  }
  int flags;
}

Вспонил, в чем проблема в твоём коде, его нельзя было нормально использовать в gcc.

Артем, я смысла не вижу.

[Джон]

Я тоже не вижу смысла. Даже если это работает - в а лежит мусор. А потом этот мусор используется в качестве адреса. Может запрограммированная ошибка доступа? Ну мало ли? Может кому захотелось пользователей подоставать? При определённых действиях.

[Артем]

Даже если это работает - в а лежит мусор.

ПОЧЕМУ  Разве в а не лежит, то что положили при вызове функции?

например:

Код:

main()
{
  int test = 10;
  int b; 
  b = fun (&test);

}

разве b не равно 10

[Джон]

Аааа сори. Каюсь. Я не обратил внимание, что а ещё и передаётся в качестве параметра. Видел только тело ф-ции. Я думал рамки ф-ции так, для полноты примера. А так это просто вызов оператора кастинга в void.

Ну тогда всё в порядке. Земля снова круглая.

Предположение - откуда такие вещи берутся. Это атавизмы кода. Недавно у себя на нечто подобное напоролся. Проследил всю историю. Короче ф-я абсолютно абсурдная в одном месте вызывалась. Надо было просто апдейтнуть корешки Таба - текст. И вдруг откуда не возьмись ещё ф-я установки цвета этих корешков. Так что при апдейте они ещё вдруг и цвет меняют. Причём файл не трогали несколько месяцев, потом вдруг в один день (два года назад) добавили в него эту ф-ю и потом снова не трогали. Те случайность исключена. Самым логичным представляется допущение, что с кодом просто экспериментировали и не всё удалили - обычно перед check-in мы проверяем только компиляспособность, а с этим было всё в порядке.

Так и тут. Кто-то что-то попробовал, компилиться ну и ладно.

[Артем]

Действительно похоже на

Это атавизмы кода.

Вот только слишком уж часто подобные строки встречаются, вот я и заволновался: вдруг чего не понимаю 

[Джон]

ну я думаю это зависит от того насколько интенсивно с этим кодом работали и как часто программера отвлекали во время работы. И потом, это было только моё предположение.