Выделение памяти для нужд C++ библиотеки

[220Volt]

Здравствуйте.

Есть ли программиста уверенность в том, что все библиотечные функции используют new-delete, а не malloc/calloc-free? Другими словами - переопределение new-delete (глобальных) гарантирует полный контроль над выделением памяти, при использовании библиотеки С++?

[Smitt&Wesson]

Нужно представлять себе, что такое оперативная память. Это "нечто", куда можно что-то записывать и откуда, "что-то считывать". malloс, выделяыет статический сегмент оперативной памяти, (посему сейчас и не в ходу у программйров). new, выделяет динамический участок, он может размещаться кусками, по всему объёму оперективки, это пре6дпочтительнее, чем malloс. Но есть и здессь подводные камни, для оптимизации работы, винда начинает перераспределять память, это выглядит как "подвисание" системы. В случае использования malloc/calloc, я такого не наблюдал.

[220Volt]

Я думаю, что у всех выделений памяти ноги растут от winapi и не удивлюсь если new – это тот же malloc, но с вызовом конструктора. Зачем мне это нужно? Я хочу выделять память для процесса в участке виртуальной памяти, который потом буду проецировать в другом процессе, поэтому нужен полный контроль.

[_Bers]

Сообщение от 220Volt

Здравствуйте.

Есть ли программиста уверенность в том, что все библиотечные функции используют new-delete, а не malloc/calloc-free? Другими словами - переопределение new-delete (глобальных) гарантирует полный контроль над выделением памяти, при использовании библиотеки С++?

Что бы иметь такую уверенность, нужно изучить исходный код этой целевой библиотеки, и только после этого что либо утверждать.

Переопределение new/delete весьма опасная операция. Чреватая сюрпризами, которые могут сильно отравлять жизнь и приводить к перерасходу времени и денег на отладке и сопровождении. Что делает подобные трюки крайне нежелательными для продуктов, которые предполагается в последствии сопровождать.

Но если очень очень сильно хочется, то есть смысл глянуть в сторону реализации небезызвестного:

#ifdef _DEBUG
#include <crtdbg.h>                 //<--- изучите реализацию библиотеки
#define _CRTDBG_MAP_ALLOC
#endif

Вот здесь есть краткое популярное объяснение работы:

http://www.realcoding.net/articles/b...ati-c-crt.html


Имхо: стоит подумать семь раз, прежде чем решиться на перехват crt функций работы с памятью.

[Smitt&Wesson]

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

[220Volt]

Сообщение от Smitt&Wesson

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

Я не хочу использовать malloc, реализацию надо на winapi.

_Bers, спасибо за ссылку натолкнуло на интересные мысли.
P.S. благодарю за ответы, думаю разобрался.

[Smitt&Wesson]

Сообщение от 220Volt

думаю разобрался.

Удачи. Но, старайтесь не использовать malloc, у нас, на с чёт него, были большие споры (вплоть до драк), когда одна прога "захватывала" всю память, тогда, как другая "висела" в ожидании высвобождения ресурса. С появлением в с++ конструкции new, все проблемы решились сами-собой. Ненавижу malloc. Хотя у неё есть и достоинстува. Если в Асме, нужно что-то поправить при выделенной статически памяти, достаточно знать начальный адрес. При динамическом выделении, нужно знать ищё и указатель.

[Пепел Феникса]

Сообщение от Smitt&Wesson

Удачи. Но, старайтесь не использовать malloc, у нас, на с чёт него, были большие споры (вплоть до драк), когда одна прога "захватывала" всю бамять, тогда, как другая "висела" в ожидании высвобождения ресурса. С появлением в с++ конструкции new, все проблемы решились сами-собой. Ненавижу malloc.

интересно мне знать какая статическая память в винде?
у каждого процесса свое адресное пространство в 2ГБ минимум.
и чтоб в него влезть надо через VirtualAllocEx там тогда, причем в каждый процесс.

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

далее:

void *__CRTDECL operator new(size_t size) _THROW1(_STD bad_alloc)
        {       // try to allocate size bytes
        void *p;
        while ((p = malloc(size)) == 0)
                if (_callnewh(size) == 0)
                {       // report no memory
                static const std::bad_alloc nomem;
                _RAISE(nomem);
                }

        return (p);
        }

забавно правда?

[EUGY]

С появлением в с++ конструкции new, все проблемы решились сами-собой. Ненавижу malloc.

Для объектов - да.
А для POD вполне себе нормально malloc.
_expand
_msize
realloc
Аналогов вроде в c++ нет.
PS

new, выделяет динамический участок, он может размещаться кусками

Не встречал объекта имеющего прерывистый диапазон адресов.

[pproger]

Сообщение от Smitt&Wesson

malloс, выделяыет статический сегмент оперативной памяти, (посему сейчас и не в ходу у программйров). new, выделяет динамический участок, он может размещаться кусками, по всему объёму оперективки, это пре6дпочтительнее, чем malloс.

чтот я не пойму о чем ты говоришь. единственная разница между malloc и new только в том, что new вызывает конструктор (ну и исключение кидает). память они получают одинаково, через один и тот же системный вызов.

new, выделяет динамический участок, он может размещаться кусками

кусками где? в физической памяти? естественно кусками, malloc точно так же выделит память кусками. в виртуальной никаких кусков нет, и new и malloc выделят непрерывный кусок памяти.

в общем я не вкурил, что ты имеешь в виду. ссылки чтоль какие приведи.