0

I've read the answers to the question of why sizeof(long long) is 8 on most systems, but I'm still not sure how to interpret the meaning of them.

One of the reasons given is that there is a lot of code 'out there' which assumes that sizeof(long long) <= sizeof(size_t). That makes sense. Then there are all kinds of views on architecture conventions and brands, etc. I don't even want to get into those debates about the history of the convention. There are also reasons given that long long can be any size according to standard, but I think that is not really what concerns me.

What I want to know is how to interpret the difference now between the fact that sizeof(long long) returns 8 but that a long long actually is 16. Should it be interpreted as a historical remnant that applies only to the sizeof operator, or is there an underlying address pointer associated with that fact, so that operations on a long long are executed in 8 byte increments?

Sizeof (signed) long v4: 8 Value of (x at 2147483647)v4: 7fffffff

Sizeof long long v5: 8 Value of (x at 9223372036854775807)v5: 7fffffffffffffff

Denilson Amorim
  • 9,642
  • 6
  • 27
  • 31
Mark Leavenworth
  • 61
  • 2
  • 12
  • 1
    How is a `long long` supposed to be 16 bytes? `long long` should be a 64 bit type and as such it should be of size 8 bytes. check this out: http://en.cppreference.com/w/cpp/language/types – NathanOliver May 12 '15 at 17:51
  • I added clarifying information. – Mark Leavenworth May 12 '15 at 18:00
  • 1
    still don't understand where the 16 comes from – user3528438 May 12 '15 at 18:02
  • I was counting each 'nibble' as a 'byte'. My question should be why long returns 8 but only hold 4bytes. – Mark Leavenworth May 12 '15 at 18:16
  • The original question was if a long long is treated as a unit by the processor, or not. Apparently it is, to the point that even a long is given 8bytes, though it only uses 4. That is a different question, though. Thank you for your help with the original question. – Mark Leavenworth May 12 '15 at 18:57
  • I've read both questions you posted and I am still confused of what you are asking. – Thomas Matthews May 12 '15 at 21:44
  • I was confused about what question I was asking as well, Thomas, which is the reason for my asking a question. The question turns out to be whether we ought to anticipate the elimination of the 4byte long, or not. – Mark Leavenworth May 12 '15 at 22:08

4 Answers4

4

According to the standard, long long is at least 64 bits, or say, 8 bytes.

On most machines today, it is 8 bytes long. sizeof (BTW, an operator, not a function) returns its size, you can count on it. There's no way sizeof(long long) is 8 while the size of long long is 16.

Yu Hao
  • 119,891
  • 44
  • 235
  • 294
1

The longest standard data type is 8 bytes (64 bits) on most of the systems, Which is long long.

In addition you can include limits.h which library contains defined values for each data type and the space it occupies on your system.

A slight update during the fact I've encountered some level of interest over long. It is guaranteed to be at least 32 bits (or 4 bytes) long. So as long int (though in that case, long is rather a length modifier).

Imobilis
  • 1,475
  • 8
  • 29
  • 1
    `long long` is very rarely (if ever) 4 bytes, even on 32bit systems. `long` varies greatly though. – mtijanic May 12 '15 at 17:55
  • Yes. I thought `might` in english means.. very unlikely and is less likely than "may". Though I had a dos pc and `long long` was 32 bits. x32 bit arch pc with x32 bit hardware – Imobilis May 12 '15 at 17:59
  • 3
    the standard now gauntness a long long to be a minimum of 64 bits. See C++11/C11 standard 5.2.4.2.1. `maximum value for an object of type unsigned long long int ULLONG_MAX 18446744073709551615 // 2^64 − 1` – NathanOliver May 12 '15 at 18:01
  • Again, what if `char` is not 8 bits? – user3528438 May 12 '15 at 18:12
  • Okay. I will drop the idea of it to be 4 bytes. Not useful enough. – Imobilis May 12 '15 at 18:12
  • @user3528438 `sizeof(char)` is guaranteed to be 1. see 5.3.3.1 of the C++11 standard. everything else dealing with sizes is based of of that. – NathanOliver May 12 '15 at 19:38
  • @NathanOliver then, if `long long` is 64bit and `char` is 16bit then what's the `sizeof(long long)`? – user3528438 May 12 '15 at 20:19
  • 1
    @user3528438 A `long long` is guaranteed to be at least 64 bits. It can be more. – NathanOliver May 12 '15 at 20:22
  • In "The longest standard data type is guaranteed to be 8 bytes (64 bits) on most of the systems", drop "guaranteed to be". – chux - Reinstate Monica May 13 '15 at 03:22
1

Somewhere there is a confusion and I am not sure where it is, because you don't say where you get your numbers from, so I will try to clarify the basics.

sizeof returns by definition the number of bytes a type occupies. On all modern systems a byte is composed of 8 bits, but on some esoteric or old architectures a byte has other number of bits. CHAR_BIT from limits.h tells you how many bits there are in a byte. But again, on all modern architectures that's 8.

sizeof(long long) returns 8 but that a long long actually is 16.

That is not true. If sizoef(long long) is 8 then long long is 8 bytes long.

The follow-up question would be why sizeof(long) returns 8, but only holds 4bytes.

Again, not true. If sizeof (long) is 8 then long holds 8 bytes.

The question turns out to be whether we ought to anticipate the elimination of the 4byte long, or not.

Not a chance in hell. One of the pillars of C and C++ is backwards compatibility. Removing a fundamental type would break practically every program on the planet.

If you ask if there is any use of the type long when int and long long seem to cover everything then again the answer is int and long long don't cover everything. There are system like e.g. arduino where sizeof int == 2, sizeof long == 4 and sizeof long long == 8.

bolov
  • 72,283
  • 15
  • 145
  • 224
  • I was using a 64 bit hardware computer with 32 bit software at the time, when Apple switched from 32 to 64 bit. My software was in the process of updating. – Mark Leavenworth Dec 18 '21 at 05:50
  • Point granted. I apologize. My American hyperbole has caused unintended offense to my friends. – Mark Leavenworth Dec 18 '21 at 06:11
  • @MarkLeavenworth apology accepted, although that was not my intention. I wanted to know how I have offended you. – bolov Dec 18 '21 at 06:14
  • 1
    @MarkLeavenworth oh, I didn't even realized it's an old question. I just saw it on the main page feed. – bolov Dec 18 '21 at 06:15
  • I deeply and sincerely apologize. My comment was directed at the diabolic self-appointed 'leaders' of this forum, and not at you or your comment. I appreciate your efforts to help myself and others. – Mark Leavenworth Dec 18 '21 at 06:17
0

The problem was that part of your system had been switched over to 64 bit and part of your system was still operating as 32 bit.

Mark Leavenworth
  • 61
  • 2
  • 12