std :: bitset보다 c 스타일 비트 조작에 이점이 있습니까?

나는 거의 C ++ 11/14에서 독점적으로 일하고 일반적으로 다음과 같은 코드를 볼 때 울다.

std::int64_t mArray;
mArray |= someMask << 1;

이것은 단지 예일뿐입니다. 나는 일반적으로 비트 단위 조작에 대해 이야기하고 있습니다. C ++에서는 실제로 어떤 점이 있습니까? 위의 내용은 마음이 뒤틀리고 오류가 발생하기 쉬운 반면을 사용 std::bitset하면 다음을 수행 할 수 있습니다.

1. std::bitset템플릿 매개 변수를 조정하고 구현이 나머지를 처리하도록하여 필요에 따라 크기를보다 쉽게 ​​수정합니다.
2. 무슨 일이 일어나고 있는지 (그리고 실수를 저지르는) 것을 알아내는 데 더 적은 시간을 소비하고 다른 데이터 컨테이너 std::bitset와 유사한 방식으로 작성하십시오 std::array.

내 질문은; 이전 버전과의 호환성을 제외하고 기본 유형을 초과 사용 하지 않는 이유가 std::bitset있습니까?

논리적 (기술적이지 않은) 관점에서는 이점이 없습니다.

모든 평범한 C / C ++ 코드는 적합한 "라이브러리 구성"내에 래핑 될 수 있습니다. 이러한 포장 후에, "이것이 그것보다 유리한지"라는 문제는 논쟁의 여지가된다.

C / C ++는 속도 관점에서 라이브러리 구성이 랩핑하는 일반 코드만큼 효율적인 코드를 생성 할 수 있도록해야합니다. 그러나 이것은 다음의 대상이됩니다 :

• 함수 인라인
• 컴파일 타임 확인 및 불필요한 런타임 확인 제거
• 데드 코드 제거
• 다른 많은 코드 최적화 ...

이러한 종류의 비 기술적 주장을 사용하면 "누락 된 기능"을 누구나 추가 할 수 있으므로 단점으로 간주되지 않습니다.

그러나 추가 코드로는 내장 요구 사항 및 제한 사항을 극복 할 수 없습니다. 아래에서는 크기 std::bitset가 컴파일 타임 상수이므로 단점으로 간주되지는 않지만 여전히 사용자의 선택에 영향을 미치는 것입니다.

미적 관점 (가독성, 유지 보수 용이성 등)에는 차이가 있습니다.

그러나 std::bitset코드가 즉시 일반 C 코드보다 우선 한다는 것은 분명하지 않습니다 . 사용 std::bitset하는 것이 소스 코드의 인간 품질을 향상 시켰 는지 말하기 위해 더 큰 코드 조각 (장난감 샘플이 아닌)을 조사해야 합니다.

비트 조작 속도는 코딩 스타일에 따라 다릅니다. 코딩 스타일은 C / C ++ 비트 조작에 영향을 미치며 std::bitset다음과 같이 적용 할 수 있습니다.

를 사용하여 operator []한 번에 한 비트 씩 읽고 쓰는 코드를 작성 하는 경우 조작 할 비트가 두 개 이상인 경우이 작업을 여러 번 수행해야합니다. C 스타일 코드도 마찬가지입니다.

그러나, bitset또한 다른 통신 사업자, 보유 operator &=, operator <<=등, 비트 세트의 전체 폭에 동작하는한다. 기본 장치는 종종 같은 비트 수의 CPU 주기로 한 번에 32 비트, 64 비트 및 때로는 128 비트 (SIMD 포함)에서 작동 할 수 있으므로 이러한 다중 비트 작업을 활용하도록 설계된 코드 "루프"비트 조작 코드보다 빠를 수 있습니다.

일반적인 아이디어는 SWAR (레지스터 내의 SIMD) 이며 비트 조작의 하위 주제입니다.

