0

I've looked at some answers that use short in C#, but I'm not sure if they really answer my question here. Is short in C++ another name for int? I know you can make short int, which seems to be able to handle a lot of values but I'm still starting out, so obviously if it's short it's not a lot of values. But in this code snippet here:

short lives,aliensKilled;

it doesn't use int short, it just uses short. So I guess my question is, can I just use short as a replacement for int if I'm not going under -32,768 or over 32,767?

Also, is it okay to just replace short with int, and it won't really mess with anything as long as I change the appropriate things? (Btw lives and aliensKilled are both variable names.)

jogojapan
  • 68,383
  • 11
  • 101
  • 131
Set
  • 57
  • 3
  • 8
  • No. `short` is 2 bytes, `int` is 4 bytes. The ranges that each can store are different. – Maria Ines Parnisari Jun 01 '13 at 08:14
  • 4
    @l19 there is nothing that says that `int` has to be 4 bytes. – juanchopanza Jun 01 '13 at 08:17
  • So if I put `int score;` and then `score=0;`, is that 1 byte of data because it's only one digit? Or is it automatically 4 bytes? – Set Jun 01 '13 at 08:23
  • It depends on the context. In C, an `int` is guaranteed to be at least 16-bits of signed integer. These days, it is most commonly a 32-bit integer, but the C standard does not require that and it would be feasible to have `int` as a 64-bit quantity on a 64-bit machine. It isn't usually done, but it could be done — and would meet the C standard. – Jonathan Leffler Jun 01 '13 at 08:24
  • Is this generally a problem for programmers/video game makers then? Like say they use `int` throughout the code instead of using `short` where it COULD be used, it'd make for a more space-consuming program/game, if I'm catching this correctly? Or is this the amount of RAM memory it takes to "run" the program? – Set Jun 01 '13 at 08:27
  • @RobertMichaud: For things that occur thousands of times (large tables), using a smaller type makes sense. For two variables representing how many lives you have left or how many aliens you have killed in a "space-game" will save, perhaps, 4 bytes. In anything but a REALLY old system, that's nothing. Even when I started working on computers in 1985, there was 64KB of RAM in the system. Soon to be expanded to 256KB or more. – Mats Petersson Jun 01 '13 at 08:31
  • @Mats Petersson Ah, okay. Someone else down there said int should just generally be used for anything so I guess I'll just use that. It was just an example in the book so I was just a little confused but I guess it was just showing an example of what you CAN do. I'm not planning on making anything huge (yet), so I'm not worried about it. Thanks for the information! – Set Jun 01 '13 at 08:43

7 Answers7

5

