Какая польза от типа int в C?

Я читал, что компиляторы C должны выделять 2 байта для типа short и должны выделять 4 байта для типа long. Итак, в зависимости от системы тип int может иметь 2 или 4 байта. Итак, какова цель этого? Если нам нужно 2-байтовое число, мы можем использовать short, а если нам нужно 4-байтовое число, мы можем использовать long. Я чувствую, что int похож на азартную игру, независимо от того, 16-битная система или нет. (Я вообще не понимаю, почему C не может сам решить, сколько памяти нужно для числа, как это делает Python)


person ClassicEndingMusic    schedule 03.01.2015    source источник
comment
Компиляторы C должны выделять 2 байта для типа short и должны выделять 4 байта для типа long — это неверно, единственное требование к размерам целочисленных типов — это sizeof(char) == 1. На самом деле в моей системе long 64-битная. (изменить я ошибаюсь)   -  person Adrian    schedule 04.01.2015
comment
О, я читал это в своем учебнике..   -  person ClassicEndingMusic    schedule 04.01.2015
comment
Возможно, вы захотите получить другой учебник   -  person Adrian    schedule 04.01.2015
comment
Ну, есть много неправильных учебников. Хотя в этом случае это может быть частью лжи детям, или автор просто не знает, что char может быть чем угодно, кроме 8 бит.   -  person Deduplicator    schedule 04.01.2015
comment
@ Адриан: Его учебник правильный. short должно быть не менее 16 бит, int не менее 16 и long не менее 32. См. типы данных C или стандартный.   -  person Jon Purdy    schedule 04.01.2015
comment
@ Адриан Любые ссылки?   -  person ClassicEndingMusic    schedule 04.01.2015
comment
@JonPurdy Ну, в этом учебнике не сказано, по крайней мере, сказано, что должно быть ..   -  person ClassicEndingMusic    schedule 04.01.2015
comment
К вашей последней части стандарт C не может предписывать точное поведение и ширину каждого типа, потому что, в отличие от python, он нацелен на удобство использования и эффективность на широком спектре оборудования (что почти равно всем существующим системам) .   -  person Deduplicator    schedule 04.01.2015
comment
Если он говорит что-то вроде того, что какой-то тип должен иметь размер не менее двух байтов, это просто неправильно. Допустимый способ - сделать байт длиной 64 бита, а все типы - одним байтом.   -  person Deduplicator    schedule 04.01.2015
comment
@Deduplicator Можете ли вы опубликовать код, который сделает байт длиной 64 бита? Это кажется очень интересным :)   -  person Adrian    schedule 04.01.2015
comment
Я еще не написал компилятор C, извините. Хотя, взгляните на компиляторы для сигнальных процессоров, некоторые из них решили, что 64 бита — это максимальный и наименьший размер, который должен иметь тип.   -  person Deduplicator    schedule 04.01.2015
comment
Это правда, что изменение размера int не является хорошей идеей. Но это реализовано таким образом, и мы не можем изменить это сейчас.   -  person i486    schedule 04.01.2015
comment
@Deduplicator: это правда, но на практике все широко используемые архитектуры с 1980-х годов имеют CHAR_BIT == 8.   -  person Jon Purdy    schedule 04.01.2015
comment
@JonPurdy: Если вы игнорируете сигнальные процессоры и тому подобное, совершенно точно. Если вы этого не сделаете, это по крайней мере ошеломляет.   -  person Deduplicator    schedule 04.01.2015
comment
@ i486 Это действительно плохая идея? Разве int не тот размер, с которым система может выполнять операции быстрее всего. При указании размера int важны int8_t, int16_t и т. д. из stdint.h   -  person Forss    schedule 04.01.2015
comment
Проблема в том, что основной причиной изменения int является переносимость программного обеспечения. Вы определяете int и получаете оптимальный размер на разных платформах. НО это причина тысяч ошибок. Если вы считаете, что стандартный тип должен иметь переменный размер int и использовать определение типа int32_t - могу сказать: почему бы не наоборот? int32 может быть встроенным типом, и вы можете определить переносимый int в stdint.h. (Это нельзя изменить сейчас, но это может быть реальностью.)   -  person i486    schedule 04.01.2015
comment
Разве это не размер, на котором система может выполнять операции на самом быстром? Очень полезный факт, но может ли кто-нибудь это одобрить?   -  person ClassicEndingMusic    schedule 04.01.2015
comment
Если C использует арифметику произвольной точности в каждом случае, это очень плохо для производительности и памяти.   -  person phuclv    schedule 04.02.2015
comment
@JonPurdy многие DSP в настоящее время имеют 16/24 или 32-битные CHAR_BIT stackoverflow.com/questions/2098149/ некоторые другие странные архитектуры с CHAR_BIT != 8 также являются используется   -  person phuclv    schedule 04.02.2015
comment
O/T, вопрос, который вы только что удалили: Python очень динамичен, практически все можно исправить во время выполнения (см., Например, stackoverflow.com/ a/29488561/3001761). Однако, несмотря на некоторую поддержку функциональных парадигм, в этом отношении ему далеко до Лиспа.   -  person jonrsharpe    schedule 16.04.2015


Ответы (1)


В B, предке C, единственным типом был int. Это был размер «машинного слова», то есть размер регистра — 16 бит в 16-битной системе, 32 бита в 32-битной системе и так далее. C просто сохранил этот тип. short и long были введены как способы управления пространством для хранения, когда требовалось меньше или больше диапазона. Это важно, когда доступная память ограничена: зачем выделять long, когда вы знаете, что значение никогда не превысит диапазон short?

Я вообще не понимаю, почему C не может сам решить, сколько памяти нужно для числа, как это делает Python

Python решает это динамически, используя представление произвольной точности. C решает это статически и требует, чтобы это было указано программистом. Существуют статически типизированные языки, в которых аннотации типов не требуются из-за выведения типов. Если вам нужны целые числа произвольной точности в C, вы можете использовать GMP, который предоставляет mpz_t и множество других типов и функций. для арифметики произвольной точности.

person Jon Purdy    schedule 03.01.2015
comment
Я понимаю. Спасибо за ответ! - person ClassicEndingMusic; 04.01.2015