Как увеличить массив не уничтожая его?

[nikedeforest]

Помнится в одной теме это уже обсуждалось, но я ее найти не могу, а вопрос вроде даже и не вопрос, поэтому думаю ответ получу быстро
Так вот есть массив
char *str;
str=new char [12];

Как мне добавить в него еще 3(не важно сколько) элемента? Функция вроде такая есть (если я ничего не путаю) чтобы к массиву, не уничтожая его, добавить новые элементы.
Надеюсь корректно выразился.

[Alf]

Это невозможно. Во-первых, подсистема распределения памяти в куче выделила под *str лишь 12 байт. Если массив прибавит себе еще несколько байт "самозахватом", то подсистема ничего об этом не узнает, и при следующем выделении памяти с большой вероятностью разместит в этой области другие объекты, которые испортят добавленный к массиву хвост (или он их испортит первым, смотря по ситуации).

Во-вторых, если после выделения памяти под массив были другие обращения к new, то скорее всего по адресу str+12 уже расположено что-то другое, и расти массиву больше некуда.

Единственное приемлемое решение в данном случае - это создать новый массив требуемого размера, скопировать в него все элементы старого, а область памяти, занятую старым, вернуть обратно через delete[]. Можно либо сделать это вручную, либо воспользоваться контейнерами из стандартной библиотеки, которые обучены подобным фокусам и могут расширяться при необходимости.

[nikedeforest]

Про вручную понял, спасибо, а что за стандартные контейнеры, хотя бы один для примера.

[Alf]

Например, погляди контейнер vector из STL. В нем есть метод resize. Если новый размер больше старого, то к нему добавятся новые элементы в хвост, а если меньше - произойдет усеечение.

[nikedeforest]

STL, я с ней никогда не связывался и пока думаю не стоит, надо выждать .
Alf, спасибо!!!

[Михалыч]

ожидание не поможет
Да нет там ничего особенно сложного. А жизнь облегчает капитально. Чем раньше начнешь - тем раньше освоишь.
Единственное неудобство (ну может это мое субъективное) отладка проблематичнее. Мягко говоря не очень удобно залезть отладчиком и посмотреть содержимое элемента того же вектора.

[Pu]

Михалыч, я для отладки пользуюсь вот таким методом, может и криво но посмотреть мона любые типы.   

Код:

       std::vector<int> v;
	for( int i = 0; i<100; i++)
		v.push_back( i);	
	int *g = new int[v.size()];
	std::copy( v.begin(), v.end(), g); //после копирования можно посмотреть в массиве любые значения по индексу, чего не получается в векторе
	delete []g;

[Pu]

nikedeforest, чем обусловлено нежелание уничтожать массив. Если ты хранишь гдето указатель на массив и потом после увеличения его пытаешься использовать, то в этом случае тебе можуть помочь только связанные списки в STL это std::list. Там после перераспределения памяти элементы остаются на своих местах. А при использовании std::vector элементы перемещаются в памяти чтобы занимать непрерывную область. Так жеж в этом случае не поможуть и функции malloc - realloc.

[Гром]

Жуть ИМХО... Чего вы насоветовали...

Слухай сюды:

1. Записи
char str[12];
и
char * str=(char *)malloc(12);
равнозначны по занятой памяти и методу обращения к ним.

И там и там можно писать
str[5]='a';

2. Во втором случае можно:
str=(char *)realoc((void *)str,newsize);
где newsize = 12+n; // n - новая необходимая к добавлению длина...

При использовании не char = 1 bite, а int писать надо:

Код:

