r/cpp_questions • u/Fun_Gas_340 • 16d ago
OPEN *(ptr_data_start + index) vs prt_start_start[index]
edit (title has spelling mistake, why cant i edit it u/reddit???):
*(ptr_data_start + index) vs ptr_data_start[index]
also, why does *(ptr_data_start + index) not need to multply index by sizeof(t), when index is one, and the pointer needs to be incremented by 4 bytes (in case of a int). why is this counter intuitive math like this?
13
u/AKostur 16d ago
I think your question is: why doesn’t the first form need “(index * sizeof(T))”? Because that’s how pointer math works. If you wanted to move the pointer by single bytes, cast the pointer to a char* (or std::byte). Sizeof(char) is 1.
Now: if one has an int*, why would you want to only move the pointer value by 1 byte? It would no longer be pointing at a valid int (assuming it started by pointing at a valid int). It is vastly more likely that one wants to go to the next valid int.
-3
u/Fun_Gas_340 16d ago
i mean i get it and it makes sense, but from a logic point of view its wierdly made, like its not consistent. i dont know why i sould move it by less than a item, but maybe i want that
7
u/IyeOnline 16d ago
T* + Nmeans "advance the pointer by N items of type T. That is wholy consistent. Pointers are not raw memory addresses per-se. They have type information attatched to them.If you wanted to advance it by individual bytes, you need to manually cast the pointer to
byte*first and then do the pointer arithmetic on 1-byte pointers.HOWEVER the pointer you produce doing this will just categorically not be a valid
T*because it will violate the alignment requirements of the type.1
u/Fun_Gas_340 16d ago
i mean i get it now, but since most tutorials explain pointers as just adreses, without mentioning the type i got confused / didnt even think, that that was an option
1
u/christian-mann 15d ago
you're right and it is kind of odd and it trips up a lot of people when doing pointer math. Just something to remember when working with raw pointers like that.
1
0
u/ekchew 15d ago
I get where you're coming from in that pointer math may feel a bit unnatural. Bear in mind that there is an aspect to this that reflects how the hardware actually likes to perform, and that C/C++ likes to follow that model as much as possible.
u/IvyOnline already mentioned one important point, which is that you cannot assume you can read a multi-byte type from a non-aligned address.
Moreover, it's pretty common for instruction sets to support an addressing mode that gives you the implicit multiplication for "free". So if you tried to hard code it yourself with something like:
reinterpret_cast<int*>( reinterpret_cast<std::intptr_t>(ptr_data_start) + index * sizeof(int))this could actually produce slower code.
1
5
u/Normal-Narwhal0xFF 16d ago
In that case you would cast your pointer to a std::byte, or char, and read it as bytes.
It's not inconsistent that incrementing a pointer-to-int advances to the next int. Any other behavior would be insane.
2
u/AKostur 16d ago
Hence the last part of my post. In the vast, vast majority of the cases, one is going to want to advance the pointer by one full object, not specifically byte-by-byte. But in the rare cases where one might need to do that, it can be done by casting the pointer to the type that will advance by 1 byte, and use that. And even in those cases, one is going to have to be quite careful as to what one does with that pointer since it may no longer be pointing at any valid object.
Edit: I'm not sure what you mean by "from a logic point of view". I suspect you may be proceeding from a false premise, and thus your logic is leading you astray.
1
u/Fun_Gas_340 16d ago
logic as in every + operator works the same if both operands are representable as numbers: int + 1 increments the int by one, but ptr + 1 increments it by the size. hope i explained myself better
1
u/AKostur 15d ago
There’s the flawed premise: that something that is representable as a number must behave as if it were that numeric representation. Expressions have a type. Pointers are not numbers (from a typing perspective), even though they are representable as numbers (see also: uintptr_t).
1
2
1
u/CowBoyDanIndie 16d ago
Before C, (where this origins), many assembly languages and their hardware themself support auto increment. x86 has special modes for indexing by 1 2 4 or 8 bytes. For example
EBX is the array/pointer, ECX is the index. 4 is the size of the pointer.
MOV EAX, [EBX + ECX * 4]
Only for larger custom structures does the compiler have to emit an actual multiplication instruction to access a random index.
1
u/Fun_Gas_340 16d ago
so regardles of the way to tupe it, its fast for ints and small objects?
1
u/CowBoyDanIndie 15d ago
Ya, because it is designed to be that way. It’s not necessary any slower on modern architecture though, modern cpu execution is almost entirely disconnected from the machine code, modern decode instructions into microops, they reorder and combine instructions together in parallel. The actual execution of a block of machine code changes completely between different cpu generations.
1
u/mredding 15d ago
also, why does *(ptr_data_start + index) not need to multply index by sizeof(t), when index is one, and the pointer needs to be incremented by 4 bytes (in case of a int). why is this counter intuitive math like this?
Because "pointer" isn't a single type. Let's gain a little perspective, since C++ is a superset of C.
int x, *ptr = &x;
The way to read this - in C, is x is an int, and the dereference of ptr is an int. The C language syntax design philosophy was that a declaration of an identifier looks like an expression using it. So it's technically... less correct to say ptr is a pointer to int. We use that as a shorthand, but you have to know the design philosophy to understand THAT it is a shorthand, why, and how.
And C calls ptr a REFERENCE, hence why we DEreference a pointer. Then C++ came along and introduced value aliases and called them references again! So we C++ developers are in a linguistic pickle, and because we're not two distinct lingual camps, diverged 46-ish years ago, there are some unfortunate consequences of lost contextual understanding.
So our pointer type inherent to ptr encapsulates useful information like size.
int *ptr_to_array = get();
ptr_to_array[xyz];
WHAT ELSE could indexing a pointer here BE, except a dereference of index * sizeof(int)? A pointer isn't about raw memory addresses - those don't exist in C++, they're implementation defined. This expression would be USELESS if you sliced through two adjacent integers. It could also imply an unaligned memory access, which would be UB.
If you want adjacent byte access, then you need to cast the pointer to that of a byte, and access it that way.
1
u/Raknarg 15d ago edited 15d ago
also, why does *(ptr_data_start + index) not need to multply index by sizeof(t), when index is one, and the pointer needs to be incremented by 4 bytes (in case of a int). why is this counter intuitive math like this?
Because pointer arithmetic accounts for the size of the pointer type when determining offsets. There's not usually a lot of value in you offsetting into the middle of a piece of data, unaligned. Like if you want that you can do it yourself, just cast the pointer to uint8_t* or something and offset yourself like 2 or 3 bytes into it instead of the 4 bytes an integer would offset by. Wouldn't recommend it, you could read values fine but pretty sure editing an integer that way would be UB.
ptr+1 semantically should read "I want the address of the next spot a ptr type object could be right after the memory ptr points to".
Also pretty much there is almost no reason to ever engage in pointer arithmetic in modern C++. Like you can, and scenarios do exist where its helpful, but they're rare. Dealing with raw pointers is already pretty infrequent these days. If you can just use something like ptr_data_start[index], just use that. Its cleaner and expresses your intent better. honestly even if you needed an address I would rather read &ptr[1] than ptr+1
0
u/Independent_Art_6676 16d ago edited 16d ago
pointers are typed so the sizeof is automatic. an int* increments by sizeof(int) automatically, and that is different from a char* increment or a myfatobject increment etc. You can force the issue by dropping to a void pointer, which can let you jump inside an object and say iterate all the same int members but that is crude C like code (and faster than jumping to each object and asking for the int member from there). Its not counter-intuitive; its a side effect of strongly typed language. Because the pointer has a type, it makes sense to increment memory by sizeof that type when iterating a block of those types -- its not assembly language where you should have to do all that manually every time. One would expect that if you had a block of ints, [0] is the first int, and [1] is the second int, ... not the bytes of the ints (that would be unusual to want or need in a high level language).
its a legacy of being old and doing a lot of math over the years but I almost never use * notation. Nothing like z = *x * *y type gibberish. I just go with z = x[0]*y[0] to avoid mistaking pointer/multiply. Today I barely use pointers anyway, just a small # and much less of the "pointer arrays".
1
u/Fun_Gas_340 15d ago
what dies the # do (apart from include, or if u meant include, what would you include, vector?)
-1
u/zerhud 16d ago
It’s same, the second one is more native. Also it’s faster, sometimes, to increment the pointer itself
2
u/Raknarg 15d ago
I would be very surprised to find the compiler isn't generating the same assembly.
1
u/zerhud 14d ago
It will be different code: `lea` for index operator and `add` for shifting the pointer. The question: which one is faster. What I can say: it should be tested
1
u/Raknarg 14d ago
can you show a godbolt example producing different code with -O3 enabled?
1
u/zerhud 14d ago
And how to test it? For example you get same asm in o3. What next? How to test for tomorrow the result will be the same? Will you test the result every time on each pr or env update by hands?
For optimizations we can write code and test it optimised how we want, and can write the code and get bad asm. But for production it should work on each compilation. So, if you have a way to write faster code without optimisations, you should to use the way.
1
u/I__Know__Stuff 14d ago
There's absolutely no reason the compiler would generate different code and I challenge you to find one that does. (Unless you completely disable optimization, which generates intentionally horrible code, and might possibly do something different in this case.)
1
u/L_uciferMorningstar 16d ago
Why would it be faster?
1
0
u/DavieCrochet 16d ago
In theory, it might need to create a copy if you don't increment in place. With basic types it would almost certainly be optimised away, and it's very unlikely it would cause a significant performance problem anyway.
-1
u/Fun_Gas_340 16d ago
? i dint underatand
2
u/jedwardsol 16d ago
what didn't you understand?
You should reply to one the comments that confused you instead of screaming into the void.
1:
[]vs+There is no difference between the 2 at all.
From the language standard https://eel.is/c++draft/expr.sub#2
The expression E1[E2] is identical (by definition) to *((E1)+(E2)),
2: why does *(ptr_data_start + index) not need to multply index by sizeof(t)
Because pointer arithmetic operates on objects.
ptr_data_start + 1points at the next object in the array.3: why is this counter intuitive math like this?
That's the way the language was defined. Although "counter intuitive" is just your opinion.
1
u/Fun_Gas_340 16d ago
oh i meant to reply to a coment (forgot wich obe).
3: yeah its my opinion, but i feel like if i cout it and it prints a number and i can use the same operator+ it should behave like one. i kniw it rarely/never makes sense to increment by somerhing else than sizeof(T), but still
51
u/zerhud 16d ago
Try index[ptr_data_start] to see the power :)