Os tipos de largura variável foram substituídos por tipos fixos no C moderno?

Hoje me deparei com um ponto interessante em uma revisão sobre o Code Review . O @Veedrac recomendou nesta resposta que tipos de tamanho variável (por exemplo, inte long) sejam substituídos por tipos de tamanho fixo como uint64_te uint32_t. Citação dos comentários dessa resposta:

Os tamanhos de int e long (e, portanto, os valores que eles podem conter) dependem da plataforma. Por outro lado, int32_t sempre tem 32 bits. Usar int apenas significa que seu código funciona de maneira diferente em plataformas diferentes, o que geralmente não é o que você deseja.

O raciocínio por trás do padrão que não corrige os tipos comuns é parcialmente explicado aqui por @supercat. C foi escrito para ser portátil em todas as arquiteturas, ao contrário da montagem que geralmente era usada para programação de sistemas na época.

Eu acho que a intenção do projeto era originalmente que cada tipo, exceto int, fosse a menor coisa que pudesse lidar com números de vários tamanhos, e que esse seria o tamanho "de uso geral" mais prático que poderia lidar com +/- 32767.

Quanto a mim, sempre usei inte não me preocupo com as alternativas. Eu sempre pensei que é o tipo mais com melhor desempenho, final da história. O único lugar que achei que a largura fixa seria útil é ao codificar dados para armazenamento ou transferência em uma rede. Eu raramente vi tipos de largura fixa no código escrito por outras pessoas também.

Estou preso nos anos 70 ou existe realmente uma justificativa para usar intna era do C99 e além?

Existe um mito comum e perigoso de que tipos como uint32_tsalvar programadores de terem que se preocupar com o tamanho de int. Embora seja útil que o Comitê de Padrões defina um meio de declarar números inteiros com semântica independente de máquina, tipos não assinados como uint32_tsemântica são muito frouxos para permitir que o código seja escrito de maneira limpa e portátil; além disso, tipos assinados como int32semântica são, para muitas aplicações, formas definidas de forma desnecessária e, portanto, impedem o que de outra forma seriam otimizações úteis.

Considere, por exemplo:

uint32_t upow(uint32_t n, uint32_t exponent)
{
  while(exponent--)
    n*=n;
  return n;
}

int32_t spow(int32_t n, uint32_t exponent)
{
  while(exponent--)
    n*=n;
  return n;
}

Em máquinas nas quais intnão é possível conter 4294967295 ou 18446744065119617025, a primeira função será definida para todos os valores de ne exponent, e seu comportamento não será afetado pelo tamanho de int; além disso, o padrão não exigirá que ele produza comportamento diferente em máquinas com qualquer tamanho de int Alguns valores de ne exponent, no entanto, fará com que invoque o Comportamento indefinido em máquinas nas quais 4294967295 é representável como int18446744065119617025, mas não é.

A segunda função produzirá Comportamento indefinido para alguns valores de ne exponentem máquinas onde intnão pode conter 4611686014132420609, mas produzirá um comportamento definido para todos os valores de ne exponentem todas as máquinas em que puder (as especificações int32_timplicam que o comportamento de quebra de complemento de dois em máquinas onde é menor que int).

Historicamente, mesmo que o Padrão não dissesse nada sobre o que os compiladores deveriam fazer com o inttransbordamento upow, os compiladores teriam consistentemente produzido o mesmo comportamento como se inttivesse sido grande o suficiente para não transbordar. Infelizmente, alguns compiladores mais recentes podem tentar "otimizar" programas, eliminando comportamentos não exigidos pelo Padrão.

Para valores intimamente relacionados a ponteiros (e, portanto, à quantidade de memória endereçável), como tamanhos de buffer, índices de matriz e Windows ' lParam, faz sentido ter um tipo inteiro com um tamanho dependente da arquitetura. Portanto, tipos de tamanho variável ainda são úteis. É por isso que temos os typedefs size_t, ptrdiff_t, intptr_t, etc. Eles têm que ser typedefs porque nenhum dos built-in C inteiro tipos precisa ser ponteiro porte.

Então a questão é realmente se char, short, int, long, e long longainda são úteis.

IME, ainda é comum os programas C e C ++ usarem intpara a maioria das coisas. E na maioria das vezes (ou seja, quando seus números estão na faixa de ± 32.767 e você não possui requisitos rigorosos de desempenho), isso funciona perfeitamente.

Mas e se você precisar trabalhar com números no intervalo de 17 a 32 bits (como as populações das grandes cidades)? Você poderia usar int, mas isso codificaria uma dependência de plataforma. Se você quiser longseguir rigorosamente o padrão, poderá usar o que é garantido em pelo menos 32 bits.

O problema é que o padrão C não especifica nenhum tamanho máximo para um tipo inteiro. Existem implementações nas quais longsão 64 bits, o que duplica o uso de memória. E se esses longelementos forem elementos de uma matriz com milhões de itens, você estragará a memória como um louco.

Portanto, intnem longé um tipo adequado para usar aqui se você deseja que seu programa seja multiplataforma e com eficiência de memória. Enter int_least32_t.

• Seu compilador I16L32 oferece 32 bits long, evitando os problemas de truncamento doint
• Seu compilador I32L64 oferece 32 bits int, evitando a perda de memória do 64 bits long.
• O seu compilador I36L72 oferece uma instalação de 36 bits. int

OTOH, suponha que você não precise de grandes números ou matrizes enormes, mas precisa de velocidade. E intpode ser grande o suficiente em todas as plataformas, mas não é necessariamente o tipo mais rápido: os sistemas de 64 bits geralmente ainda têm 32 bits int. Mas você pode usar int_fast16_te obter o tipo “mais rápido”, se é int, longou long long.

Portanto, existem casos de uso práticos para os tipos de <stdint.h>. Os tipos inteiros padrão não significam nada. Especialmente long, que pode ter 32 ou 64 bits e pode ou não ser grande o suficiente para conter um ponteiro, dependendo do capricho dos escritores do compilador.