Rust: C interop에 대한 지원 비트 필드

불가피해 보입니다. 매크로 경로를 먼저 시도하는 것이 좋습니다.

그것은 나에게 불가피해 보이지는 않는다... 나는 우리가 uint와 명시적 마스킹을 사용하여 잘 할 수 있다고 느낀다. 물론 비트 집합을 지원하는 일부 매크로는 괜찮을 것입니다. 비트 필드의 레이아웃이 LLVM이 아닌 clang으로 완전히 수행된다고 생각합니다. 비록 제가 틀릴 수 있지만, 이는 우리가 지원하는 데 상당한 고통이 될 것입니다.

솔직히 말해서 C에서도 비트필드의 매력을 이해하지 못했습니다. 항상 레이아웃과 마스킹에 대한 제어권을 컴파일러에 넘기는 것처럼 보였지만 세부 사항에 대해 많이 신경 쓸 때만 사용합니다. -- 정확히 무슨 일이 일어나고 있는지 정확히 알고 싶을 때.

컴파일러의 코드 생성이 신뢰할 수 없기 때문에 Linux 커널(및 많은 라이브러리)은 일반적으로 비트 필드를 피합니다. 정렬, 순서 및 레이아웃은 구현에 달려 있으므로 다른 ABI를 지원해야 합니다. http://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit_002dfields-implementation.html

네, 저는 이것을 피하는 것이 좋습니다.

이것은 Servo에서 이를 수행하기 위해 C shim을 사용하여 이러한 문제를 피하기 위해 각 필드를 가져오거나 설정해야 함을 의미합니까?

Rust에 대해 읽는 동안 이 문제를 우연히 발견했습니다. 저는 임베디드 C/C++ 코드 개발을 많이 하고 UART 연결 장치의 상태를 표현하기 위해 비트 필드를 사용하기 때문에 비트 필드에 대해 궁금했습니다. 상태는 꽤 크지만 비트필드 덕분에 나쁘지 않습니다. 낮은 메모리 제약으로 인해 부울, 특정 작은 정수 및 열거형을 단일에서 소수의 비트로 표시하는 것은 매우 깨끗합니다. Rust가 4KB - 16KB 메모리 범위를 가진 장치에서 실행되기를 원하는지 확실하지 않지만 단일 비트 플래그를 얻기 위해 매크로를 사용해야 하는 경우에는 Rust를 사용하지 않을 것입니다. 비트필드는 매크로가 읽을 수 없는 팽창을 만드는 매우 높은 수준의 코드를 허용합니다. ABI/특정 정렬 호환성이 필요한 경우 물론 매크로가 유일한 선택일 수 있습니다. 아마도 Servo와 같은 프로젝트 또는 Rust의 미래 Javascript 엔진은 내부적으로 비트 필드를 사용하여 특정 경우에 메모리를 절약할 수 있습니다.

@RushPL : Rust 매크로는 C 매크로와 다릅니다. 그것들은 텍스트 대체가 아니라 패턴 일치(선언적 매크로) 또는 Rust 코드(절차적 매크로)를 통해 토큰 트리를 조작합니다. 어떤 경우에는 그것들 없이 더 나은 구문을 제공할 수 있지만, Rust는 이미 유형 검사 형식 문자열( std::fmt )과 같은 것에 대해 매크로를 많이 사용합니다.

글쎄, 그것은 여전히 ​​특정 비트 번호를 제공하는 것을 포함할 것입니다. 맞습니까? (따라서 코드 오류가 발생하기 쉽습니다)
let some_state = int_from_bits!(object.state, 3, 5) // 5 bit number from bit 3
대
let some_state = object.some_state // compiler does all the magic as it should be

글쎄, 당신이 할 수 있는 한 가지는 그것에 접근하기 위한 메소드로 struct 를 생성하는 것입니다. 손실은 Rust의 컴파일 타임 함수 실행 부족으로 인해 상수 표현식에서 사용할 수 없다는 것입니다.

비트 필드를 사용하지 않지만 코드를 생성하는 것이 좋은 답이라면 C 또는 C++로 할 수 있는 것과 같은 일입니까? 지원하는 제네릭을 건너뛰고 대신 다른 유형에 대한 모든 코드를 생성할 수 있습니다. 어쨌든, 데이터 구조의 크기와 임베디드 필드의 사용 용이성에 관심이 있는 사람의 관점에서 볼 때 단지 2센트입니다.

참조: RFC: 비트 필드 및 비트 일치
https://github.com/rust-lang/rfcs/pull/29

새로운 bitflags! 매크로가 이 문제를 해결합니까?

https://github.com/mozilla/rust/pull/13072

미지근한 응답과 모호한 요구 사항을 고려할 때 이 문제를 닫는 것이 현명할 수 있습니다.

이 문제는 RFC 저장소로 이동되었습니다: rust-lang/rfcs#314