I think that "address-free" clearly applies only to "lock-free", and if something is not "address-free" then the point whether it can be used interprocess is kind of moot as it is most certainly not going to be mapped at the same address (if you consider numerically identical addresses in different spaces to be the same at all).
this implies that one can only use atomic integral types in shared memory, but not std::atomic<>, because the std::atomic<> template has a per-instance is_lock_free member. there is no standard-compliant way to test at compile- time if std::atomic<T> is lock-free.
i cannot find any reference in the standard, that std::atomic<T> is lockfree, if there is a lockfree integral atomic type of the same size, so one cannot write a metafunction to dispatch at compile time .... that's both correct and very annoying indeed -- for Boost.Atomic this property of course holds true and I can create a "type trait"-like class to perform the required mapping (maybe would have made sense for C++11 as well) -- this assumption also sounds reasonable enough that there may be justification for boost to offer such a type trait for atomics of the platform compiler.
i double-checked: atomic_is_lock_free: takes the argument `atomic-type', not `atomic-integral': this means it should also support atomic<T>. to me this sounds like atomic<T>::is_lock_free should have the same semantics, althought it is not mentioned anywhere ... tim