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

[OKTA]

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

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

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

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

Думаю, опять же правильнее оговориться, что не в любую нераспределенную память, а в "свою" нераспределенную память. И опять же, запись в нераспределенную память не обязательно вылетит с ошибкой. Это, как говорится, undefined behaviour.

[Alex Custov]

Думаю, опять же правильнее оговориться, что не в любую нераспределенную память, а в "свою" нераспределенную память.

Опять же насколько я знаю у процесса есть своя память, которая распределена, и не своя, которая делится на общий userspace и kernel. Нет такой памяти как "своя нераспределённая".

И опять же, запись в нераспределенную память не обязательно вылетит с ошибкой. Это, как говорится, undefined behaviour.

Это уже ошибка доступа к памяти в классической схеме защиты доступа к памяти, которая регулируется ядром, см. например https://ru.wikipedia.org/wiki/SIGSEGV

[OKTA]

Думаю, опять же правильнее оговориться, что не в любую нераспределенную память, а в "свою" нераспределенную память.

Опять же насколько я знаю у процесса есть своя память, которая распределена, и не своя, которая делится на общий userspace и kernel. Нет такой памяти как "своя нераспределённая".

И опять же, запись в нераспределенную память не обязательно вылетит с ошибкой. Это, как говорится, undefined behaviour.

Это уже ошибка доступа к памяти в классической схеме защиты доступа к памяти, которая регулируется ядром, см. например https://ru.wikipedia.org/wiki/SIGSEGV

Да, с нераспределенной видимо так, ошибся.
Да, ошибка сегментации, но например здесь опять же этой ошибки нет

Код:

#include <iostream>
using namespace std;

int main() {
    float* tab = new float[3];

    cout << tab[7] << endl;
    tab[7] = 6.87;
    cout << tab[7] << endl;

    delete[] tab;
}

[Igors]

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

А я и не утверждал что они истинные. Но если Вам удалось завалить такого быка как Word - это ведь совсем не значит что Вы вторглись в его адресное пр-во ОС Вындоуз предоставляет богатейшие возможности задрочить систему (что Вы перечислили лишь малая толика). В сочетании с талантом разработчика это дает изумительные результаты  

[Alex Custov]

но например здесь опять же этой ошибки нет

ты же не знаешь наверняка, в свою память ты запишешь или нет, вот в чём фокус. Поэтому такой пример далеко не всегда упадёт. Слегка побив свою память, программа может запросто работать дальше, и упадёт только спустя некоторое время с SIGALARM на совершенно законной операции типа t = new T. Такие ошибки - это самый гемморой, особенно для виндоус пользователей, у которых нет valgrind.

[OKTA]

но например здесь опять же этой ошибки нет

ты же не знаешь наверняка, в свою память ты запишешь или нет, вот в чём фокус. Поэтому такой пример далеко не всегда упадёт. Слегка побив свою память, программа может запросто работать дальше, и упадёт только спустя некоторое время с SIGALARM на совершенно законной операции типа t = new T. Такие ошибки - это самый гемморой, особенно для виндоус пользователей, у которых нет valgrind.

Спасибо, понял 

[Bepec]

"Адресное пространство - одно. Попытка разделить его - лишь иллюзия." Цитата из какой то умной книги.

to Alex Custov - любой процесс, абсолютно любой использует общие ресурсы
Даже складывая 2+2 он обращается к менеджеру памяти, который... общий?

В общем делаю для себя вывод.
Завалить любой другой процесс - можно. ОС пытается этому помешать, но как заметил Igors  имеются богатейшие возможности. Ещё прибавим сюда любознательного программиста, который пишет не понимая части выполняемых им самим действий и вуаля

PS эт да, потерянные указатели на Windows - зло.

[Igors]

Да, ошибка сегментации, но например здесь опять же этой ошибки нет

ОС распределяет память страницами (обычно 4K). Обращение по любому адресу внутри страницы валидно для OC

[Alex Custov]

to Alex Custov - любой процесс, абсолютно любой использует общие ресурсы

он использует только то, что ему разрешили, при этом контролируя его действия. Конечно, можно уронить сервер, если у него есть ошибка переполнения буфера, но без прямой работы с его памятью, ибо это невозможно.

[OKTA]

Да, ошибка сегментации, но например здесь опять же этой ошибки нет

ОС распределяет память страницами (обычно 4K). Обращение по любому адресу внутри страницы валидно для OC

Логично черт возьми! 

[Igors]

Отклонились от темы (впрочем вполне в рамках). Не хочется быть навязчивым, но все же

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

Ну конечно речь идет не о "победе над битыми указателями", но в данном конкретном случае с вектором часто есть дешевое и хорошее решение (пусть и не очень популярное в широких кругах). Еще подсказка: оно полностью соответствует данной теме

[OKTA]

Отклонились от темы (впрочем вполне в рамках). Не хочется быть навязчивым, но все же

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

Ну конечно речь идет не о "победе над битыми указателями", но в данном конкретном случае с вектором часто есть дешевое и хорошее решение (пусть и не очень популярное в широких кругах). Еще подсказка: оно полностью соответствует данной теме

Igors, не обижайся, но ты всегда как-то дико формулируешь задачки и правило "в правильно заданном вопросе уже половина ответа" здесь не уместно  Ну или я такой чугунный 

[Igors]

Igors, не обижайся, но ты всегда как-то дико формулируешь задачки и правило "в правильно заданном вопросе уже половина ответа" здесь не уместно   Ну или я такой чугунный  

Не обижаюсь, но как в том анекдоте "а жизнь какая?"   - ведь там Вам никто даже не намекнет что "решение есть". Так что нечего создавать тепличные условия, обильный хелп, видео-уроки - все это только разлагает.

Edit: а решение очень простое, правда

[OKTA]

Да я банально не понял на моменте с

Ну ясно можно всегда писать vec[ i ] (или итератор),

Это имелось ввиду, что вместо указателя сразу делать

Код:

vec.push_back(vec[i])

?
А теперь вопрос, как сделать тоже самое без

Код:

vec[i]

? Верно?)

[Igors]

А теперь вопрос, как сделать тоже самое без

Код:

vec[i]

? Верно?)

Верно, но слишком узко. Иногда надо смотреть ширше. Мы убедились что минус вектора - перемещаемость данных - сейчас элемент по одному адресу, а нарастили вектор - уже по другому, что может повести к тяжелым ошибкам. Конечно если будем работать только по индексу - все норм. Но это часто неудобно - адрес самодостаточен, а вот индекс нет. Как это порешать?