In C++ (and C), short, short int, and int short are different names for the same type. This type is guaranteed to have a range of at least -32,767..+32,767. (No, that's not a typo.)

On most modern systems, short is 16 bits and int is 32 bits. You can replace int with short without ill effects as long as you don't exceed the range of a short. On most modern systems, exceeding the range of a short will usually result in the values wrapping around—this behavior is not guaranteed by the standard and you should not rely on it, especially now that common C++ compilers will prune code paths that contain signed integer overflow.

However, in most situations, there is little benefit to replacing int with short. I would only replace int with short if I had at least thousands of them. There's not always a benefit, by using short you can reduce the memory used and the bandwidth required, but you can potentially increase the number of CPU cycles required to convert from short to int (a short is always "promoted" to int when you do arithmetic on it).

Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
  • So is the symmetric range ("not a typo...") to allow for different signed integer representations? – juanchopanza Jun 01 '13 at 08:18
  • Using short makes sense if it's member of a structure in many cases, say you have two of them. – Balog Pal Jun 01 '13 at 08:19
  • the range req is minimum, and one's complement implementation would be in real trouble otherwise – Balog Pal Jun 01 '13 at 08:21
  • @BalogPal I would argue that it doesn't really matter if one use `short` or `int` in structures unless it's on small embedded systems (or 20 year old computers) or for binary protocols/file formats. Instead go for the increased range and lesser chance of over/under run. – Some programmer dude Jun 01 '13 at 08:24
  • So it's just best to use `int` for everything then? – Set Jun 01 '13 at 08:29
  • 1
    @Setari: I wouldn't go that far. My experience is that usually it is not worth it to try and evaluate which one is better for your particular application, because `int` is good enough 99% of the time. – Dietrich Epp Jun 01 '13 at 08:34
  • 1
    Another reason to prefer int to short is that arithmetic on shorts causes operands to undergo promotion, which can lead to confusing results. – Oliver Charlesworth Jun 01 '13 at 09:40
2

short int, int short and short are all synonymous in C and C++.

These work like int, but the range is smaller (typically, but not always) 16 bit. As long as none of the code relies on the transitions when the number "wraps around" due to it being 16 bits (that is, no calculation goes above the highest value (SHORT_MAX) or below the lowest value (SHORT_MIN)), using a larger type (int, long) will work just fine.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • You say "typically, but not always". Is this correct? I agree that implementations are not obliged to make their `short` type 16 bits -- but are there any out there? – TonyK Jun 01 '13 at 08:23
  • Isn't the requirement that `short` be *at least* 16 bits (based on the minimum range it should cover)? – juanchopanza Jun 01 '13 at 08:25
  • @TonyK: Types in C and C++ are defined by "must be at least this big". It can be bigger. `short` must also not be "bigger" than `int`, but it can be the same size. `long` can also be the same size as int, and it's perfectly valid to have all three the exact same size. If your code relies on "this number should have this many bits, or things will go wrong" (e.g. expecting overflows to have certain behaviour), there are types like `int16_t` and `int32_t` that only exist if that particular size is valid in that compiler. – Mats Petersson Jun 01 '13 at 08:28
  • Yes, but my question was: are there any compilers whose `short` is not 16 bits? – TonyK Jun 01 '13 at 08:51
  • @TonyK: You'd probably struggle to find one, but in a 36-bit IBM or DEC mainframe system, I bet it's 18 bits... – Mats Petersson Jun 01 '13 at 08:53
1

C++ (and C# and Objective-C and other direct descendants of C) have a quirky way of naming and specifying the primitive integral types.

As specified by C++, short and int are simple-type-specifiers, which can be mixed and matched along with the keywords long, signed, and unsigned in any of a page-full of combinations.

The general pattern for the single type short int is [signed] short [int], which is to say the signed and int keywords are optional.

Note that even if int and short are the same size on a particular platform, they are still different types. int has at least the same range as short so it's numerically a drop-in replacement, but you can't use an int * or int & where a short * or short & is required. Besides that C++ provides all kinds of machinery for working with types… for a large program written around short, converting to int may take some work.

Note also that there is no advantage to declaring something short unless you really have a reason to save a few bytes. It is poor style and leads to overflow errors, and can even reduce performance as CPUs today aren't optimized for 16-bit operations. And as Dietrich notes, according to the crazy way C arithmetic semantics are specified, the short is upcast to int before any operation is performed and then if the result is assigned back to a short, it's cast back again. This dance usually has no effect but can still lead to compiler warnings and worse.

In any case, the best practice is to typedef your own types for whatever jobs you need done. Always use int by default, and leverage int16_t, uint32_t from <stdint.h> (<cstdint> since C++11), etc instead of relying on platform-dependent short and long.

Potatoswatter
  • 134,909
  • 25
  • 265
  • 421
0

Yes, short is equivalent to short int, and it uses at least 2 bytes, but if you stay in the range you can replace int with short without any problem.

user2302436
  • 518
  • 2
  • 9
-1

Yes, you can use it. short = short int. Signed -32768 to 32767 and unsigned 0 to 65535 .

Zs.Zs.
  • 63
  • 1
  • 1
  • 6
-2

short can at max be two bytes long. On machines where int is two bytes, short and int have same range i.e. -32767 to +32767. For most of the new platforms, int is 4 bytes, catering to much larger range of values.

I recommend to go for explicit declaration such as int16_t for short and int32_t for int to avoid any confusion.

Amit
  • 677
  • 8
  • 15
  • `short` can be more than two bytes long. `int` just has to be at least as long as `short`. – juanchopanza Jun 01 '13 at 08:34
  • @juanchopanza I have never come across more than two byte short, any reference would help. I agree with second part (int at least as long as short), and my answer also says something similar. – Amit Jun 01 '13 at 13:01
  • It even could be one byte. Has to be two octets, though, and bytes usually are octets. – MSalters Jun 02 '13 at 23:35
-2

Also notice that for the following code:

short a = 32767;
a++;
cout << a;

It will print -32768.

So, if you go over its limit, it will "go back" with the counting.

Vlad Tarniceru
  • 711
  • 1
  • 8
  • 15
  • This is technically undefined behavior. – Dietrich Epp Jun 01 '13 at 08:22
  • 1
    If you overflow a 16-bit signed integer, the behaviour is undefined. What you show is the most common result; it is not in any sense a guaranteed result. – Jonathan Leffler Jun 01 '13 at 08:23
  • @JonathanLeffler: Of course it doesn't, I just wanted to show him that he doesn't get any error (like **killed by signal** for example). – Vlad Tarniceru Jun 01 '13 at 08:24
  • There's no guarantee that there won't be an error; the compiler could arrange to reformat your disk. It probably won't, but undefined behaviour is undefined; anything could happen. – Jonathan Leffler Jun 01 '13 at 08:25
  • Note that if `sizeof(short) – Marc Glisse Jun 01 '13 at 08:33
  • 1
    @Vlad Pretty bad things can happen if you try to exploit undefined behaviour, even in the case of signed integer overflow: http://stackoverflow.com/questions/7682477/why-does-integer-overflow-on-x86-with-gcc-cause-an-infinite-loop – jogojapan Jun 01 '13 at 09:09