Бог ты мой, да в C те же проблемы. Если, скажем, внутри одной структуры определяются указатели на какие-то значения этой структуры, то беды при realloc не избежать:


И ещё пример. Здесь просто запомнили указатель на какой-то элемент списка, а потом сделали realloc:



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

что измениться есть вместо operator = будет метод Сlone ?
а  operator = будет private , для верности , а на С = просто не вызывать, 
да писать так не очень удобно , но компайлеру то какая разница ,?



Это сообщение отредактировал(а) sergioK1 - 7.3.2012, 17:49

C отличается от С++ тем, что на тебе лежит больше обязанностей по контролю правильности.

Изменится то, что стандартные методы работать с таким классом не будут. Зачем усложнять себе жизнь?

Или писать свой  wrapper realloc он же Clone и копировать указатели/ссылки , или не копировать , в зависимости от задачи, 
в С++ это копи конструктор ,  но это  не значит что realloc это плохо,  

в случае с vector возникают  теже самые проблемы , 


feodorv - спасибо прояснил ситуацию , 
Вопрос решен 




Это сообщение отредактировал(а) sergioK1 - 8.3.2012, 00:14

Разница в том, что operator= будет вызываться автоматически компилятором (там, где надо), а Clone вам придется звать вручную. При этом запросто можно забыть и не позвать этот самый Clone (человеку свойственно ошибаться). А вот компилятор не ошибается. Ну и в конце концов у вас может и не быть возможности этот самый Clone позвать (как уже упоминал bsa, например при использовании stl контейнеров)

PS. В 99% реализации realloc внутри сделает free и malloc если его попросят увеличить выделенный блок, так что его использование не дает никаких преимуществ

На чем это утверждение основано ?  
мне как в суде аргуметы нужны и факты   , 

Это сообщение отредактировал(а) sergioK1 - 8.3.2012, 10:42

Потому же менеджер кучи не резервирует дополнительного места после блока выделенной памяти. Расширение будет только если освободили память строго за текущим блоком при этом освобожденный блок был больше чем нужно для роста. Такое событие маловероятно. Если хотите реально иметь возможность выделять память с возможностью роста, то такое поведение можно сделать средствами ОС, в частности в Windows можно зарезервировать адресное пространство, но выделить только столько сколько нужно, а при необходимости до выделить память по зарезервированным адресам. Тогда получиться непрерывный кусок расширяемый кусок. 

Это понятно ,но Я не уверен что он вызывает имеено malloc , если бы так то realloc был бы не нужен ,
а не другие механизмы , более низнего уровня,  

malloc/realloc/calloc/free работают с "кучей" (new/delete тоже, кстати), которая реализуется средствами стандартной библиотеки. К API системы это не имеет отношения (точнее, API используется только для изменения размеров собственно кучи). А куча - это как файловая система на диске, только без возможности фрагментации. Увеличить конкретный блок можно только:
или если после него есть свободное место
или если он находится в конце кучи, а другого подходящего куска в куче нет, в этом случае куча будет увеличена и блок будет увеличен соответственно.

Это сообщение отредактировал(а) bsa - 8.3.2012, 14:29

На изучении некоторого количества сорцов RTL и на здравом смысле. Если вы хотите, что бы realloc мог сделать что то помимо free/malloc вам надо самому следить за тем, что и в какой последовательности вы просите расположить на куче. realloc не может перераспределить уже выделенную память, поэтому, если после куска, который вы хотите увеличить, что то уже лежит, то никаких вариантов кроме free/malloc уже не остается

Не понял, если  если после куска, который вы хотите увеличить, что то уже лежит, то логике ,realloc сам вызовет malloc + memcpy,
или какой то свой механизм/алгоритм, 
Я ж не знаю лежит что-то после куска или нет , счас может лежать через 5 минут нет , 

про самому следить за тем, что и в какой последовательности вы просите расположить на куче это как ? 

Ты все понял. После malloc+memcpy+free будет выделен НОВЫЙ участок памяти, и старые указатели станут неверны.
Вот именно.
Написать свой собственный менеджер кучи.

он и в С не особо то и нужен, все равно нужно клонировать объект (хоть с =() , хоть и без ),
тут вопрос закрыт

еще момент , раз уж зашла речь за вектор , 



стандартный вектор на два множит , мне надо 100 прибавлять,   правильно алокатор писать ?
должен быть свой класс наследник std::allocator? , какие методы перегружать ? или у вектора resize перегрузить ?



Это сообщение отредактировал(а) sergioK1 - 12.3.2012, 00:32

Вектор имеет право изменять размер буфера как ему захочется, но снаружи это не видно. size() всегда будет возвращать размер реальных данных. А вот capacity() будет возвращать нечто большее.


Это не поможет, вектор стартегию выделения памяти (с запасом) на allocator не отдает.



Управляйте размером и резервацией в векторе явно (resize() и reserve())


Никакие. У STL контейнеров нет виртуальных методов

из простого, написать свой (внешний) push_back, который будет ресайзить по нужной стратегии...