Nos cabeçalhos stdint.h
(C99), boost / cstdint.hpp e cstdint
(C ++ 0x) existe, entre outros, o tipo int32_t
.
Existem tipos semelhantes de ponto flutuante de tamanho fixo? Algo assim float32_t
?
Nos cabeçalhos stdint.h
(C99), boost / cstdint.hpp e cstdint
(C ++ 0x) existe, entre outros, o tipo int32_t
.
Existem tipos semelhantes de ponto flutuante de tamanho fixo? Algo assim float32_t
?
sizeof
operadora. Um tipo como esse seria útil quando um algoritmo exigir que ele tenha um tamanho específico conhecido.
sizeof
ser usado para resolver o problema de tipos flutuantes de empacotamento e desempate de forma consistente?
Respostas:
Nada como isso existe nos padrões C ou C ++ no momento. Na verdade, não há nem mesmo uma garantia de que float
será um formato de ponto flutuante binário.
Alguns compiladores garantem que o float
tipo será o formato binário IEEE-754 de 32 bits. Alguns não. Na realidade, float
é o single
tipo IEEE-754 na maioria das plataformas não embarcadas, embora se apliquem as advertências usuais sobre alguns compiladores que avaliam expressões em um formato mais amplo.
Há um grupo de trabalho discutindo a adição de associações de linguagem C para a revisão de 2008 do IEEE-754, que pode considerar a recomendação de adicionar tal typedef. Se isso fosse adicionado ao C, espero que o padrão C ++ siga o exemplo ... eventualmente.
Se você quer saber se o seu float
é do tipo IEEE de 32 bits, verifique std::numeric_limits<float>::is_iec559
. É uma constante de tempo de compilação, não uma função.
Se você quiser ser mais à prova de balas, verifique também std::numeric_limits<float>::digits
se eles não estão usando furtivamente o padrão de precisão dupla do IEEE para float
. Deve ser 24.
Quando se trata de long double
, é mais importante verificar digits
porque existem alguns formatos IEEE que podem ser razoavelmente: 128 bits (dígitos = 113) ou 80 bits (dígitos = 64).
Não seria prático fazer float32_t
isso porque você geralmente deseja usar hardware de ponto flutuante, se disponível, e não recorrer a uma implementação de software.
long double
formato no OS X (Intel de 32 bits e 64 bits) é exatamente o formato duplo estendido IEEE-754 armazenado na ordem little-endian. Nada de estranho nisso tudo. Os bytes 0-7 contêm o campo de significando e os bytes 8 e 9 contêm os campos de expoente e sinal.
5.0L
tem um significando de a000000000000000
. Seu expoente não enviesado é +2, e a polarização do expoente estendido duplo é 3fff
, então o expoente polarizado para 5.0L é 4001
. O padrão de bytes real quando armazenado na ordem little-endian é 00 00 00 00 00 00 00 a0 01 40
, e se você vir isso como dois inteiros little-endian de 64 bits, verá exatamente o que observou.
4001
em little-endian é 01 40 00 00 ...
Se nada mais, o byte menos significativo vem primeiro. Espero que a sequência a0 01 40
apareça em algum lugar do número (se eles apenas executaram uma rotação), mas não acho que você explicou o porquê a0
e 01 40
estão em metades completamente separadas.
Se você acha que ter typedefs como float32_t e float64_t é impraticável por alguma razão, você deve estar muito acostumado com seu sistema operacional familiar, compilador, que não consegue olhar para fora de seu pequeno ninho.
Existem hardwares que executam nativamente operações de ponto flutuante IEEE de 32 bits e outros que executam 64 bits. Às vezes, esses sistemas até precisam se comunicar, caso em que é extremamente importante saber se um duplo é de 32 bits ou 64 bits em cada plataforma. Se a plataforma de 32 bits fizesse cálculos excessivos com base nos valores de 64 bits da outra, podemos desejar lançar para a precisão mais baixa, dependendo dos requisitos de tempo e velocidade.
Eu pessoalmente me sinto desconfortável usando flutuadores e duplos, a menos que eu saiba exatamente quantos bits eles estão em minha plataforma. Ainda mais se eu for transferi-los para outra plataforma em algum canal de comunicação.
Atualmente, existe uma proposta para adicionar os seguintes tipos ao idioma:
decimal32
decimal64
decimal128
que pode um dia ser acessível através #include <decimal>
.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.html