Something strange with pointers | Sololearn: Learn to code for FREE!

+5

Something strange with pointers

Does the conversion from pointers to integers actually return the memory location in bytes? (In need of a professional C++ programmer) Here's the code that I made to properly show my idea: https://code.sololearn.com/ci8Fu9FD29v6/#cpp // I am using Udemy courses and haven't progressed C++ in Sololearn. So, don't take my profile stats seriously.

3/19/2020 7:26:31 PM

D3F4U1T

10 Answers

New Answer

+5

You are right, very well spotted! There is something interesting to note though: It's not really a "memory location". Your operating system (windows) makes your program believe that it has infinite memory, even though you probably only have 8 or 16 GB of it. If windows ever runs out of memory it will take memory from some inactive processes and move it to your hard drive, so the illusion can persist. Ideally your program doesn't notice all this shuffling of memory. Your OS achieves this by "virtualizing" addresses. Internally it keeps an address table, the "page table", which maps virtual addresses the OS invents to physical addresses in RAM. Your program only ever gets virtual addresses handed out by the OS, so the OS can mess about with physical memory as much as it wants and you are none the wiser. You can just pretend like you are dealing with real memory locations but the numbers don't mean much. However if you calculate a difference of pointers you get a result in bytes, that is for certain!

+4

Why should anything happen when pointer is converted to int or long? You should actually convert a pointer to an unsigned int(if sizeof(pointer) is 4 bytes or unsigned long long if sizeof (pointer) is 8 bytes if you convert to int or long then the value will rollover once the signed int / long limit is reached. subtracting two pointers (addresses) gives you no of elements If you do the same after converting to integers then you get total sizeof the array which is equal to total sz = no of element * sizeof(type) // type here is string you are calculating the block difference wrong diff = &strArray[NSTRINGS] - &strArray[0]; sure the last element is at strArray[NSTRINGS-1] because indexing is 0 based.

+3

When you use pointers they actually store the memory address of the variable they are pointing to, the location on ram where it is allocated some memory. This is what happens in iso c++ which is used here but in older c++ compilers it used to be random number, so im you convert a pointer ( here which is hexa ) it will become an equivalent number of that that hexadecimal, which in turn is some random number. Second thing here in the program you are prnting the size of string class which wont work as it's the size of the string not the strings stored in that class. The address the compile return is same unless you change the cide because by default the memory address randomisation is disabled kn windows and linux. To make it easier to allocate memory to your program even after million runs, that's why the memory address is always same it could be turned off by passing some arguments to compiler. Im not a pro but i deal pointers quite often so i said what i knew. There might be errors after all am a human lol

+3

D3F4U1T Yep. Physical memory has addresses, from 0 to 16.000.000.000 (ish) if you have 16 GB of RAM. You are not writing directly to that memory location but there is a "translation layer" in between. If you print your pointer numbers in C++ you will see that the numbers can become much bigger than 16.000.000.000 so obviously there must be something happening.

+3

I found it interesting that those 8 small strings, 3 - 5 bytes long, took 256 bytes of memory. That is 32 bytes each. Then I found this on Stack Overflow regarding the string object: https://stackoverflow.com/questions/3770781/why-is-sizeofstring-32 Quote: "In g++5.2 (in e.g. g++4.9, it is different) a string is basically defined as : class string {   char* bufferp;   size_t length;   union {     char local_buffer[16];     size_t capacity;   }; }; On an ordinary computer this adds up to 32 bytes (8+8+16)."

+2

Thanks @schindlabua, I think that you got exactly what I was talking about. Despite being unable to understand it clearly. This is my thought: I think that OS has some sort of mechanics that numbers the memory in bytes. Correct me if I am wrong, please.

+2

A 64 bit processor can address up to 2 ^ 64 - 1 bytes which is way larger than the physical memory that is installed.

+2

~ swim ~ . I am aware that I get 8 instead of 9 in terms of array cell count. Since it starts with 0 it can be compensated by adding one so there is no worry there. My worry was about those numbers which Schindlabua explained. Thanks for your help. :) Also the scheme that I wrote down as a comment explains that I was aware that the last cell was not counted.

+1

There is nothing like conversion from pointers to integers returns memory in bytes.In the program you just converted the two adresses(starting index i.e,0 and ending index i.e,8 )into integers and subtracted them.As,it is array and stores elements in continuous memory locations,difference between them must return the difference in number of bytes,it returned number of bytes.

+1

anuhya velagaturi, exactly. That was what happened there. The convertion from hexadecimals to integer changed nothing. They are the same but the type representation is different. So it was expected to return the same thing again. I guess I must learn how memory is numbered in hexadecimals. Since I am progressing with the udemy course I can't go deep into it. Memory is just a big topic itself. Accepting that they are just addresses is enough for me. Thanks for your explanation. ;)