Why would I use pointers if I'm on a 64 bit machine?

ok but isn't pass by reference essentially the same as copying a pointer over. Just different notation? On a 64 bit machine where pointers/passbyreference is 8 bytes, wouldnt it be more efficent to copy an adt of 2 bytes over?

fuck off faggot. go use java

Yes that is what I'm looking for. Which is faster? It would make a difference if I had billions of objects of my class (which I plan on doing).

A class of primitives shouldn't be a class, that's a pretty obvious code smell. You even mention passing these fields into other functions. Probably shouldn't be doing that.

>ok but isn't pass by reference essentially the same as copying a pointer over. Just different notation?
no. references have no overhead, you're basically passing the variable itself in, not a pointer to the variable

Yeah I can see that. That makes sense to me. But in general, assuming 1 thread, it would make the most sense to copy a 2 byte object instead of a pointer to the object (8 bytes) right?

do you want multiple copies of these 2 byte structures? Or just one?
if just one, passing a pointer I think will keep the CPU looking at a single cache entry

Why not? My primative is used to represent a chess move. It is 16 bits (4) bits for a piece code, 6 for for a coordinate the piece is moving from, and 6 for a coordinate the piece is moving to. I have a lot of functions pertaining to how to access moves. It would be a mess if it wasn't in a class.

Isn't there still overhead because you're passing something into the function's call frame, whether it's the memory address of the original variable, or a copy of the variable. Each frame is unique.

I'm not exactly sure yet. I assume multiple copies, but I am not entirely sure yet.

Primitives are almost always copied, from my limited experience. Pointers are most useful for pointing to structs or arrays of data which are infeasible to copy on every function call.

Also, if your function has to modify a memory region that a previous function call created, then you have no choice but to pass a pointer.

yes good point, where are we: heap or stack

>Isn't there still overhead because you're passing something into the function's call frame, whether it's the memory address of the original variable, or a copy of the variable. Each frame is unique.
depends on implementation, references will always have the least overhead though, but you should not be concerned with data size of the stuff you're storing on the stack like with function calls, it only matters when you have alot of data, stuff you would typically store on the heap

>I'm not exactly sure yet. I assume multiple copies, but I am not entirely sure yet.
to be a bit facetious, if you only need the one copy, you can write some of this in assembly and keep the two bytes in a register for the majority of the program.

I think this is this is the answer I was looking for

right now stack.

They aren't equivalent. If you want to be able to change the value once and have every function see the update, then you have to use a pointer.

If the value is immutable then sure, do what you want.

To modify something outside of function's scope.

I probably will need more than one, because I plan on having a class for a chessboard that contains the state of the board (which will be 32 bytes) and I want to link the different states of the board by moves (2 bytes).

If you REALLY want to bundle those three things together use a struct. However, I'd keep them separate. I understand where you're coming from, but this object is only used to transfer data. I'm almost certain that the functions access this objects' fields in disgusting ways, like move->piece, move->from, move->to, and because this object has no functionality of its' own, it has no business existing. All that really changes is the function signatures, instead of a move object they receive 3 primitives (or a struct).

You'd have a case if your chess thing was networked or accessed a database. To be honest it's just a nitpick on design, but it really does lead back to your performance question. If this was a struct, you wouldn't be asking this question.

Pass by reference. That's why.

data size only matters in big data structures. You have no reason to fret over byte size for shit like this. Only if you're storing large arrays of data

If I were to make it a struct, composed of 3 separate objects, wouldn't it be a lot larger (3 bytes vs 2). Also I do have a few extra functions, like isLegal to validate if the move is legally allowed in the game. I know this could be implemented in a struct, but I don't see the harm in aggregating 3 words into 1, especially if it gives each move a unique ID. If it was a struct I'd still be asking the question because a 3 byte struct < 8 byte pointer. But I see what your saying. It does make it slightly more complex.

>3 byte struct < 8 byte pointer
not really
when they're stored in memory they're aligned to the word size anyway
your 3 byte struct is essentially an 8 byte struct

>Why would I use pointers if I'm on a 64 bit machine?
Quite a few reasons:

You're using C and you want to return an error code as well as data. The typical way to do this is have the caller allocate some data for you to output to, then pass you a pointer to it, then use the normal return functionality for the error code.
The structure is large, passing it around would be expensive.
The structure is even larger/more persistent, so you need to use heap allocation, which is only accessible via pointers.
You're using C++ and you basically want a reference but you would like it to be nullable.
You're using C++ and you basically want a reference but you don't want it to be a massive pain in the ass that has to be initialized before the your class's constructor is even called.
You want to interface with low level systems/operating system features, for example all runtime dynamic library loading implementations I'm aware of use pointers.
You want to pass a function to be called later. (C++ has function references and std::function here).
You want to refer to some data without knowing anything about it's type.

Don't forget that you would have to copy the pointer itself. Plus there is the overhead inherent to indirection. If you don't need to mutate it at a shared location then it would not make sense to use a pointer in this case.

stackoverflow.com/questions/20272762/first-time-learning-assembly-is-this-saying-a-word-size-is-8-bytes
so according to this, x86 has the following:

1 byte = 8 bits
2 bytes = word
4 bytes = dword
8 bytes = qword

if the struct is 3 bytes then it would probably be stored as a dword.
If the class im using is 2 bytes then it would be stored as a word. So wouldn't it be more efficient to use the smaller one?

ok. makes sense to me

Any data is 16 byte aligned on x64: gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html
So it doesn't matter. Also, CPUs will need the same time to copy a 2 byte variable than a 8 byte variable. It shouldn't matter. The only thing you might consider is proper alignment of primitives in you classes/structs because of the padding.

>So wouldn't it be more efficient to use the smaller one?
Intuitively yes. In terms of stack usage almost certainly. In terms of real world performance... maybe? Never guess, always measure, processors can behave in some rather unexpected ways.
The only test I've ever run on this sort of thing was static class vs. instance class in C++ (the difference being the passing of an extra 8 byte pointer for the "this" argument in the case of instance classes). I don't recall the exact performance difference, but it was in the thousandths of a percent.

>In terms of stack usage almost certainly
Scratch that, as pointed out the stack is 16 byte aligned on x86 (may not be the case on other platforms).

ok. so on the stack it's theoretically better. Heap it doesn't matter. Gotcha. Makes sense. So lets say I wanted to allocated a ton of moves on the heap. Since gnu says its 16 byte aligned, does that mean each move is now (16 bytes). vs 2 on the stack. Is there anyway I can check that? Like sizeof() or something?

I'm not sure what you mean by the first bit but the only alignment sizeof interacts with is structure member alignment, which often makes structure members bigger than they need to be in order to accelerate memory accesses.

This. Get it working, tested, and then profile it. A modern compiler will do all types of shit with optimisations turned on, and trying to be clever early on can even end up slowing things down.

This.
Only profiling can reveal what is fastest.

if you have a 64bit machine, copying a 64bit value is the most trivial operation on it...
you just grab a chunk of bits thats already an exast size of your registers.
Whenever youre fetching a 2 byte from the memory, most likely 8 byte instruction is used anyway.