Melhor resposta
> cat pointersize.c
#include
int main(){
int *ip;
printf(“pointer size: \%zu\n”, sizeof(ip));
}
> cc -o pointersize pointersize.c
> ./pointersize
pointer size: 8
> cc -m32 -o pointersize pointersize.c
> ./pointersize
pointer size: 4
O tamanho do ponteiro depende apenas do modelo sob o qual você está compilando seu código. Não no sistema operacional. Eu tenho um Linux de 64 bits, mas se eu forçar o gcc a compilar o código de 32 bits, obtenho o código ELF de 32 bits e i386 com um ponteiro de apenas 4 bytes.
Se você obter 4 bytes no seu Windows, isso significa que você ainda estão compilando 32 bits e você deve encontrar a opção para liberar todo o potencial de sua máquina. Liberte o Kraken!
Acabei de avaliar que ontem, entre o desempenho do código i386 de 32 bits e x86\_64 bdver2 (Piledriver, Haswell e superior) pode ser mais do que fator 5 no ganho de velocidade, não apenas o uso modelo de memória maior. Isso geralmente não é tão crítico, 4 GB de memória são suficientes para a maioria dos aplicativos.
Mas com apenas código de 32 bits você começa a perder as habilidades de MMX, SSE, SSE2,3,4 e muitos avanços em montagem sobre o últimos 35 anos. Bem como o acesso mais rápido para qualquer transferência de dados, manipulação de bits, operações de string, funções matemáticas avançadas e, e, e,…
Embora em alguns casos o código x86 original seja uma vantagem: você não pode Vença a rigidez do código!
Editar: (e um pequeno discurso retórico, você pode ignorar)
Tudo bem, eu sempre verifico o valor de frases como essa. Acabei de compilar o código legado x86\_64 vs 8086. 53 bytes para x88\_64 vs 74 bytes no código legado 8086 com um pequeno programa. Bem … Se você mantiver em 8/16 bits, isso pode ser verdade. Mas não com softwares modernos e programas c e compiladores. Então, sem lágrimas sobre os velhos tempos de legado se foram. Vamos ser honestos: eles eram uma merda. A única coisa boa era que eu era jovem e brilhante naquela época. Mas isso tinha outras desvantagens.
A questão é: nossos processadores modernos são muito legais. Temos agora o que só tínhamos em nossos sonhos na década de 80. Finalmente, temos discos rígidos grandes o suficiente para que não nos importemos com um ou dois bytes. Temos memória grande o suficiente, se não dirigirmos o Windows ou outros consumidores de recursos. Temos processamento vetorial em nossa CPU e computação paralela total em nossas GPUs. Temos multicores, FPUs matemáticos, registros especializados como em MMX, SSE, SSEx, temos FMA3 e FMA4 (bem, se você tiver um processador AMD, pelo menos terá que esperar muito tempo para colocar as mãos nele), nós temos opcodes de montagem altamente sofisticados que fazem todas as coisas legais em microcódigo ou até mesmo em hardware para nós, muitas vezes, apenas feito em um ciclo, temos memória cache que é maior do que qualquer coisa que ousaríamos sonhar nos anos 80 .
E o que estava por vir nos anos 80 era o CD e a ideia de armazenar gigabytes estonteantes em uma placa de prata barata era simplesmente inimaginável. E temos telefones com computadores, que são capazes de simular os maiores computadores mainframe de 85 por fator de velocidade de 10.000 ou algo assim.
Agora temos todo o material legal!
Mas o que estamos fazendo com isso? Nós tuímos 144 caracteres. Ninguém conhece mais as maravilhas dos opcodes de montagem de nossos novos processadores. Nós simplesmente retiramos a porra do spam e conduzimos os sistemas Windows, que foram classificados como “acabaram logo”, “merdos”, “o que você faz com essa porcaria” até 1985, quando comecei a estudar.
Não realmente não ficou melhor com o Windows. Ele ainda está cheio de bugs e uma porcaria de spam de malware, que monopoliza as maravilhas do nosso hardware de computador, que são tão incríveis que, se você instalar um sistema operacional melhor adequado para o nosso tempo, vai explodir sua mente. Especialmente como desenvolvedor.
O desenvolvimento de nossos processadores está desacelerando com apenas dois concorrentes restantes no mercado e deve ser hora de realmente liberar o que já temos: desligue essa merda de 32 bits, comece a otimizar nosso código da biblioteca em montagem onde podemos. Opcional, com sempre um fallback para “C” puro.
E que porra é o Twitter? Isso é uma piada, não é? 144 caracteres ?! Isso não é sério, ou? Eles notaram que tipo de hardware temos? Nenhuma palavra contra o Twitter, bom serviço, mas você sabe o que quero dizer. Eles estão pensando tão pequeno e falham mesmo assim.
Resposta
Você vai odiar essa resposta.
Pronto?
Depende.
Um ponteiro é o tamanho de um endereço na máquina para a qual o programa C está sendo compilado.
- No microprocessador Z80, popular na década de 1980, um ponteiro tem 16 bits.
- No 8086 original, um ponteiro pode ter 16, 20 ou 32 bits, embora o espaço de endereço tenha apenas 20 bits de largura. Você tinha que fornecer ao compilador C um argumento de linha de comando que dizia a largura do ponteiro. Foi um pesadelo.Procure “ modelo de memória ” na wikipedia para uma longa e horripilante introdução.
- No microprocessador 68000, os ponteiros eram de 32 bits.
- No modelo x86 usado para processadores Intel até cerca de 5 anos atrás, e ainda utilizável, um ponteiro era de 32 bits, permitindo-lhe endereçar cerca de 4 GB. Essa limitação leva à criação de endereços de 64 bits.
- No modelo x64 usado para processadores Intel das últimas gerações, um ponteiro tem 64 bits.
Você não pode suponha que um ponteiro tenha o mesmo tamanho de um int ou o mesmo tamanho de um longo. A constante inteira 0 pode ser convertida em um ponteiro, mas outras constantes inteiras podem não ser conversíveis. Quando você converte 0 em um ponteiro, não há garantia de que os bits contidos no ponteiro serão todos zeros, embora isso seja típico. Pode ser qualquer coisa. 0 é convertido em um ponteiro que não aponta para um endereço válido. Você pode adicionar um inteiro a um ponteiro, produzindo um ponteiro, ou subtrair um inteiro de um ponteiro, produzindo um ponteiro. Qualquer outra coisa tem efeito indefinido.