제 의견으로는 bool과 같은 이진 변수에 필요한 모든 것이 하나 있습니다. 어떤 식 으로든 bool에 1 비트 만 사용하도록 명시 적으로 알리는 것은 나쁜 결정입니까?항상 1 비트 부울을 사용할 수 있습니까?
struct Banana {
// little fields
bool on_off : 1;
bool yes_no : 1;
bool left_right : 1;
bool alive_dead : 1;
bool in_out : 1;
};
편집 :
나는 필드의 주소를 취할 수 없음을 알고있다. 다른 단점이 있습니까?
이러한 항목이 많으면 공간을 절약 할 수 있습니다. 그러나 일반 1 바이트 솔루션보다 각 클리어/세트/검사 작업에 대해 최소한 AND 또는 OR 명령어를 추가합니다.
사실 전체적인 계획에서, 실제로 엄청난 숫자가 없으면 아무런 이점도 없을 것입니다.
즉, 전형적인 시간/공간 트레이드 오프입니다. (현대적인 메모리 액세스가 트레이드 오프의 조건을 바꿀 수 있다는 것을 제외하고는, 타입이 큰 벡터를 다루는 경우, 메모리 사용을 줄이면 런타임시 비트 필드 솔루션을보다 효율적으로 만들 수있는 지역이 될 수 있습니다 그러나 측정 할 때까지는 알 수 없을 것입니다. –
여분의'AND' 또는'OR'과'left shift'이 필요합니다. –
@TheOtherGuy 반드시 사용해야하는 것은 아닙니다. (예를 들어, VAX). "bool"은 조건부입니다.이 경우에는 변환이 필요하지 않습니다. (또한 구현에 따라 다르며 적어도 하나의 비트를 처리 할 수있는 프로세서가 있습니다.) –
시간/공간/동기화가 절충됩니다.
분명히 같은 공간에 32 비트만큼의 비트를 저장할 수 있습니다.
그러나 개별 bool에 액세스하려면 적어도 마스킹 작업이 필요하며 아마도 특정 상황에서는 최적화가 될 가능성이 있습니다.
업데이트를위한 간단한 쓰기를 읽기/수정/쓰기로 변경 했으므로 컨트롤의 여러 스레드가 부울을 수정하려고하면 결과가 동기화되므로 동기화를 추가해야합니다.
동기화에 대한 좋은 지적. 이 방법을 사용하면 스레드간에 단 하나의 부울 값만 공유 할 수 없습니다. 전체 저장된 값을 모든 부울과 공유해야합니다. 따라서 부울 값의 ** **를 만지는 것은 실제로 수정 된 부울에 아무런 관심이 없다고하더라도 저장된 값 전체를 보유하는 모든 캐시를 업데이트한다는 의미입니다. –
좋은 컴파일러/아키텍처/기능에서 부울을 비트 필드로 이동하면 이 크게 개선되어 코드 품질과 성능이 향상되었습니다.
불행히도 GCC는 이러한 컴파일러 중 하나가 아닙니다 (또는 내가 이것을 테스트 한 마지막 시간이 아니 었습니다).
여러 개의 부울을 하나의 레지스터에 저장하면 많은 레지스터가 누적 될 수 있으므로 스택에 많은 레지스터 누출이 제거되고 나머지 코드가 훨씬 효율적으로 처리됩니다.
아키텍처에 적절한 비트 처리 명령어 집합이있는 경우 테스트 및 조작 작업은 전체 레지스터 또는 더 나아가 스택에서 부울을 추출하는 비슷한 연산보다 작거나 같은 작은 연산 또는 일 수 있습니다.
일반적으로 (심지어 x86에서도) 비트 패킹 부울은 더 효율적인 코드를 생성해야하지만 제한은 컴파일러입니다.
예, 실적은 쓰레기가됩니다. – Joe
아마도 느려질 것입니다. 공간이 필요하신가요? – BoBTFish
'int'를 타입으로 사용하면 여전히 비트에'true' 또는'false'를 할당 할 수 있습니다. –