int *test_param;
int size=100;
int increment=1000;
test_param = (int *malloc(size*sizeof(int));

....
....
test_param = (int *)realloc((void *)test_param,(size+increment)*sizeof(int));

Всегда надо помнить что в С и С++ массив и типизированный указатель можно использовать одинаково, с единственной разницей - указатель надо высвобождать free(test_param);

[Pu]

Гром, я вот о чем, в приведеном коде сохраняется указатель на выделенную память в указатель с1. после операции реаллок он будет уже показывать на невалидные данные. попытка воспользоваться им приведет к .... сам знаешь .

Код:

char *c1;

int main()
{
	char *c = (char *)malloc(12);
       с1 = с;
	char *t = (char *)malloc(12);
	c = (char *)realloc( c, 20); // теперь указатель с1 будет показывать на черт знает что
	free(c);
	free(t);
	return 0;
}

[Гром]

Гром, я вот о чем, в приведеном коде сохраняется указатель на выделенную память в указатель с1. после операции реаллок он будет уже показывать на невалидные данные. попытка воспользоваться им приведет к .... сам знаешь .

Код:

char *c1;

int main()
{
	char *c = (char *)malloc(12);
 с1 = с;
	char *t = (char *)malloc(12);
	c = (char *)realloc( c, 20); // теперь указатель с1 будет показывать на черт знает что
	free(c);
	free(t);
	return 0;
}

А что мешает дописать:
с1 = с;
после realloc???
Как и всегда - отслеживание состояние указателя лежит на программисте.

[Alf]

Как и всегда - отслеживание состояние указателя лежит на программисте.

Некрасиво все-таки. Компилятором C++ пользуем программу, написанную практически на чистом С. Для того и ввели объектные заморочки, чтобы писать надежные программы без побочных сюрпризов. А тут придется чесать репу, обнаружив, что Вася в своей подпрограмме изволил передвинуть массив, которому стало тесно, и не предупредил Петю, который в начале программы сохранил на него ссылку и теперь диву дается, куда подевались его данные. Можно, конечно, выпороть Васю на конюшне за саботаж, а можно воспользоваться надежными объектами, которые таких фокусов не допустят и не потянут особых накладных расходов.

[Pu]

Alf, абсолютно согласен. И уже давненько отказался от такого рода практики, можно привести массу примеров когда нарывался на трудноуловимые ошибки. Щас контейнеры и только контейнеры. Слава богу реализация их у меня  вызывает все больше восхищения. Да есть их на все случаи жизни. Плюс алгоритмы. Короче репу морщить не надо.

[Гром]

Альф 
Не смеши

Я вообще не помню в своей практике realloc-a Если надо - делается динамический список данных или LinkedList или дерево.

[Alf]

Альф
Не смеши

Я вообще не помню в своей практике realloc-a Если надо - делается динамический список данных или LinkedList или дерево.

Ну вот сам и признался, каков ты хитрец 

Сам пишешь корректно, а других всяким низкоуровневым гадостям учишь вроде realloc.

[Гром]

Стоп - не правда ваша
Был конкретный вопрос про массив - я конкретно ответил про массив.

Бывает такое, например рекурсия, когда заполнение данных в массив выгоднее чем в списки - и тогда лучше использовать realloc я признаю забыл что делал такое....

Но просто такие задачи редки.
А когда изначально известно о динамичности данных, то выгоднее выбрать сразу динамичный тип хранения

[nikedeforest]

Ну и дискуссия .
Гром, кажется твой совет я и имел ввиду когда пытался его вспомнить. В какой-то теме ты его предлагал Алексею1153 (если я ничего не путаю), кстати тогда он не вызвал столько отрицательных эмоций, но теперь была возможность оценить плюсы и минусы, спасибо за очередной глоток знаний.
По прочтению постов возник вопрос: Что такое LinkedList? Кажется я с этим еще не сталкивался .

[Михалыч]

to Pu

Михалыч, я для отладки пользуюсь вот таким методом, может и криво но посмотреть мона любые типы.   

Дык, кто бы спорил...
Я же и говорю - несколько неудобно и с извращениями типа промежуточных массивов, но можно.
Все это правда окупается несомненным удобством применения STL.

to Alf

Сам пишешь корректно, а других всяким низкоуровневым гадостям учишь вроде realloc.

Если касательно только этого момента с массивом - то да... И то не гадость. Не одним С++ -ом живем. Просто С еще никто со счетов не сбрасывал. Есть применимость и не маленькая. Другое дело что не везде. Во встраиваемых приложениях, например. Правда тоже не везде. Это не ради дискуссии, поскольку она по этому поводу (на мой взгляд) бессмысленна, просто у тех кто только начинает может сложиться неадекватное впечатление о языке

[Гром]

Liinked List - связный список

[nikedeforest]

А это что инструмент, алгоритм, функция

[Гром]

Тип данных - который состоит из полей связанных между собой указателями...

Нифига себе какой пробел в знаниях

[Pu]

nikedeforest, из названия следует - связанный список , те в стл это контейнер std::list. суть в том что элементы располагаются в памяти не подряд, а с разрывами, как попало. Каждый элемент имеет ссылки на предыдущий и последующий член. Доступ по индексу в таких контейнерах затруднен, тк приходится от текущего перебрать все элементы до нужного. зато алгоритмы сортировки и типа того работают эффективнее не надо физически перемещать элементы, просто пересвязать указатели и все.

[Alf]

...
to Alf
...у тех кто только начинает может сложиться неадекватное впечатление о языке

Согласен на 100%. Почти полная обратная совместимость С++ и С провоцирует использовать рудименты вроде malloc, всяких макроопределений и тому подобных устаревших конструкций там, где вполне можно обойтись более выразительными и безопасными новыми средствами языка. При этом программист совершенно искренне заблуждается, считая, что пишет на С++, ведь компилятор не выдает ни единой ошибки, да и программа вроде работает корректно (пока не пришлось ее модифицировать или передать на сопровождение коллеге, который не успел разгадать все ребусы с периодически кочующими массивами и т.п.).

IMHO эта обратная совместимость с предшественником оказывает сегодня языку такую же медвежью услугу, как и обратная совместимость последних процессоров Intel с динозавром 8086, в результате которой мы имеем технологически совершенный кристалл, работающий на невообразимых частотах и при этом имеющий искалеченную архитектуру с ограниченным набором регистров общего назначения, которые фактически таковыми не являются, архаичным аккумулятором, извращенными методами адресации, непонятной пристройкой в виде сопроцессора с плавающей точкой... Словом, обычный популистский шаг, который сначала дает некоторое преимущество, позволяя сохранить приверженцев прежней модели, не готовых к радикальным переменам концепции, а потом оказывается тяжкой гирей на ногах, которая мешает двигаться дальше.

[nikedeforest]

Нифига себе какой пробел в знаниях 

Гром, в реалии этот пробел еще больше .
Pu, спасибо, доступно объяснил.

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

У нас в науку вкладывает гос-во, из-за чего наука нищенствует, а на западе наука сама зарабатывает (или зарабатывают с помощью науки) из-за чего там приходится корректировать прогресс на благо заработка и не совсем в угоду прогрессу. Везде есть свои недостатки.

[Джон]

Alf, привет. Тоже не спится? Я вот выбрался из дому, а тут такая дискуссия, но только ты в онлайне. Ну ладно.
Чего они тут воду мутят? Гром, говоря твоими словами - Был конкретный вопрос про массив - Alf конкретно ответил про массив. Нельзя такого сделать. Тем более, что  nikedeforest о чём то таком догадывался - ведь не зря в вопросте стоит "не уничтожая его". Прелесть массивов и заключается в непрерывности блоков данных, чем обеспечивается мгновенный доступ к необходимому блоку простым вычислением его адреса. Но как правильно Alf написал во втором пункте - а ежели дальше нет места? то тогда никуда не денешься придётся искать другой блок подходящих размеров. В независимости програмируется в С или С++.
Кстати, Михалыч, в 2003 студии дебаггер показыват содержимое STL контейнеров. Конечно если это твои типы данных. Так что всё в порядке - проблемм нет.
nikedeforest, - не отчаивайся и не бойся - я начал с знакомство с STL случайно. Как всегда в поисках скудной инфы на русском языке (дело было в конце прошлого тысячелетия) я наткнулся на пример главы из книги
Леена Аммерааля "STL для программистов на C++" - файл в формате pdf - около -30 страниц. Читалось очень легко и главное понятно. Могу только порекомендовать. Теперь вопрос как люди могут програмировать без STL вызывает у меня такое же недоумение как и вопрос, как люди 100 лет назад обходились без пластмассы.

[Джон]

nikedeforest, у тебя оказывается тоже бессонница.

[nikedeforest]

Джон, я полуночник (сова). За рекомендацию спасибо, обязательно ознакомлюсь в ближайшее время. По-видимому настало время браться за STL .

[Джон]

Непременно надо браться. Если не найдёшь (хотя я думаю с этим проблем не будет) чиркни на мыло. Я тебе файл на мыло кину.

[nikedeforest]

Джон, буду иметь ввиду

[Alf]

Alf, привет. Тоже не спится? Я вот выбрался из дому, а тут такая дискуссия, но только ты в онлайне.

Привет. Тут такой интересный разговор завязался из безобидного поначалу вопроса, что никак проспать нельзя 

Столкновение двух точек зрения: "так не следует делать, потому что..." против "но я ведь делал, и у меня все работало!!!" 

Это интереснее, чем куски MSDN друг другу цитировать...