Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I'm currently reading through Crash Course C++ and have a question regarding types.
If I declare and initialize both an int and a long long variable on a 64-bit machine running Linux to the decimal value 4, does the compiler recognize the wasted bytes and make changes to the underlying type? This is probably a no, as at some point that field may take on a value that would cause overflow with a smaller type (i.e. going from 8 bytes to 4).
I've read a little about object byte reordering during compilation in c++; that compilers can sometimes rearrange fields to minimize padding in memory. Just wondering if there is a similar optimization that happens for numeric types.
I do not think that the compiler will change the size of a variable. It might do so because of the as if rule, but if it can reliably do that, it means that the variable is used is a very simple context, for example assigned (or initialized) once from a constant and then only used in the same compilation unit and its address is not used (that last point if often said odr-usage for One Definition Rule).
But in that case, the compiler will simply optimize out the variable because it can directly use its value, so it will use no memory at all...
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
Does declaring a variable after a buffer in a function make its memory area inaccessible by the buffer? Because I tried doing that and every time I compile the program the buffer can still access it. First address of the buffer is always the lowest possible address of the stack frame.
Does it have to do with the compiler? I'm using gcc.
int check_authentication(char *password){
int demovar;
char password_buffer[16];
int auth_flag;
strcpy(password_buffer,password);
if(strcmp(password_buffer,"brilling")==0)auth_flag=1;
if(strcmp(password_buffer,"outgrabe")==0)auth_flag=1;
return auth_flag;
}
First:
The C standard does not tell anything about the location of your variables. The C standard doesn't even say that they are on a (call) stack. So your variables can be anywhere in memory (or they can not even be in memory).
A stack is an implementation specific thing that is never ever mentioned by the standard. Most (if not all) implementations use a stack but still there is no way to tell from the C code how variables will be located on the stack. It's an implementation thing - it's decided by your compiler.
Second:
C has no overflow protection what so ever. If you copy more into password_buffer than it can hold (16 char in this example), C will not warn you. It's called Undefined Behavior. It means that anything may happen. Maybe your program crash. Maybe it overwrites another variable. Maybe ... whatever. But nothing in C will help you. It's your responsebility to make sure such things doesn't happen.
It's kind of how C works. The programmer is responsible for doing things correctly. There is almost no help in C. The benefit is that there is almost no overhead in C. You win some, you lose some...
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
Consider the following example:
Foo foo;
int main()
{
//...
}
What would happen if the size of Foo is too big and allocation fails? Consider a small device with limited memory. Also, what difference would it make if Foo is instantiated within main function?
What would happen if the size of Foo is too big and allocation fails?
The language doesn't specify what would happen. This is what the standard says:
[implimits]
Because computers are finite, C++ implementations are inevitably limited in the size of the programs they can successfully process.
Every implementation shall document those limitations where known.
This documentation may cite fixed limits where they exist, say how to compute variable limits as a function of available resources, or say that fixed limits do not exist or are unknown.
The limits may constrain quantities that include those described below or others.
The bracketed number following each quantity is recommended as the minimum for that quantity. However, these quantities are only guidelines and do not determine compliance.
...
Size of an object ([intro.object]) [262 144].
The behaviour may vary across language implementations. You can try it out to discover what happens on your target system. Here is a demo where the operating system raises a segfault: https://godbolt.org/z/PjnfbW
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Is a C compiler obligated to place a static const variable in memory or is it allowed to use it as immediate instruction operand when referenced?
No, it isn't as long as you do not tell it to otherwise. It can very well use the constant as literal (immediate) values in assembler instructions.
Telling otherwise could be
declaring the const volatile (Telling the compiler: "We don't change it, but somebody else could")
declaring and/or using i.e. dereferencing a pointer to the constwhich is not explicitely const
A C compiler isn't obligated to put anything in memory. Even a non-static non-const variable could be entirely optimised out, as long as the compiler & linker could prove that the object were not to be referenced externally (or that its address is requested internally, e.g. using the & operator) and that its value did not depend on any unpredictable circumstances (such as user input).
A modern C or C++ compiler performs such optimisations aggressively, which is why the typical low-level "this is how your program works" explanations that come from the poorer introductory textbooks are misleading, and why we discuss the semantics of these languages in theoretical/abstract terms, rather than obsessing over which bits of data are on which chip of RAM when the user hits a button.
For reference on how this optimisation is permitted, look up the "as-if" rule.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Are there some low level features of C++ that are growing extinct because of the increasing availability of computer resources like memory, disk space, CPU power etc?
Not per-se a C++ feature (it's common to C), but the register specification doesn't do much any more. This used to be a recommendation for the compiler to generate instructions to place some variable in a register, but it's not really useful anymore. When I learned C, the chapter on loops used to be full of
for(register int i ...)
Compilers develop, but the language as such is likely to stay the same (at least old language standards will remain), because otherwise, old code will break.
The inline keyword is no longer meaning "inline this function", but has some semantics based on multiple declarations of the same function in the final binary (there will only be ONE function, rather than multiple functions).
This is an effect of compiler being more clever as to when to inline (most modern compilers will for example inline any function that is static and called only once, regardless of size)
Obviusly, with more hardware resources, the solution may change - if you can write something in Python and it's reasonably speedy, why write it in C or C++? 20 years ago, that project may not even have been possible with hand-written assembler...
Bitfields are often pointless nowadays. They typically save only a few bytes per object, but accessing them is slower. So if you're not running out of memory, your program is probably faster without them. (They make a lot of sense when they can prevent your program from swapping to disk; disk is 100x slower than RAM)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I can't seem to find anything regarding whether or not this is possible. Ideally I'd have someone input an integer like "4" and then it would make a 4-d array.
is this at all possible?
As explained in the Stack Overflow post, "Create an N dimensional array, where N is determined at runtime (C++)":
The dimensions of an array are part of the type, and the type must be known
at compile time.
Thus the programmer must specify the dimensions of the array before compile-time, not during run-time.
Type checking is typically one of the first operations a compiler does (it is specifically found in the semantic analysis portion of the compiler's control flow) to ensure the code received is free of simple programming errors (assignment/equivilance errors, etc).
Please let me know if you have any questions!