Так никто и не говорит, что битовые поля это неудобно. Удобно. Но там, где нужно максимально надёжный и портабельный код иметь (а проблем с ним — не иметь), лучше их не юзать вовсе. У нас в конторе мы их вообще запретили, из-за специфики. Самолёты прогаем, код должен на куче разных архитектур работать, с разной разрядностью и разным порядком байтов, причём вперемешку (а в протоколах ой как хочется, бывает, битовые поля заюзать). Но многолетнаяя практика показала, что это в итоге выливается в боль. А мы не хотим страдать, хотим новые крутые фичи пилить, а не внезапно всплывающие старые баги отлаживать )
>а вроде много лет смотрели разные люди этот код и никто не видел
Судя по описанию, просто не вчитывались, потому что код страшненький был, это обычное дело. А в приведённом мной случае — код простой и читаемый, от которого не ждёшь подвоха.
"Просто ошибка" — это когда можно просто посмотреть на код и увидеть, что там ошибка. А здесь — нельзя просто посмотреть на код и увидеть, что там ошибка. Можно столкнуться случайно, когда уже поздно (что и произошло).
Вот примерно так в поле структуры записывался код результата. Но внезапно оказывалось, что в поле result после этой записи — 0 (код для ERR_CODE_OK) вместо ожидаемого кода ошибки. Почему?
А потому что автор изначального кода отвёл на поле result всего один бит, описав его так:
typedef struct {
...
int32_t result: 1;
} DATA;
Кодов тогда было всего два, ноль и один, оно работало как задумывалось.
А потом в какой-то момент кто-то решил добавить других значений, и всё сломалось.
Компилятор ошибками не ругался (инт в инт пишется же, всё окей), и никто ничего не заметил.
И вот сидишь ты в отладке, смотришь на этот код, наводишь курсор на поле result, тебе IDE услужливо подсказывает: тип int32_t, всё окей! Шаг делаешь, туда восьмёрка пишется, а получается 0. Магия! )
Т.е. чтобы изначально врубиться, что в этой строке может быть косяк, нужно непременно полезть в описание структуры и вручную глазами смотреть, что за поле такое, и как объявлено. Отличная фича для стрельбы себе в ногу, в общем.
В детстве было неочевидно, что закончилось плохо, потому что серии по ТВ в неправильном порядке крутили; серия с разгромом базы совсем не последней оказывалась, как должна была. Я потом нагуглил, что это вроде даже оригинальный косяк — при премьерном показе их тоже в такой перепутанной последовательности показывали...
Лучший сериал ever. До глубин души поразил в своё время. Помню, как потом не раз и не два обдумывал эту философскую концепцию тотальной декомпозиции путём оцифровывания и последующего восстановления из цифровой копии. Наверное, это кино одна из важнейших причин, почему я в детстве заболел компьютерами и цифрой.
Кстати, может оно и хорошо, что дальше снимать не стали, читал я варианты дальнейшего развития сценария, есть подозрение, что вышла бы шляпа...
P.S. Как раз не так давно скачал и пересмотрел. Грустно, что того самого визуального эффекта от стробоскопических "мигалок", который был на ЭЛТ, с его интерлейсом в 50/60Гц, уже не получить. Все записи, что я сейчас нашёл, или деинтерлейснутые, или просто каждый второй кадр пропущен; мигалки не работают! Половина визуальной магии пропала :(
Ну так тем более. Хороший же пример. Гитаристу-одиночке под что играть, как не под машинку? У неё и пресеты есть, придумывать партию не нужно.
Кстати, у Кино вполне себе живой барабанщик был, но альбомы писали с машинкой. Потому что звучало модно, современно, синтетично. Нравилось им так. Так почему нет-то?
А зачем нужны живые барабанщики? Это же надо найти такого, кто умеет играть на барабанах, в ритм попадает, и т. п... Договариваться с ним... А потом всегда под рукой его иметь... А ещё барабанную установку найти хорошую, с подходящим звуком... А ещё обязательно найти того, кто эти живые барабаны хорошо запишет и сведёт (запись барабанов это самое сложное в живой записи). Зачем это всё, когда есть машинка, которая всё идеально сыграет, заранее идеально записанными сэмплами?
Человек, читающий вслух, тоже видит только и исключительно текст. Так что для подделки голоса и манеры говорить конкретного человека оно может (пока) и не сильно пригодно, но есть огромная сфера применений, где подделывать никого конкретного не нужно.
Типа того. Вернёт 1, если количество выставленных в слове битов нечётное, иначе 0.
Вообще, это один из известных алгоритмов (Compute parity in parallel), взятых с эпичной старинной странички с подборкой всякого такого разного прикольного: Bit Twiddling Hacks https://graphics.stanford.edu/~seander/bithacks.html
Там просто ерунда написана. Эта функция не число на чётность проверяет (тогда действительно младший бит посмотреть достаточно), а вычисляет бит чётности (который зависит от количества выставленных битов в слове). И, в отличие от заявленного, это часто бывает невероятно полезно )
Компилятор-то может имеет, но не каждый компилятор и не на каждой архитектуре. Это расширение, а не часть стандарта языка, так что есть случаи, когда использовать такое — не комильфо. А ещё бывает, что компилятор вроде и умеет в __builtin_parity, но реализовано оно медленнее, потому что готовой инструкции под это дело в целевом процессоре нет. Попробуйте в этом godbolt-сниппете выбрать, скажем, 32-х битную архитектуру PPC (power gcc 15.0.2). Там компилятор вообще сгенерит немаленький такой код, да ещё и вызывающий встроенную функцию (__paritysi2); это не будет быстро.
Да, там вопрос неудачный. Как-то совпало, что как раз недавно с ребёнком почему-то поговорили про амплитуду высот в майнкрафте. Так вот, после релиза там достаточно долго было 256, а начиная с версии 1.17 сделали 384. А поначалу в альфа-версии вроде вообще 64 было.
Ну вот, обещали на Си, а код — на плюсах, да с набором антипаттернов, типа макросов где ни попадя. И зачем писать #define mypoints std::vector<double>, когда специально для такого есть typedef или using?
Не так давно пересматривал "Чужого" и "Чужих", и обратил внимание, насколько в первом фильме более классно визуал подан. Детали окружения, рельеф, объёмный свет, просто обалденно смотрится, почти каждый кадр как произведение искусства. А в "Чужих" всё более простое, плоское, свет проще, косяки в спецэффектах заметнее. В детстве когда смотрел, не замечал этого, и второй фильм нравился больше. Из-за движухи, наверное. А сейчас вот, думаю, отдал бы свой голос первому.
Вот, например, ConPTY API — нормальный человеческий интерфейс для (псевдо)консоли — появился только в 10-й винде... Ну и много других штук появлялось периодически, которые либо делали какой-то ранее возможный процесс удобнее, однозначее и/или универсальнее, либо добавляли новые фичи. Это сильно заметно, если программы под WINAPI пишешь. Правда.
Никаких проблем со стенами нет. Газовики только если к объёму котельной и наличию/размеру окна/взрывного клапана придраться могут. А для тех, кто не хочет газовый котёл прямо в доме (я, например, не хотел бы) продаются готовые мини-котельные (утеплённый домик с котлом внутри), которые можно поставить рядом с домом, на улице.
Ну, в моём домике это как минимум бойлер на 50 литров (а ведь мог быть и на 100), а также кухонные шкафчики. И под то, и под то пришлось заранее просчитывать место для монтажа и делать закладные.
Тоже живу в самодельном каркаснике и достраиваю газобетонный. И с ходу только один минус у каркасника могу назвать — не получится в произвольном месте в стену засверлиться и что-то тяжёлое повесить, всё заранее надо просчитывать и закладные в стенах делать. Впрочем, и на газобетон что-то достаточно тяжёлое навесить может быть проблемно.
Так никто и не говорит, что битовые поля это неудобно. Удобно. Но там, где нужно максимально надёжный и портабельный код иметь (а проблем с ним — не иметь), лучше их не юзать вовсе. У нас в конторе мы их вообще запретили, из-за специфики. Самолёты прогаем, код должен на куче разных архитектур работать, с разной разрядностью и разным порядком байтов, причём вперемешку (а в протоколах ой как хочется, бывает, битовые поля заюзать). Но многолетнаяя практика показала, что это в итоге выливается в боль. А мы не хотим страдать, хотим новые крутые фичи пилить, а не внезапно всплывающие старые баги отлаживать )
>а вроде много лет смотрели разные люди этот код и никто не видел
Судя по описанию, просто не вчитывались, потому что код страшненький был, это обычное дело. А в приведённом мной случае — код простой и читаемый, от которого не ждёшь подвоха.
"Просто ошибка" — это когда можно просто посмотреть на код и увидеть, что там ошибка. А здесь — нельзя просто посмотреть на код и увидеть, что там ошибка. Можно столкнуться случайно, когда уже поздно (что и произошло).
>По поводу битовых полей не понимаю, зачем их избегать
Кроме BE/LE там достаточно своих приколов. Приведу пример из жизни.
Оказалось, что один проект несколько лет работал неверно, не сообщал об ошибке, когда надо было. Когда это обнаружили, не сразу поняли, в чём прикол.
Вот примерно так в поле структуры записывался код результата. Но внезапно оказывалось, что в поле result после этой записи — 0 (код для ERR_CODE_OK) вместо ожидаемого кода ошибки. Почему?
А потому что автор изначального кода отвёл на поле result всего один бит, описав его так:
Кодов тогда было всего два, ноль и один, оно работало как задумывалось.
А потом в какой-то момент кто-то решил добавить других значений, и всё сломалось.
Компилятор ошибками не ругался (инт в инт пишется же, всё окей), и никто ничего не заметил.
И вот сидишь ты в отладке, смотришь на этот код, наводишь курсор на поле result, тебе IDE услужливо подсказывает: тип int32_t, всё окей! Шаг делаешь, туда восьмёрка пишется, а получается 0. Магия! )
Т.е. чтобы изначально врубиться, что в этой строке может быть косяк, нужно непременно полезть в описание структуры и вручную глазами смотреть, что за поле такое, и как объявлено. Отличная фича для стрельбы себе в ногу, в общем.
В детстве было неочевидно, что закончилось плохо, потому что серии по ТВ в неправильном порядке крутили; серия с разгромом базы совсем не последней оказывалась, как должна была. Я потом нагуглил, что это вроде даже оригинальный косяк — при премьерном показе их тоже в такой перепутанной последовательности показывали...
Лучший сериал ever. До глубин души поразил в своё время. Помню, как потом не раз и не два обдумывал эту философскую концепцию тотальной декомпозиции путём оцифровывания и последующего восстановления из цифровой копии. Наверное, это кино одна из важнейших причин, почему я в детстве заболел компьютерами и цифрой.
Кстати, может оно и хорошо, что дальше снимать не стали, читал я варианты дальнейшего развития сценария, есть подозрение, что вышла бы шляпа...
P.S. Как раз не так давно скачал и пересмотрел. Грустно, что того самого визуального эффекта от стробоскопических "мигалок", который был на ЭЛТ, с его интерлейсом в 50/60Гц, уже не получить. Все записи, что я сейчас нашёл, или деинтерлейснутые, или просто каждый второй кадр пропущен; мигалки не работают! Половина визуальной магии пропала :(
Ну так тем более. Хороший же пример. Гитаристу-одиночке под что играть, как не под машинку? У неё и пресеты есть, придумывать партию не нужно.
Кстати, у Кино вполне себе живой барабанщик был, но альбомы писали с машинкой. Потому что звучало модно, современно, синтетично. Нравилось им так. Так почему нет-то?
А зачем нужны живые барабанщики? Это же надо найти такого, кто умеет играть на барабанах, в ритм попадает, и т. п... Договариваться с ним... А потом всегда под рукой его иметь... А ещё барабанную установку найти хорошую, с подходящим звуком... А ещё обязательно найти того, кто эти живые барабаны хорошо запишет и сведёт (запись барабанов это самое сложное в живой записи). Зачем это всё, когда есть машинка, которая всё идеально сыграет, заранее идеально записанными сэмплами?
del
Человек, читающий вслух, тоже видит только и исключительно текст. Так что для подделки голоса и манеры говорить конкретного человека оно может (пока) и не сильно пригодно, но есть огромная сфера применений, где подделывать никого конкретного не нужно.
Типа того. Вернёт 1, если количество выставленных в слове битов нечётное, иначе 0.
Вообще, это один из известных алгоритмов (Compute parity in parallel), взятых с эпичной старинной странички с подборкой всякого такого разного прикольного: Bit Twiddling Hacks https://graphics.stanford.edu/~seander/bithacks.html
Там просто ерунда написана. Эта функция не число на чётность проверяет (тогда действительно младший бит посмотреть достаточно), а вычисляет бит чётности (который зависит от количества выставленных битов в слове). И, в отличие от заявленного, это часто бывает невероятно полезно )
Компилятор-то может имеет, но не каждый компилятор и не на каждой архитектуре. Это расширение, а не часть стандарта языка, так что есть случаи, когда использовать такое — не комильфо. А ещё бывает, что компилятор вроде и умеет в __builtin_parity, но реализовано оно медленнее, потому что готовой инструкции под это дело в целевом процессоре нет. Попробуйте в этом godbolt-сниппете выбрать, скажем, 32-х битную архитектуру PPC (power gcc 15.0.2). Там компилятор вообще сгенерит немаленький такой код, да ещё и вызывающий встроенную функцию (__paritysi2); это не будет быстро.
Спасибо, люблю такое. Почти всё угадал, кроме города из стратегии и вопросов про МассЭффект с Биошоком (не играл в них).
Да, там вопрос неудачный. Как-то совпало, что как раз недавно с ребёнком почему-то поговорили про амплитуду высот в майнкрафте. Так вот, после релиза там достаточно долго было 256, а начиная с версии 1.17 сделали 384. А поначалу в альфа-версии вроде вообще 64 было.
Ну вот, обещали на Си, а код — на плюсах, да с набором антипаттернов, типа макросов где ни попадя. И зачем
писать #define mypoints std::vector<double>, когда специально для такого есть typedef или using?Не так давно пересматривал "Чужого" и "Чужих", и обратил внимание, насколько в первом фильме более классно визуал подан. Детали окружения, рельеф, объёмный свет, просто обалденно смотрится, почти каждый кадр как произведение искусства. А в "Чужих" всё более простое, плоское, свет проще, косяки в спецэффектах заметнее. В детстве когда смотрел, не замечал этого, и второй фильм нравился больше. Из-за движухи, наверное. А сейчас вот, думаю, отдал бы свой голос первому.
Вот, например, ConPTY API — нормальный человеческий интерфейс для (псевдо)консоли — появился только в 10-й винде... Ну и много других штук появлялось периодически, которые либо делали какой-то ранее возможный процесс удобнее, однозначее и/или универсальнее, либо добавляли новые фичи. Это сильно заметно, если программы под WINAPI пишешь. Правда.
Никаких проблем со стенами нет. Газовики только если к объёму котельной и наличию/размеру окна/взрывного клапана придраться могут. А для тех, кто не хочет газовый котёл прямо в доме (я, например, не хотел бы) продаются готовые мини-котельные (утеплённый домик с котлом внутри), которые можно поставить рядом с домом, на улице.
Ну, в моём домике это как минимум бойлер на 50 литров (а ведь мог быть и на 100), а также кухонные шкафчики. И под то, и под то пришлось заранее просчитывать место для монтажа и делать закладные.
Тоже живу в самодельном каркаснике и достраиваю газобетонный. И с ходу только один минус у каркасника могу назвать — не получится в произвольном месте в стену засверлиться и что-то тяжёлое повесить, всё заранее надо просчитывать и закладные в стенах делать. Впрочем, и на газобетон что-то достаточно тяжёлое навесить может быть проблемно.