Так наверно не процесс другой должен занять память, ведь память у каждого процесса своя, нет?
И если идет обращение к памяти, которая инициализирована, то никакой ошибки не будет, если конечно не говорить о многопоточности.
Или я что-то не так понимаю?

Это развитие темы не касается контейнерных классов. Мы поняли, что после vec.push_back() если блок памяти закончится, то операционка переместит весь вектор в другое место (хотя... тут есть сомнения, так как такие перемещения были бы дороги для компютера, может имелось введу какое-то хитрое перераспределение адресов? с другой стороны элементы в векторе хранятся последовательно, поэтому она перемещает весь вектор в другое более большое место). А к чему это приведёт и как операцианка отреагирует - это уже на совести разработчиков операционки, а не на совести разработчика прикладного ПО. Наша задача не допускать записи по уже недействительным адресам.

Было бы хорошо если всегда так. Но освобожденный блок памяти может опять распределиться (напр есть какое-то new после push_back). И запись может быть 100% легальной для ОС - ну записали куда-то нолик И кайф в том что происходит это редко, лишь когда растет пул вектора.

Xорошо, а какие решения этой проблемы?  Ну ясно можно всегда писать vec[ i ] (или итератор), но короткое имя не всегда возможно/желательно, да и доступ все-таки чуть медленнее.

Никак.
Все что в этой теме написано про память не соответствует действительности.
Подробно писать с телефона не могу... Может вечером.

Не стоит горевать о понимании которое так легко разрушить Каждый процесс имеет свое адресное пр-во, поэтому штатными средствами языка обратиться к памяти др процесса мы не можем. Другое дело что ОС совсем не обязан падать при обращении по калечному указателю. Адрес может находиться в распределенной странице, т.е. с точки зрения ОС все гуд  

Есть 2 утверждения
1) из одного процесса нет доступа к пр-ву др процесса
2) некорректные действия в рамках одного процесса не могут повлиять на др процессы 

Эти утверждения не равны и не тождественны, поэтому включать женскую логику не нужно 

А я повторюсь - моя программа (1 процесс) вызывала Critical Error у Word и иных программ (N-ные процессы).
Это утверждение.

А ваши два утверждения ложные. Точнее не полные. Поправлю.

1) По заверениям разработчиков Microsoft и основываясь только на их словах - ни один процесс не может получить доступ к пространству другого процесса, если не использует специальное API и/или способы обхода ихнего утверждения.
Пример: хуки/инжекты Dll/дебажное API Windows/ устаревшие функции.
 
2) Некорректные действия в рамках одного процесса не могут повлиять на другие процессы, если только они не используют общие источники данных, конфликтующие компоненты и/или  иные связывающие их сущности. Так же некорректная работа одного процесса может убить системные службы и/или ОС, которые необходимы для работы иных процессов.
Пример: буферы обменов, сокеты, работа с драйверами, неблокирующая работа с файлами, работа с пайпами, работа с Shared Memory, оконный менеджер Windows.

PS добавим к этому ещё и баги ОС, которые я не привожу. Ибо это именно ошибки
 

Я не специалист, из того что я знаю, могу сказать, что да, виртуальная память у каждого процесса своя, но это не значит, что он может записывать в любую нераспределённую память данные. Это действие вызывает фатальную ошибку (и трактуется как запись данных в чужое пространство) и закрытие программы (одна из причин SIGSEGV). Естественно, речь тут не идёт о законных методах вторжения в память, как инжект в Win32 API или ptrace.


Это и называется "в рамках одного процесса". Если процесс в явном виде использует различные типы IPC, то он уже не standalone.