c++ - uint16_t - ¿Por qué no se permite `std:: uniform_int_distribution<uint8_t>` y `std:: uniform_int_distribution<int8_t>`?

uint8_t data type arduino

Question

Como dice la documentación :

El efecto no está definido si no es short , int , long , long long , unsigned short , unsigned int , unsigned long o unsigned long long .

Si no me importa el rango, solo puedo enmascarar los bits de un tipo más grande para generar números aleatorios. Si no, es más complejo. ¿Por qué los tipos de bytes no se proporcionan de forma predeterminada?

Answer 1

Hay un problema de grupo de trabajo de biblioteca sin resolver en esta uniform_int_distribution <unsigned char> debe estar permitido y dice, entre otras cosas:

No tengo conocimiento de nada en <random> que funcione con enteros de 16 bits pero que falle con enteros de 8 bits, por lo que sospecho que IntType y UIntType simplemente podrían extenderse para permitir la familia char. Alternativamente, este cambio podría limitarse a uniform_int_distribution solo, donde es definitivamente seguro. Un experto en <random> debería decidir cuál es el mejor cambio.

La resolución propuesta es cambiar la restricción para permitir tipos de enteros estándar:

que tiene un parámetro de tipo de plantilla llamado IntType no está definido a menos que el argumento de la plantilla correspondiente no esté IntType como IntType y sea un tipo de entero estándar (3.9.1 [basic.fundamental]

y:

que tiene un parámetro de tipo de plantilla llamado UIntType no está definido a menos que el argumento de la plantilla correspondiente no esté UIntType como UIntType y sea un tipo de entero sin signo estándar (3.9.1 [basic.fundamental])

Esto le da carácter no firmado / firmado aunque no es uint8_t ni int8_t, pero es probable que sean equivalentes. Se excluyeron los tipos integrales extendidos para simplificar la redacción y maximizar el consenso:

Esto también excluye los tipos integrales extendidos y los tipos de caracteres anchos, que, en el mejor de los casos, parecen ser buenos. No tengo ninguna objeción en apoyar ninguno de esos tipos; Acabo de elegir esto para simplificar la redacción y, con suerte, maximizar el consenso.

Tenga en cuenta que esto excluye char ya que su implementación está definida si char está firmado o no.

Tenga en cuenta que este tema también se mencionó en la lista de discusión estándar .

Jonathan Wakely observa que esta propuesta es controvertida y comentó que sus notas de la última discusión incluyen lo siguiente:

que fue definitivamente muy intencional que los enteros de un solo byte no sean compatibles, no una omisión accidental, por lo que debemos tener cuidado al cambiar eso sin consultar a los diseñadores de C ++ 11

Sugiere agregar un miembro a random_device para proporcionar bytes individuales, lo que parece ser una alternativa razonable.