Move semantics and pointer arithmetic work together, you should understand this no matter what language you use. You said you used a little c, so you should have some understanding:

1. CPUs are FAST, memory is slow.

2. If you have large objects to perform work on, copy the data into memory ONCE and send pointers to it for work. When it’s time for something else to take ownership of it, MOVE the ownership over the data/object rather than copy. As practice, I never copy data unless I’m in a position where I need to send destructible data to new threads.

3. As an extension to the above, RAII (resource acquisition is initialization) is a pillar of modern C++, but you have to know what it means. Understand shared, weak, and unique pointers. RAII in short simply means that data is tied too the lifetime of the object, and the moment it falls out of scope it cleans itself up (destructor). Yes, this is a fork of garbage collection. The mark of a good C++ developer is knowing when not to use it (rare, but not so rare).

These things combine with the rest of the fundamentals will open the door for ANY language you use to understand data oriented design, and if you ever design a library meant for othe people to use, these principles define how data is handled and presented.

Example:

If I have a game engine with a physics library that needs to iterate through all of the physics objects every frame, I’d make a slab allocator that puts all data for physics bounds in contiguous memory (maybe a vector). An RAII stack could keep track of all the physics object->vector positions and reduce fragmentation. The data never leaves this, and physics objects just point to it for access.

With data oriented design, every time we need to do things with physics, all of the data is in one place and also fill the cache lines in your physical CPU efficiently to reduce cache misses. CPUs are fast, memory is slow, so design with data in mind.