d.set(10);//d only contains an integer that is initialized to be 0, a setter and a getter
t.start(); //t is a thread object which knows d; upon starting it will get the value of the integer from d and print it.
A legitimate output for this code is 0. That is, the thread t does not "see" the change to the state of d (set to 10) performed in the main thread of the program.
Why is that? Won't d.set() be finished before t.start(), because it's an atomic action? I can see no reason why won't the update be known to t. It's not a context switch kind of thing, as if the change will only occur after the main will be over... If we add a 10-seconds sleep period after t.start for the main thread to rest, it still prints out 10. How can it ever print 0?
Illustrated in the link above is an object BAR's vtable, in case the original, parent object FOO had a method m() which we've overridden.
So bar.m() will run the overridden method we implemented in bar,
but we can still access the old method if we'll do something like bar::f::m(); (maybe the syntax is incorrect - I'm on Windows now and can't check it. However I'm sure that from inside BAR we can access foo::m() easily. Ignore the case sensitivities please).
In the illustration, foo's original m()'s address is nowhere to be seen... Where is it? On the top of the vtable? Or in the bottom, underneath BAR's virtual methods?