А почему так инициализация Опции

[DASM]

CODE

struct lala
{
char *p;
}
....
lala la = {"the"};
*(la.p) = '1'; // access violation

Чего тут думают керниганы и примкнувшие, не понимаю. Ну вроде же initialyzer list, почему он не создает временный rw объект и не присваивает ему указатель, а вместо этого прямо в лоб на константный инициализатор ссыль кидает. Где в стандартах этого так называемого языка программирования глянуть?

[esaulenka]

Я дико извиняюсь, но почему обсуждение стандартной библиотеки языка си++ (наиболее базовых вещей из неё) - "откровенный офф" ?

"Откровенный офф" - это пара страниц обсуждения дурацкой опечатки у майкрософта.

А STL прямо вот очень рекомендую посмотреть. Умные люди понаделали велосипедов почти на все случаи жизни.

PS для статического создания массивов есть std::array, ему куча не нужна (но при этом у него нет push()/pop())
PPS в кишках std::vector НЕТУ двусвязного списка (и вообще списка нет). Это один сплошной массив. И да, этот массив создеётся в куче.

[Forger]

Я дико извиняюсь, но почему обсуждение стандартной библиотеки языка си++ (наиболее базовых вещей из неё) - "откровенный офф" ?

Эта тема вообще ни разу не про C++ и уж тем более про STL
Но тенденция "скатиться к этому" есть почему-то у каждой темы в этом разделе ...

"Откровенный офф" - это пара страниц обсуждения дурацкой опечатки у майкрософта.

Это не офф, это - пустой треп

А STL прямо вот очень рекомендую посмотреть. Умные люди понаделали велосипедов почти на все случаи жизни.

К сожалению, STL довольно толстая библиотека и, если и стоит ее использовать в конкретнтных встраиваемых приложениях, то как можно активнее.
Поэтому пока что у меня лично нет возможности совать ее во все проекты без исключения.
Другая причина - активное использование кучи.
Причем, опасения вызывает даже не сам факт использования кучи (если "правильно ее готовить", то ничего страшного в ней нет),
а то, что STL использует кучу неявно. Можно сказать, непредсказуемо. Поэтому без перегруженных new/delete уж никак не обойтись.
А еще хлеще, что наверняка придется перегружать еще и локальные new/delete ("локальные", это значит - предназначенные для конкретных классов, точный термин не помню).
Например, вместо фрагментируемой кучи использовать более безопасные "пулы" для конкретно взятых классов.
С этой точки зрения Ваша фраза "понаделали велосипедов" может звучать уже иначе

PS для статического создания массивов есть std::array, ему куча не нужна (но при этом у него нет push()/pop())

Это все понятно ))) Книжки читать умеем )
Но речь зашла именно про vector и почему у меня он так работал. Но к счастью разобрался. Короче, проехали

PPS в кишках std::vector НЕТУ двусвязного списка (и вообще списка нет). Это один сплошной массив. И да, этот массив создеётся в куче.

Некая "описательная" часть этого массива все равно требует места для хранения, а точнее хранится именно там в какой области объявили этот vector.
Например, для случая: std::vector <int> v = {0, 1, 2, 3, 4};
sizeof(v) = 12 байт (arm compiler v6)

А уже сами данные вектора хранятся в куче.
Именно это момент вызвал проблемы в моем случае.
Кстати, размер выделенных в куче данных может оказаться даже больше, чем было "запрошено". Таков функционал этого vector - выделяет с неким запасом.

Напомню причину: у меня в текущих и старых проектах куча имеет минимально возможный размер (вроде 8 байт) и в принципе не используется, т.к. не особо-то и нужна.
По-хорошему мне стоит "перегрузить" штатные malloc и free (их используют new/delete) на некие "заглушки-ловушки"...