Контейнерные классы

[OKTA]

А вот что будет если мы запишем по адресу который уже занял другой процессе? Операционка же не позволит и выдаст сообщение? Завершит наш процесс?

да, процесс упадёт с фатальной ошибкой

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

[OKTA]

  куда все поховались 

[8Observer8]

куда все поховались  

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

[8Observer8]

А вот что будет если мы запишем по адресу который уже занял другой процессе? Операционка же не позволит и выдаст сообщение? Завершит наш процесс?

да, процесс упадёт с фатальной ошибкой

Не совсем правильно.
Операционка может просто сама упасть. Уже не раз в моей практике мои же программы опровергали "безопасть" работы с областями памяти разных процессов

Я склоняюсь в вашим версиям. Спасибо, парни!

[Igors]

Да... коварная ошибка. Если блока памяти не хватает для вектора (после добавления), то операционная система скопирует вектор в другую область памяти, где адреса будут другими, а мы запишем данные по старому адресу. А что будет в реальности после такой записи? Понятно, что программа не занулит элемент. А вот что будет если мы запишем по адресу который уже занял другой процессе? Операционка же не позволит и выдаст сообщение? Завершит наш процесс?

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

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

[OKTA]

А вот что будет если мы запишем по адресу который уже занял другой процессе? Операционка же не позволит и выдаст сообщение? Завершит наш процесс?

Вот такие вещи на мой взгляд рушат все понимание и спустя время взрывают мозг. Объясните тогда, как простыми средствами с++ обратиться в память, занятую другим процессом?

[Old]

Вот такие вещи на мой взгляд рушат все понимание и спустя время взрывают мозг. Объясните тогда, как простыми средствами с++ обратиться в память, занятую другим процессом?

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

[OKTA]

Вот такие вещи на мой взгляд рушат все понимание и спустя время взрывают мозг. Объясните тогда, как простыми средствами с++ обратиться в память, занятую другим процессом?

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

Этого ответа я и ждал 

[Igors]

А вот что будет если мы запишем по адресу который уже занял другой процессе? Операционка же не позволит и выдаст сообщение? Завершит наш процесс?

Вот такие вещи на мой взгляд рушат все понимание и спустя время взрывают мозг. Объясните тогда, как простыми средствами с++ обратиться в память, занятую другим процессом?

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

[Bepec]

Есть много тем, в которых обсасывается тема "адресное пространство у каждого процесса своё" и "доступ в память другого процесса не может быть совершен штатными средствами". Я им верил до той поры, пока моя  программка (обработка больших массивов данных) не начала рушить запущенные программы. Особенно страдала линейка Word.
Пара программ вызывала BSOD'ы, причём проблема была просто в использовании "потерянных" указателей.

Это моё мнение, конечно. Оно не имеет жестких обоснований и авторитетных заявлений, но "оно работает, но неправильно работает!".

PS ещё забавный случай - программка для посыла и разбора кадров по корпоративному протоколу рандомно вызывала BSOD при частом приёме. Даже соревнование устроили, у кого упадёт быстрее.

[Igors]

Есть много тем, в которых обсасывается тема "адресное пространство у каждого процесса своё" и "доступ в память другого процесса не может быть совершен штатными средствами". Я им верил до той поры, пока моя  программка (обработка больших массивов данных) не начала рушить запущенные программы. Особенно страдала линейка Word.

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

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

[OKTA]

Есть много тем, в которых обсасывается тема "адресное пространство у каждого процесса своё" и "доступ в память другого процесса не может быть совершен штатными средствами". Я им верил до той поры, пока моя  программка (обработка больших массивов данных) не начала рушить запущенные программы. Особенно страдала линейка Word.

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

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

Очень хорошо сказано.

[Bepec]

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

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

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

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

[OKTA]

Ну так это еще раз подтверждает, что для убийства других процессов, далеко не обязательно вмешиваться в их память  

А невозможность влезть в другой процесс без использования специальных средств  - это простейшее обеспечение надежности и безопасности - без этого ни одна операционная система нормально бы не функционировала)

У вас Верес что-то видимо косвенно влияло на Word)
Вот, если интересно, забавное поведение с выделением и освобождением памяти) http://habrahabr.ru/post/158347/

[Alex Custov]

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

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

если только они не используют общие источники данных

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