1

My IT teacher said that when space is allocated for a constant in C and C ++ only the STRICTLY necessary space is allocated: he said that if we store the value 12 in a constant, for example, only 4 bits of memory will be allocated. I believe this is not true, both because the memory is almost always divided into 8-bit "cells", and because when we declare a constant we also indicate its type, so we decide how much memory to dedicate to it. Any expert opinion?

PS: He was talking about constants declared with the const qualifier.

RobertS supports Monica Cellio
  • 14,524
  • 7
  • 33
  • 80
DarkoNaito_09
  • 71
  • 2
  • 12
  • 4
    Mostly BS in practice, yes; but I suppose an implementation could decide to optimize for storage if it wanted to. The opposite tends to be true; the compiler will align addresses on e.g. 4-byte boundaries if that's more efficient on the architecture you are compiling for. – tripleee Jan 23 '20 at 12:47
  • 1
    Ask your teacher for proof for his claim of "if we store the value 12 in a constant, for example, only 4 bits of memory will be allocated.". He won't be able to supply any because it's simply not true. It wouldn't even make any sense - if all constants were just mangled onto one spot with just enough bits to fit them, then it wouldn't just need to store their addresses wherever they're used (if they're not optimized away), but also their size. So you'd have store a constant (number) to store the size of another number, and then you'd have the same issue again there. So you save no memory. – Blaze Jan 23 '20 at 12:48
  • 4
    Frequently, _no_ memory will be allocated at all. Compilers will generally constant-fold constants into the expressions they are used in. – Max Langhof Jan 23 '20 at 12:50
  • "constants declared with the `const` qualifier" --> In C, the _object_ `a` can have a `const` qualifier like in `const unsigned char a = 42;`, yet the _constant_ 42 does not have a `const` qualifier. `a` is _not_ a constant here. – chux - Reinstate Monica Jan 23 '20 at 13:15
  • How isn't "a" a constant? – DarkoNaito_09 Jan 23 '20 at 13:29
  • @DarkoNaito_09 `a` is not a C _constant_ as it does not meet the definition of a _constant_. See [Defining constant in c with const keyword](https://stackoverflow.com/a/56919102/2410359) or C17/18 spec 6.4.4 Constants. – chux - Reinstate Monica Jan 23 '20 at 13:51
  • Note that `sizeof(12)==sizeof(int)`. – MSalters Jan 23 '20 at 15:33
  • Also consider `const int x = 12; const int *px = &x;`. According to your teacher x is 4 bit and then px points to half a byte? The only way to get a 4 bit integer is with fields in a struct: `struct Foo { uint8_t x : 4; uint8_t y : 4; }` will use 8 bit because x and y can be combined into a single uint8_t for storage. – Goswin von Brederlow Jan 23 '20 at 16:31

3 Answers3

5

Of course your IT teacher is wrong. The size depends on the type of the const value. But you must also remember that any objects can be removed by the optimizing compiler if the they are not needed.

0___________
  • 60,014
  • 4
  • 34
  • 74
3

both because the memory is almost always divided into 8-bit "cells"

That's data memory is usually in 8-bit cells.

With int x = 12 in C, the constant 12 is not specified to be store in memory as data. All that is required is the x takes on the value of 12 - somehow.

The 12 could be embedded as part of an instruction - possibly only a few bits.

Some instruction sets allow small values to be stored in a few bit of the emitted code and not memory thus using zero bytes of data memory.

This commonly happens with special values like 0. There is no 0 stored someplace taking up 8 bits of data as likely there is an instruction to simply "clear" x.

chux - Reinstate Monica
  • 143,097
  • 13
  • 135
  • 256
  • `x=0` in x86 assembly would be translated to `x = x^x`. (XOR) precisely so no constant is needed. This trick is so common that modern x86 CPU's actively recognize it. – MSalters Jan 23 '20 at 15:32
2

My IT teacher said that when space is allocated for a constant in C and C ++ only the STRICTLY necessary space is allocated: he said that if we store the value 12 in a constant, for example, only 4 bits of memory will be allocated.

If that's really what the instructor said then there is indeed no justification for it.

It makes no sense to me, both because the memory is almost always divided into 8-bit "cells", and because when we declare a constant we also indicate its type, so we decide how much memory to dedicate to it. Any expert opinion?

Neither the C nor the C++ language standard provides any justification for the claim, and in practice, it is not descriptive of of real-world implementations.

But really, the terms in which the claim is stated need to be challenged before we even get to that. In C, a "constant" is a literal numeric or null pointer value appearing in source code. The language implementation has free rein to combine constants algebraically, to encode them into instructions rather than data, and to perform other transformations that effectively mean that the constant does not correspond to any storage at all. Where constants do have a corresponding representation in runtime memory, that representation is indeed bound by the system architecture, and I do not know any current computer architecture that can address storage in units smaller than eight bits.

If we suppose, however, that instead of the instructor being flagrantly wrong, there was instead some kind of miscommunication, there is a way to describe storage consisting of fewer than eight bits: structure types can have members called "bit fields", which have integer type and a specified number of bits. Example:

struct example {
    unsigned int two_bits:2;
};

Bit fields are not themselves addressible -- you may not apply the address-of operator (&) to them -- and the language acknowledges that their storage is part of one or more anonymous "addressible storage units" that are typically larger, but the representation of each bit field member of a structure object is defined to consist of the specific number of bits declared for it.

RobertS supports Monica Cellio
  • 14,524
  • 7
  • 33
  • 80
John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • The problem is that the `struct` will not be 2 bit long, or even not 1 byte long https://godbolt.org/z/7d7M6A – 0___________ Jan 23 '20 at 13:31
  • 1
    @P__J__, of course *the struct* is longer than two bits. I never said otherwise. It is the bitfield member that is only two bits in size. Even if you just ignore the whole "addressible storage unit" thing, there is nothing particularly new or surprising about the size of a struct being greater than the combined sizes of its members. Anyway, the point of that part of the discussion is to raise a possibility of what the instructor might have been talking about without being totally wrong. – John Bollinger Jan 23 '20 at 15:57