일부 C ++ 공급 업체는 bitsetSIMD를 사용하여 64 비트와 128 비트 사이에서 구현할 수 있습니다 . 일부 공급 업체는 그렇지 않을 수도 있지만 결국에는 그렇지 않을 수도 있습니다. C ++ 공급 업체의 라이브러리가 무엇을 수행해야하는지 알아야 할 경우 유일한 방법은 분해를 보는 것입니다.

std::bitset한계 가 있는지에 대해서는 두 가지 예를들 수 있습니다.

1. std::bitset컴파일시 크기를 알아야합니다. 동적으로 선택된 크기의 비트 배열을 만들려면을 사용해야 std::vector<bool>합니다.
2. 현재의 C ++ 사양 std::bitset은 더 큰 bitsetM 비트 에서 N 비트의 연속 슬라이스를 추출하는 방법을 제공하지 않습니다 .

첫 번째는 기본입니다. 즉, 동적 크기의 비트 세트가 필요한 사람들은 다른 옵션을 선택해야합니다.

두 번째 어댑터 는 표준을 bitset확장 할 수없는 경우에도 작업을 수행하기 위해 어떤 종류의 어댑터 를 작성할 수 있기 때문에 극복 할 수 있습니다 .

에서 기본적으로 제공되지 않는 특정 유형의 고급 SWAR 작업이 있습니다 std::bitset. 비트 순열에 대한이 웹 사이트의 이러한 작업에 대해 읽을 수 있습니다. 평소와 같이 위에서 구현하여 자체적으로 구현할 수 있습니다 std::bitset.

성능에 관한 토론.

하나의 훈계 : 많은 사람들 이 표준 라이브러리의 (무언가) 단순한 C 스타일 코드보다 훨씬 느린 이유에 대해 묻습니다 . 여기 microbenchmarking의 필수 지식을 반복하지,하지만 난 그냥이 조언을 (최적화가 활성화 된 상태) "릴리스 모드"에서 벤치 마크를 확인하고, 확인 코드가되고 있지 않은지 제거 (죽은 코드 제거) 또는 존재 루프 (루프-불변 코드 모션)에서 들어 올렸습니다 .

일반적으로 우리는 인터넷상에서 누군가가 마이크로 벤치 마크를 올바르게 수행하고 있는지 알 수 없기 때문에 신뢰할만한 결론을 얻을 수있는 유일한 방법은 마이크로 벤치 마크를 작성하고 세부 사항을 문서화하고 공개 검토 및 비평에 제출하는 것입니다. 다른 사람들이 이전에 해왔 던 마이크로 벤치 마크를 다시 실행하는 것은 아프지 않습니다.

이것은 모든 경우에 적용되는 것은 아니지만 때로는 알고리즘이 C 스타일의 비트 트위들 링의 효율성에 의존하여 상당한 성능 향상을 제공 할 수 있습니다. 내 마음에 떠오르는 첫 번째 예는 체스 보드 등의 속도를 높이기 위해 비트 보드, 보드 게임 위치의 영리한 정수 인코딩을 사용하는 것입니다. 여기서 체스 판은 항상 8 * 8이므로 정수 유형의 고정 크기는 문제가되지 않습니다.

간단한 예를 들어, 다음 함수 ( Ben Jackson이이 답변 에서 가져옴 )를 사용하여 Connect Four 포지션을 승리로 테스트하십시오.

// return whether newboard includes a win
bool haswon2(uint64_t newboard)
{
    uint64_t y = newboard & (newboard >> 6);
    uint64_t z = newboard & (newboard >> 7);
    uint64_t w = newboard & (newboard >> 8);
    uint64_t x = newboard & (newboard >> 1);
    return (y & (y >> 2 * 6)) | // check \ diagonal
           (z & (z >> 2 * 7)) | // check horizontal -
           (w & (w >> 2 * 8)) | // check / diagonal
           (x & (x >> 2));      // check vertical |
}