But how does the Scheduler actually interrupt the application when it has full control? Is there a timer that interrupts the CPU every 10ms unless it is reset, triggering some Scheduler code?
On x86, you can set up a timer interrupt to trigger every so often.
Does the OS before launching a new thread set the CPU to operate in "user mode" limiting some instructions?
On x86, most os's will set the 'ring level' to 3, limiting some cpu commands (like loading the page table, 'hlt' ing the cpu, etc., making some io ports unavailable)
How does the application allocate memory without hazard, through the memory controller?
Generally, it sends a 'syscall' irq, where when the os recieves it, it maps some memory for the application, possibly adding a page table entry.
How can the OS restrict the application to its own address space, user mode, can't the application disable "user mode" itself?
On x86, the 'kernel' sets the process to ring level 3, limiting many commands. Restricting the address space is basically done by the kernel setting up a unique page table for the process itself before handing over control to the process.
www.osdev.net may have documentation that will help you out.
header guards (or pragma once) just make sure that the header file is read one time per tu (translation unit). so if a.cpp includes it, and b.cpp includes it, and you compile a.cpp and b.cpp separately, there will be 2 instances of 'LogicContainer logic'. Simplest solution is to put 'extern LogicContainer logic' in the header file, and define 'LogicContainer logic' in some .cpp that will be linked in.
You are putting copies of a particle object on the vector. This copy will be destructed within vector::erase(). If you have allocated pointers in the particle object itself, its up to you to delete them.