Что решает, что целочисленный тип по умолчанию подписан или беззнаковый?

За исключением bool и расширенных типов символов, интегральные типы могут быть знаковыми или беззнаковыми (34 стр. C ++ Primer 5ed)

«может быть» сбивает меня с толку, однако, пожалуйста, не давайте такой ответ, Я не спрашиваю разницу между, например, int и unsigned int, когда вы явно записываете их в декларации. Я хотел бы знать для типа char, short, int, long, long long, в каком состоянии он подпален или беззнаковый

Я написал простой тестовый код на своем Mac и скомпилировал компилятором GNU, он говорит, что char подпалин

#include <iostream>
#include <limits>
using namespace std;

int main( int argc, char * argv[] )
{
    int minChar = numeric_limits<char>::min(); 
    int maxChar = numeric_limits<char>::max(); 


    cout << minChar << endl; // prints -128
    cout << maxChar << endl; // prints 127
    return 0;
}

Тот же механизм был применен ко всем знаковым целочисленным типам, и результаты показаны ниже.

minOfChar: -128
maxOfChar: 127
minOfShort: -32768
maxOfShort: 32767
minOfInt: -2147483648
maxOfInt: 2147483647
minOfLong: 0    // This is interesting, 0
maxOfLong: -1   // and -1  :p
minOfLongLong: 0 // shouldn't use int to hold max/min of long/long long #Bathsheba answered below
maxOfLongLong: -1 // I'll live this error unfixed, that's a stupid pitiful for newbies like me, also good for leaning :)

Результат говорит мне, что для char, short, int, long, long long, который скомпилирован g ++ на Mac, по умолчанию используются целые числа.

Итак, вопрос в названии:

Что определяет интегральный тип - подпаленный или беззнаковый


person SLN    schedule 26.01.2018    source источник
comment
Только char не имеет подписи в некоторых системах, потому что это может работать лучше всего на базовом оборудовании. Возвращается к портам C 1970-х годов.   -  person Bo Persson    schedule 26.01.2018
comment
@BoPersson Значит, это зависит от платформы и компилятора   -  person SLN    schedule 26.01.2018
comment
Прочтите: en.cppreference.com/w/cpp/language/types   -  person Richard Critten    schedule 26.01.2018
comment
Все дело в платформе. В некоторых системах знаковый символ может быть неестественным и медленнее, чем беззнаковый.   -  person Bo Persson    schedule 26.01.2018
comment
@BoPersson Спасибо!   -  person SLN    schedule 26.01.2018
comment
Цитируемый вами текст просто говорит о существовании int и unsigned int и т. Д. int всегда подписан   -  person M.M    schedule 26.01.2018


Ответы (1)


Помимо char, подписи интегральных типов указываются в стандартах C и C ++ либо явно, либо путем простого следствия диапазонов, которые типы должны реализовать.

Подписанность char определяется конкретной реализацией C и C ++; т.е. обычно это зависит от компилятора. И выбор будет сделан в соответствии с аппаратной частью.

Обратите внимание, что char, signed char и unsigned char - все разные типы, почти так же, как int и long являются разными типами, даже если они имеют одинаковый размер и схему дополнения.

Также не рекомендуется назначать, например,

numeric_limits<long>::min(); 

до значения int, поведение этого может быть неопределенным. Почему бы не использовать

auto foo = numeric_limits<whatever>::min();

вместо?

person Bathsheba    schedule 26.01.2018
comment
@ 水 飲 み 鳥: Длинное должно быть способно представлять -2 ‹sup› 32 ‹/sup› + 1 - person Bathsheba; 26.01.2018
comment
@ 水 飲 み 鳥: Да, это так. Что именно вы здесь пытаетесь сказать? Если диапазон включает отрицательные и положительные значения, тогда это должен быть знаковый тип. Вряд ли это ракетостроение. - person Bathsheba; 26.01.2018
comment
Спасибо за помощь! Также интересно узнать о 0 и -1 для long и long long. Это может быть новый вопрос. Тем не менее, я ценю, что вы могли написать пару строк. - person SLN; 26.01.2018
comment
Как вы думаете, связано ли это с тем, что то, что возвращает numeric_limits<>, хранится в int? - person 眠りネロク; 26.01.2018
comment
@ 水 飲 み 鳥: Да, это правильно. Использование int в качестве типа - безумие. - person Bathsheba; 26.01.2018
comment
@Bathsheba Ах, отлично. Спасибо за объяснение! - person 眠りネロク; 26.01.2018