Why, when declaring a variable, in any programming language, is the entire memory size allocated for the data type reserved?

Question

Programming languages

Why is it that when declaring a variable in any programming language, the entire memory size allocated for the data type is reserved, and not just the one that the data actually occupies inside
?
on sale there are only 64GB and above, as if the same. Is
this somehow facilitated by the restrictions imposed on the stack and hip?

Answer 1

The SSD example is incorrect, it's the same as demanding from KAMAZ, for example, to release a truck with a load capacity of 20 kg. The manufacturer needs a market.
However, small memory chips exist, only no one writes on them that they are "SSD".
Memory allocation is not a free operation, and someone decided that it would be more profitable this way.
https://randomascii.wordpress.com/2014/12/10/hidde...
https://habr.com/ru/post/270009/

Somehow everything is clumsily arranged

You can write your own memory managers, compilers and other related stuff. It is possible that you will gain worldwide fame. But do not think that no one has tried before you.

Answer 2

If I just declared a variable of type short, then how much memory should be allocated for it? What if you put zero in it? And if after that I wrote 65535 into it? And where to store the amount of memory allocated for a variable? And how to re-allocate memory if it is allocated on the stack?
PS And how do you imagine an array with access by index, if each element of the array has its own size?

Answer 3

Question from the category "Why are there 8 bits in a byte?".
A variable declaration is just a request for memory allocation. If you need to allocate less memory, you can use a type with a smaller size - bytes, bits. And an example of dynamically growing memory structures can be some vector from C ++. What is the disadvantage - overhead. If a contiguous area of ​​memory is not available when expanding a classic array, you will need to copy the entire structure to another area of ​​memory. It is much faster and more economical in terms of speed to immediately allocate a large amount of memory, since it is now not in short supply on a PC.

Answer 4

I can be wrong, but all this results from the architecture of the computer.
Memory has a physical dimension, the processor works with strictly defined blocks of data.
In order to make a variable floating in volume, it is necessary to spend resources on its control.
With millions of variables, a lot of resources will be spent on controlling such changes.

Answer 5

Memory for a variable in C++ (for example) is allocated in accordance with the data type and a specific size for the speed of programs, so that the computer during program execution does not have to constantly recalculate and reallocate memory for many thousands of variables, the content and size of which is constantly changing within the type.
And it has nothing to do with the size of the SSD.
And what then is the point in data types, if the memory for them will be allocated strictly according to the size of the content? That's what data types are for.

Answer 6

1. And why did you decide that something obliges or imposes a restriction? With your imagination, everything is possible. Make a type from an array of bits, make logic that will expand it as needed, narrow it according to certain conditions ... Profit.
2. For example - why do you live in a living space that is larger than you take up space? Let everyone make boxes according to their height and width, and when they get better, lose weight or have children, they will rebuild according to their needs. Built-up houses are not at all optimal in terms of the space occupied.

Answer 7

Why is it that when declaring a variable in any programming language, the entire amount of memory allocated for the data type is reserved, and not just the amount that the data inside actually occupies

There are two questions at once:
1. Why did you decide to reserve the entire size?
2. How to determine how much data is really taking up?
On the first point - there are dynamic data types like lists, vectors, trees, etc. They usually take up as much space as they need + overhead.
On the second - here I created structure from integers. I need somewhere else to get a bitmask in order to know which fields are already in use. And with each access to the field, you must first subtract the mask, calculate the offset from the beginning of the structure, and only then read the field. And if I write in a field that has not been used before, then I need to allocate a new piece of memory, place the old fields there, and only then add new ones. And then update all pointers to this structure. Can you imagine how much extra work for the processor?
The same for primitive types - instead of a fixed number of bits, I have to separately store the length of the number and then the number itself. When I try to write a larger number to a variable, I will be forced to look for a new piece of memory. By the way, in fact, such a thing is implemented, called BigInt. But its scope is rather narrow...
In general, try to put yourself in the place of a compiler (or processor) developer and figure out how you would store such data of variable length in memory. How would you deal with increasing (and decreasing) sizes, etc. Try to just draw a piece of memory on a piece of paper and play with write and read operations.
By the way, in fact, memory is not always allocated for a variable. Modern compilers are smart enough to keep most local variables in registers without touching the stack and/or heap at all.

Answer 8

Firstly, not in any programming language. In particular, in languages ​​with dynamic typing, this is more likely not the case than it is.
Secondly - by no means for all data types. True for base/primitive types. But for complex types (such as trees, vectors, etc.) this is no longer the case.
In fact, there is even more memory - some goes to the reservation.
In fact, less data can be written there - some goes to write auxiliary structures of the file system (file distribution table, directory, etc., etc.)

Answer 9

Zakkmalin ,

Well, that it cannot be dynamic, why store and transfer 2 billion, if we say a prime number 1 inside the variable?

that is, all the same, it is necessary to explain ...
To begin with: There is a dimension of registers that accept variables in the size of the bit depth of the register, and in general it is faster and more convenient to store a variable in the size of the bit depth of the register. Anything less requires an overhead for processing "extra" space, anything more requires splitting into several register variables (this is obvious for people who have worked with asm). Basically, data types are a trade-off between losing speed and saving memory space.
Further, to the issue of dynamically changing variable sizes - any allocation is a wild overhead of 3 or more operations, and since the data in the heap goes in a row, it will not be possible to expand the variable size without allocation. To this add heap fragmentation, which also seriously adds brakes.
There are a lot of different nuances, but these are the main arguments.