C/C++ bitfields versus operadores bit a bit para seleccionar bits individuales, ¿qué es más rápido, mejor y más portátil?

Question

que necesita para empacar algunos bits en un byte de esta manera:

struct 
{ 
    char bit0: 1; 
    char bit1: 1; 
} a; 

if(a.bit1) /* etc */ 

o:

if(a & 0x2) /* etc */ 

Desde la claridad del código fuente que es bastante obvio para mí que son campos de bits más ordenado. Pero, ¿qué opción es más rápida? Sé que la diferencia de velocidad no será demasiado si la hay, pero como puedo usar cualquiera de ellos, si uno es más rápido, mejor.
Por otro lado, he leído que no se garantiza que los campos de bits organicen bits en el mismo orden en todas las plataformas, y quiero que mi código sea portátil.

Notas: Si planeas responder "Perfil" bien, lo haré, pero como soy flojo, si alguien ya tiene la respuesta, mucho mejor.
El código puede estar equivocado, puede corregirme si lo desea, pero recuerde cuál es el punto de esta pregunta y por favor intente y responda también.

Answer 1

Preferiría usar el segundo ejemplo en preferencia por la máxima portabilidad. Como señaló Neil Butterworth, el uso de bitfields es solo para el procesador nativo. Ok, piensen en esto, ¿qué pasa si el x86 de Intel dejara de funcionar mañana, el código se bloqueará, lo que significa tener que volver a implementar los campos de bits para otro procesador, digamos RISC?

Tienes que ver la imagen más grande y preguntar cómo logró OpenBSD portar sus sistemas BSD a muchas plataformas usando una sola base de código. Vale, admito que es un poco exagerado, discutible y subjetivo, pero hablando de forma realista, si quieres transferir el código a otra plataforma, es la manera de hacerlo usando el segundo ejemplo que usaste en tu pregunta .

No solo eso, los compiladores para diferentes plataformas tendrían su propia forma de relleno, alineando bitfields para el procesador donde está el compilador. Y, además, ¿qué pasa con la endianess del procesador?

Nunca confíe en bitfields como una bala mágica. Si desea velocidad para el procesador y se fijará en él, es decir, no tiene intención de transferir, puede utilizar los campos de bits. ¡No puede tener ambas cosas!

Answer 2

Si desea portabilidad, evite los campos de bits. Y si está interesado en el rendimiento de un código específico, no hay alternativa a escribir sus propias pruebas. Recuerde, Bitfields usará las instrucciones bit a bit del procesador debajo del capó.

Answer 3

Creo que un programador C tenderá hacia la segunda opción de usar máscaras de bits y operaciones lógicas para deducir el valor de cada bit. En lugar de tener el código lleno de valores hexadecimales, las enumeraciones se configurarían o, por lo general, cuando se trata de operaciones más complejas, macros para obtener/establecer bits específicos. He escuchado en la vid, que los campos de bit implementados de la estructura son más lentos.

Answer 4

El primero es explícito y sea cual sea la velocidad, la segunda expresión es propensa a errores porque cualquier cambio en su estructura puede hacer que la segunda expresión sea incorrecta.

Utilice el primero.

Answer 5

Los campos de bits hacen que el código sea mucho más claro si se usan de forma adecuada. Yo usaría bitfields solo como un dispositivo de ahorro de espacio. Un lugar común en el que los he visto es en los compiladores: a menudo, la información de tipo o símbolo consiste en un grupo de indicadores de verdadero/falso. Los bitfields son ideales aquí ya que un programa típico tendrá muchos miles de estos nodos creados cuando se compile.

No utilizaría bitfields para hacer un trabajo de programación incrustado común: leer y escribir registros de dispositivos. Prefiero usar turnos y máscaras aquí porque obtienes exactamente los bits que la documentación te dice que necesitas y no tienes que preocuparte por las diferencias en la implementación de varios bitios de los compiladores.

En cuanto a la velocidad, un buen compilador dará el mismo código para los campos de bits que el enmascarado.

Answer 6

C bitfields nacieron muertos desde el momento en que se inventaron, por razones desconocidas. A la gente no les gustó y usó operadores bit a bit en su lugar. Tienes que esperar que otros desarrolladores no entiendan el código de bit de C.

Con respecto a cuál es más rápido: irrelevante. Cualquier compilador de optimización (lo que significa prácticamente todo) hará que el código haga lo mismo en cualquier notación. Es un concepto erróneo común de los programadores C que el compilador simplemente busque y reemplace las palabras clave en el ensamblado. Los compiladores modernos usan el código fuente como un plan para lo que se debe lograr y luego emiten un código que a menudo se ve muy diferente pero que logra el resultado deseado.

Answer 7

No lea mucho en los "campos de bits no portátiles". Hay dos aspectos de los campos de bits que están definidos por la implementación: la firma y el diseño y uno no especificado: la alineación de la unidad de asignación en la que están empaquetados. Si no necesita nada más que el efecto de embalaje, usarlos es tan portátil (siempre que especifique explícitamente una palabra clave signed cuando sea necesario) como llamadas a funciones que también tienen propiedades no especificadas.

En cuanto al rendimiento, el perfil es la mejor respuesta que puede obtener. En un mundo perfecto, no habría diferencia entre las dos escrituras. En la práctica, puede haber algunos, pero puedo pensar en tantas razones en una dirección como en la otra. Y puede ser muy sensible al contexto (diferencia lógicamente sin sentido entre sin firma y firmada por ejemplo) así que mida en contexto ...

En resumen, la diferencia es principalmente una diferencia de estilo en los casos donde realmente tiene la opción (es decir, no si el diseño preciso es importante). En esos casos, se trata de una optimización (en tamaño, no en velocidad) y, por lo tanto, tendía primero a escribir el código sin él y agregarlo después si fuera necesario. Por lo tanto, los campos de bits son la elección obvia (las modificaciones que se deben realizar son las más pequeñas para lograr el resultado y están contenidas en el lugar único de definición en lugar de extenderse a todos los lugares de uso).