void * operator new( size_t cb )
{
void *res = _nh_malloc( cb, 1 );
RTCCALLBACK(_RTC_Allocate_hook, (res, cb, 0));
return res;
}
Подскажите функции для работы с динамической памятью.
Народ! Какими функциями лучше всего в VC 7.0 создать динамический массив, а потом изменить его размер (прибавить элементы или удалить несколько) сохранив при этом данные, содержащиеся в массиве... (вроде realloc позволяет изменить размер выделенной динамически памяти сохранив ее содержание? Это правда? )
Цитата:
Originally posted by warezhka
Народ! Какими функциями лучше всего в VC 7.0 создать динамический массив, а потом изменить его размер (прибавить элементы или удалить несколько) сохранив при этом данные, содержащиеся в массиве... (вроде realloc позволяет изменить размер выделенной динамически памяти сохранив ее содержание? Это правда? )
Народ! Какими функциями лучше всего в VC 7.0 создать динамический массив, а потом изменить его размер (прибавить элементы или удалить несколько) сохранив при этом данные, содержащиеся в массиве... (вроде realloc позволяет изменить размер выделенной динамически памяти сохранив ее содержание? Это правда? )
Проще не пользоваться никакими realloc и т.п., а
использовать шаблон std::vector<T>, где T- тип элементов вектора. Данный контейнер сам динамически меняет размер, и предлагает большой выбор операций.
Да с помощью realloc можно переопределить размер массива при этом не повредив уже хранящиеся в нем данные,конечно если переопределние идет в сторону увеличения массива. Например
//Alloc array of size in 1000 bytes
BYTE* bAr=(BYTE*)malloc(1000);
//Fill some info to array
for(DWORD i=0;i<1000;i++)
bArr=1;
//realloc to size in 2000 bytes
bAr=(BYTE*)realloc(bAr,2000);
//now bAr is size of 2000 bytes and first 1000 bytes still unchanged
//Alloc array of size in 1000 bytes
BYTE* bAr=(BYTE*)malloc(1000);
//Fill some info to array
for(DWORD i=0;i<1000;i++)
bArr=1;
//realloc to size in 2000 bytes
bAr=(BYTE*)realloc(bAr,2000);
//now bAr is size of 2000 bytes and first 1000 bytes still unchanged
Цитата:
Originally posted by warezhka
Народ! Какими функциями лучше всего в VC 7.0 создать динамический массив, а потом изменить его размер (прибавить элементы или удалить несколько) сохранив при этом данные, содержащиеся в массиве... (вроде realloc позволяет изменить размер выделенной динамически памяти сохранив ее содержание? Это правда? )
Народ! Какими функциями лучше всего в VC 7.0 создать динамический массив, а потом изменить его размер (прибавить элементы или удалить несколько) сохранив при этом данные, содержащиеся в массиве... (вроде realloc позволяет изменить размер выделенной динамически памяти сохранив ее содержание? Это правда? )
Если ты пишешь на C++, а не на С, то забудь про realloc и используй контейнеры.
Один из них mefisto тебе уже показал.
Цитата:
Originally posted by Green
Если ты пишешь на C++, а не на С, то забудь про realloc и используй контейнеры.
Один из них mefisto тебе уже показал.
Если ты пишешь на C++, а не на С, то забудь про realloc и используй контейнеры.
Один из них mefisto тебе уже показал.
А как же new b delete?
Цитата:
Originally posted by alibabaich
А как же new b delete?
А как же new b delete?
Дык придется все равно реализовывать изменение размера, а на кой в банальном случае изобретать велосипед?
Цитата:
Originally posted by Green
Дык придется все равно реализовывать изменение размера, а на кой в банальном случае изобретать велосипед?
Дык придется все равно реализовывать изменение размера, а на кой в банальном случае изобретать велосипед?
Потеря универсальности, выйгрышь в скорости... Хотя, может и не будет выйгрыша... Но new и delete это то что работает с динамической памятью, не на уровне подключения библиотек...
new и delete хороши для классов,а вот для большого количества массивов они не очень подходят так как заметно медленнее чем тот же malloc или realloc. А еще лучше если тебе нужно полностью контролировать процесс отдачи и выделения памяти под что угодно особенно больших размеров то лучше сделать свой класс менеджера памяти с использованием функций семейства VirtualAlloc. А для остальных случаев даже в с++ я все равно придерживаюсь хорошего мнения о malloc или realloc,нежели каих то контейнеров или вообще классов из MFC.
Цитата:
Originally posted by vitaly2003s
new и delete хороши для классов,а вот для большого количества массивов они не очень подходят так как заметно медленнее чем тот же malloc или realloc. А еще лучше если тебе нужно полностью контролировать процесс отдачи и выделения памяти под что угодно особенно больших размеров то лучше сделать свой класс менеджера памяти с использованием функций семейства VirtualAlloc. А для остальных случаев даже в с++ я все равно придерживаюсь хорошего мнения о malloc или realloc,нежели каих то контейнеров или вообще классов из MFC.
new и delete хороши для классов,а вот для большого количества массивов они не очень подходят так как заметно медленнее чем тот же malloc или realloc. А еще лучше если тебе нужно полностью контролировать процесс отдачи и выделения памяти под что угодно особенно больших размеров то лучше сделать свой класс менеджера памяти с использованием функций семейства VirtualAlloc. А для остальных случаев даже в с++ я все равно придерживаюсь хорошего мнения о malloc или realloc,нежели каих то контейнеров или вообще классов из MFC.
Не поминай имя MFC в суе...
Тебе подсказали два реальных способа (я не беру realloc!) - контейнер и new & delete;
1. Насчет контейнеров и про vector частности - это
шаблонный код. А он долго компилируеться, довольно быстро выполняеться, так что если особенных по оптимизации критериев нет, то используй его.
2. Про второй способ - то можешь сам написать, что - то своего контейнера. В принципе - это неплохой вариант. Там ты сам волен оптимизировать все.
Удачи!!!
1. Насчет контейнеров и про vector частности - это
шаблонный код. А он долго компилируеться, довольно быстро выполняеться, так что если особенных по оптимизации критериев нет, то используй его.
2. Про второй способ - то можешь сам написать, что - то своего контейнера. В принципе - это неплохой вариант. Там ты сам волен оптимизировать все.
Удачи!!!
Цитата:
Originally posted by vitaly2003s
new и delete хороши для классов,а вот для большого количества массивов они не очень подходят так как заметно медленнее чем тот же malloc или realloc.
new и delete хороши для классов,а вот для большого количества массивов они не очень подходят так как заметно медленнее чем тот же malloc или realloc.
Ну никак не отвыкнуть от С и начать писать на С++?
У вас в остальном так все соптимизировано, что new - это камень преткновения?
Ты уверен, что "заметно медленнее"?
Реализация new:
Код:
Реализация malloc:
Код:
void * __cdecl _malloc_base (size_t size)
{
void *res = _nh_malloc_base(size, _newmode);
RTCCALLBACK(_RTC_Allocate_hook, (res, size, 0));
return res;
}
{
void *res = _nh_malloc_base(size, _newmode);
RTCCALLBACK(_RTC_Allocate_hook, (res, size, 0));
return res;
}
В каком именно месте оно медленнее?
Цитата:
Originally posted by vitaly2003s
А еще лучше если тебе нужно полностью контролировать процесс отдачи и выделения памяти под что угодно особенно больших размеров то лучше сделать свой класс менеджера памяти с использованием функций семейства VirtualAlloc.
А еще лучше если тебе нужно полностью контролировать процесс отдачи и выделения памяти под что угодно особенно больших размеров то лучше сделать свой класс менеджера памяти с использованием функций семейства VirtualAlloc.
Угумс, и там где можно было спокойно воспользоваться new, потратить пол-жизни на разработку и отладку универсального менеджера памяти, который был бы потокобезопасным и одинаково хорошо и экономично работал бы с блоками больших и малых размеров.
Цитата:
Originally posted by vitaly2003s
А для остальных случаев даже в с++ я все равно придерживаюсь хорошего мнения о malloc или realloc,нежели каих то контейнеров или вообще классов из MFC.
А для остальных случаев даже в с++ я все равно придерживаюсь хорошего мнения о malloc или realloc,нежели каих то контейнеров или вообще классов из MFC.
Великолепно, сравнить функцию выделения/перераспределения памяти и класс контейнера.
Хотя, чему удивляться после фразы "каих то контейнеров".
[QUOTE]Originally posted by Green
Абсолютно согласен насчет того, что если пишешь на С++, то желательно использовать только библиотеки С++. Если пишешь на обьектно-ориентированном языке, то должен стараться уйти от всяких представлениях о структурной модели мышления.
[QUOTE]Originally posted by vitaly2003s
Вообще С++ гораздо сильнее, чем С, даже в структурном программировании.
Абсолютно согласен насчет того, что если пишешь на С++, то желательно использовать только библиотеки С++. Если пишешь на обьектно-ориентированном языке, то должен стараться уйти от всяких представлениях о структурной модели мышления.
[QUOTE]Originally posted by vitaly2003s
Вообще С++ гораздо сильнее, чем С, даже в структурном программировании.
Тут явно затисались поклонники МФЦ. И все же malloc and realloc это рулез. Безотказно и быстро работают во всех моих прогах уже на протяжение достаточно долгого времени,и еще не разу меня не подвели. А насчет того что раз пользуешся с++ то должен использовать только классы и методы объектно ориентированого программирования,то я с этим категорически не согласен. С был,буде и останется самым лучшим языком особенно для полного понимания функционирования программ и ОС в целом. Вас бы на АСМе заставить что то стоящее напистать,тогда бы вы забыли что такое объектно ориентированое программирование. И по моему лучше изобрести свой велосипед чем пользоватся чужими спицами!
Цитата:
Originally posted by vitaly2003s
Тут явно затисались поклонники МФЦ.
Тут явно затисались поклонники МФЦ.
Здесь явно затаился человек совершенно не компетентный в С++. :D
STL не имеет ни какого отношения к MFC и к VC++ вообще. STL - это стандартная библиотека, неотлемлемая часть С++.
Цитата:
Originally posted by vitaly2003s
И все же malloc and realloc это рулез. Безотказно и быстро работают во всех моих прогах уже на протяжение достаточно долгого времени,и еще не разу меня не подвели.
И все же malloc and realloc это рулез. Безотказно и быстро работают во всех моих прогах уже на протяжение достаточно долгого времени,и еще не разу меня не подвели.
Вот только сомневаюсь, что программы эти написаны на С++.
Цитата:
Originally posted by vitaly2003s
А насчет того что раз пользуешся с++ то должен использовать только классы и методы объектно ориентированого программирования, то я с этим категорически не согласен.
А насчет того что раз пользуешся с++ то должен использовать только классы и методы объектно ориентированого программирования, то я с этим категорически не согласен.
Ну это твои проблемы. Можешь и по дорогам ездить по другой стороне, если никого рядом нет.
Цитата:
Originally posted by vitaly2003s
С был,буде и останется самым лучшим языком особенно для полного понимания функционирования программ и ОС в целом.
С был,буде и останется самым лучшим языком особенно для полного понимания функционирования программ и ОС в целом.
Извини, бредовый лозунг...
Язык не для понимания, а для реализации алгоритма.
Цитата:
Originally posted by vitaly2003s
Вас бы на АСМе заставить что то стоящее напистать,тогда бы вы забыли что такое объектно ориентированое программирование.
Вас бы на АСМе заставить что то стоящее напистать,тогда бы вы забыли что такое объектно ориентированое программирование.
Я плакаль... :D
АСМ, а кто это?
Цитата:
Originally posted by vitaly2003s
И по моему лучше изобрести свой велосипед чем пользоватся чужими спицами!
И по моему лучше изобрести свой велосипед чем пользоватся чужими спицами!
ТовариСЧ Вы не туда попали, Вам в темное средневековье.
Цитата:
Originally posted by Green
Здесь явно затаился человек совершенно не компетентный в С++. :D
STL не имеет ни какого отношения к MFC и к VC++ вообще. STL - это стандартная библиотека, неотлемлемая часть С++.
Вот только сомневаюсь, что программы эти написаны на С++.
Ну это твои проблемы. Можешь и по дорогам ездить по другой стороне, если никого рядом нет.
Извини, бредовый лозунг...
Язык не для понимания, а для реализации алгоритма.
Я плакаль... :D
АСМ, а кто это?
ТовариСЧ Вы не туда попали, Вам в темное средневековье.
Здесь явно затаился человек совершенно не компетентный в С++. :D
STL не имеет ни какого отношения к MFC и к VC++ вообще. STL - это стандартная библиотека, неотлемлемая часть С++.
Вот только сомневаюсь, что программы эти написаны на С++.
Ну это твои проблемы. Можешь и по дорогам ездить по другой стороне, если никого рядом нет.
Извини, бредовый лозунг...
Язык не для понимания, а для реализации алгоритма.
Я плакаль... :D
АСМ, а кто это?
ТовариСЧ Вы не туда попали, Вам в темное средневековье.
Green, поздравляю с 1000-ым сообщением, разоблачающим C-онистов, закравшихся в ряды C++-истов.
Цитата:
Originally posted by pavor
Green, поздравляю с 1000-ым сообщением, разоблачающим [COLOR=red]C-онистов[/COLOR], закравшихся в ряды C++-истов.
Green, поздравляю с 1000-ым сообщением, разоблачающим [COLOR=red]C-онистов[/COLOR], закравшихся в ряды C++-истов.
Green! я тоже поздравляю с 1000м сообщением. Желаю удачи...
Цитата:
Originally posted by vitaly2003s
С был,буде и останется самым лучшим языком особенно для полного понимания функционирования программ и ОС в целом.
[QUOTE]Originally posted by Green
Извини, бредовый лозунг...
Язык не для понимания, а для реализации алгоритма.
С был,буде и останется самым лучшим языком особенно для полного понимания функционирования программ и ОС в целом.
[QUOTE]Originally posted by Green
Извини, бредовый лозунг...
Язык не для понимания, а для реализации алгоритма.
[/QUOTE]Недавно читал одно мнение, что писать программу на языке отличном от C++, это извращение, за что сажать надо.
Цитата:
Originally posted by Green
Я плакаль...
АСМ, а кто это? :D
Я плакаль...
АСМ, а кто это? :D
Так это же ассемблер! Более трудный вопрос: "Кто такой Скр?"
-----------------------------------------------
Диктант. Марья Ивановна диктует:"В углу скребёт мышь".
Вовочка тянет руку.
Марья Ивановна раздражённо:"Вовочка! Что тебе опять не ясно"?
Вовочка:"МарьИванна! А кто такой Скр"?
------------------------------------------------
Цитата:
Originally posted by vitaly2003s
С был,буде и останется самым лучшим языком особенно для полного понимания функционирования программ и ОС в целом.
С был,буде и останется самым лучшим языком особенно для полного понимания функционирования программ и ОС в целом.
Но если речь идет о сложной программе, то у C++ есть небольшой плюс, алгоритм проще писать и, более важно, проще изменять.
Цитата:
Originally posted by vitaly2003s
И по моему лучше изобрести свой велосипед чем пользоватся чужими спицами![QUOTE]Originally posted by GreenТовариСЧ Вы не туда попали, Вам в темное средневековье.
И по моему лучше изобрести свой велосипед чем пользоватся чужими спицами![QUOTE]Originally posted by GreenТовариСЧ Вы не туда попали, Вам в темное средневековье.
[/QUOTE]Если речь идет о студенте, или об освоении что-то нового, то, IMHO vitaly2003s прав.
Цитата:
Originally posted by Green
Ну никак не отвыкнуть от С и начать писать на С++?
У вас в остальном так все соптимизировано, что new - это камень преткновения?
Ну никак не отвыкнуть от С и начать писать на С++?
У вас в остальном так все соптимизировано, что new - это камень преткновения?
Ооо.. Я бы дак не заявлял.
Сегодня весь день промаялся с подобной проблемой. Может кто помнит эту тему:
http://forum.codenet.ru/showthread.php?threadid=16036
При подробном разбирательстве оказалось, что в gcc глюкавый STL (В Borland C++ Builder все работает как часы - никаких проблем с памятью). В Visual C++ оказалось все тоже не так прозрачно - реже, но утечки были.
Вместо map пришлось использовать хэшированый массив. Стало работать сильно быстрее и никаких утечек памяти.
Написал свой менеджер памяти. Сразу могу сказать - если проект большой, то начинать нужно именно с этого. (Особенно актуально под *nix, где отладка сильно отличается от виндозной, да и еще когда отлаживаются многопроцессорные, многопоточные демоны с кучей сигналов и всяких взаимодействий)
Для начала всем спасибо за поздравления с "юбилеем". Я так растрогался, что хочу попросить прощения за свои резкие высказывания в прошлом... и будущем... :)
Цитата:
Originally posted by mike
При подробном разбирательстве оказалось, что в gcc глюкавый STL (В Borland C++ Builder все работает как часы - никаких проблем с памятью). В Visual C++ оказалось все тоже не так прозрачно - реже, но утечки были.
При подробном разбирательстве оказалось, что в gcc глюкавый STL (В Borland C++ Builder все работает как часы - никаких проблем с памятью). В Visual C++ оказалось все тоже не так прозрачно - реже, но утечки были.
Ну так про глюки различных реализаций STL не раз уже говорилось. Я использую STLPort, в нем глюков по-меньше, чем в реализации STL поставляемом с VC++ и Borland. Кстати, до последнего времени по моим данным у них была одна реализация STL. Неужели Borland прикупил другую?
Цитата:
Originally posted by mike
Написал свой менеджер памяти. Сразу могу сказать - если проект большой, то начинать нужно именно с этого. (Особенно актуально под *nix, где отладка сильно отличается от виндозной, да и еще когда отлаживаются многопроцессорные, многопоточные демоны с кучей сигналов и всяких взаимодействий)
Написал свой менеджер памяти. Сразу могу сказать - если проект большой, то начинать нужно именно с этого. (Особенно актуально под *nix, где отладка сильно отличается от виндозной, да и еще когда отлаживаются многопроцессорные, многопоточные демоны с кучей сигналов и всяких взаимодействий)
Согласись, что это дело совсем не для новичка или программиста "среднего звена", и в большинстве случаев все же достаточно стандартных средств распределения памяти.
Цитата:
Originally posted by rostyslav
Так это же ассемблер! Более трудный вопрос: "Кто такой Скр?"
Так это же ассемблер! Более трудный вопрос: "Кто такой Скр?"
Да про ассемблер я понял. Просто хотел подыграть тов.vitaly2003s, типа даже не знаю, что это такое. :)
А Скр - это наверное сокращение от script. А в рассказе идет речь о злобном скрипте "I Love you", который любит мышь...
Поздровляю, с перевалом за 1000 извини что поздно... Но в нет я только на работе выхожу, дома не поверишь даже радиоприёмник плохо
Да. Да. Наверное товарищ Green крутой программист в чем я очень сомневаюсь,между прочим я вхожу в десятку сильнейших программистов на сях нашего города,а ты чем можешь похвастаться,только своими оскорблениями? А про STL я конечно знаю и не путаю его с MFC,я написал так потому что подумал что имею дело с людьми которые без MFC написать вообще ничего не смогут,и вообще MFC - это дурь которую втирает МелкоМякгий простым смертным да и там где можно совершенно обойтись без него.
Цитата:
Originally posted by vitaly2003s
Да. Да. Наверное товарищ Green крутой программист в чем я очень сомневаюсь,между прочим я вхожу в десятку сильнейших программистов на сях нашего города,а ты чем можешь похвастаться,только своими оскорблениями? А про STL я конечно знаю и не путаю его с MFC,я написал так потому что подумал что имею дело с людьми которые без MFC написать вообще ничего не смогут,и вообще MFC - это дурь которую втирает МелкоМякгий простым смертным да и там где можно совершенно обойтись без него.
Да. Да. Наверное товарищ Green крутой программист в чем я очень сомневаюсь,между прочим я вхожу в десятку сильнейших программистов на сях нашего города,а ты чем можешь похвастаться,только своими оскорблениями? А про STL я конечно знаю и не путаю его с MFC,я написал так потому что подумал что имею дело с людьми которые без MFC написать вообще ничего не смогут,и вообще MFC - это дурь которую втирает МелкоМякгий простым смертным да и там где можно совершенно обойтись без него.
А я вообще самый крутой программист, по мнению моей жены(она правда других не знает)... :D
Цитата:
Originally posted by vitaly2003s
между прочим я вхожу в десятку сильнейших программистов на сях нашего города
между прочим я вхожу в десятку сильнейших программистов на сях нашего города
Когда войдешь в десятку сильнейших программистов по С++, можешь помочь мне решить эту задачу:
http://forum.codenet.ru/showthread.php?s=&threadid=19409
P.S. Кстати, для выявления сильнейших вы толкали гири или жали штангу?
Помнится в академии я выступал за сборную курса по гирям. Призовые места не занимал, но в десятку тоже входил...