SUBJ

new/delete equal HeapAlloc/HeapFree — слишком сильное обобщение.

Здравствуйте Алекс, Вы писали:

HeapAlloc/HeapFree — Это менеджер памяти.
new/delete — Это операторы языка которые кроме выделения/освобождения памяти вызывают конструкторы/деструктор. Они(new/delete) могут быть реализованы через HeapAlloc/HeapFree.

Почувствуйте разницу.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте Алекс, Вы писали:

WH>Почувствуйте разницу.
Действительно. Первое функции OS, второе языка

Здравствуйте, Sergey, Вы писали:

S>new/delete equal HeapAlloc/HeapFree — слишком сильное обобщение.

Не слишком. Нормальное. Наверное, вы немного неправильно распарсили вопрос Он не содержит всех слов, которые были упущены.

Сформулируем его по-другому:
Что по скорости управления памятью лучше: HeapXXX или операторы new/delete?

В такой постановке (и я именно так понял вопрос, как, видимо, и Алекс) имеются ввиду именно void* ::operator new( size_t ) и соответствующий ::operator delete().

Заметьте, что речь идет не и new/delete expression, а о операторах. Операторы только выделяют или освобождают сырую память. Никаких побочных действий. И по скорости два варианта практически равны.

Здравствуйте, Sergey, Вы писали:

S>new/delete equal HeapAlloc/HeapFree — слишком сильное обобщение.

C/C++ Run-time (CRT) allocator: Provides malloc() and free() as well as new and delete operators. Languages like Microsoft Visual Basic® and Java also offer new operators and use garbage collection instead of heaps. CRT creates its own private heap, which resides on top of the Win32 heap.

Здравствуйте, Kaa, Вы писали:

[]

Kaa>В такой постановке (и я именно так понял вопрос, как, видимо, и Алекс) имеются ввиду именно void* ::operator new( size_t ) и соответствующий ::operator delete().

Которые могут быть реализованы разными способами.

Здравствуйте, Patalog, Вы писали:

P>Которые могут быть реализованы разными способами.

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

Здравствуйте, Kaa, Вы писали:

P>>Которые могут быть реализованы разными способами.

Kaa>... для каждого отдельно взятого компилятора. Но я не верю, что какой-то производитель компилятора сделает что-то такое, что будет тормознее, чем систмные вызовы. Не враг же он себе и своей репутации.

Ну, веришь\не веришь — дело десятое. Я к тому, что ставить знак равенства в данном случае весьма и весьма не правильно. Кроме того, при чем tyt производители компиляторов? Не, ну они конечно роль играют , но с другой стороны перегрузку операторов пока не отменили. И ежели я перегружу operator new так, что память у меня будет выделяться к примеру, в другом процессе, то что, тоже equal поставить можно?

Здравствуйте, Kaa, Вы писали:

S>>new/delete equal HeapAlloc/HeapFree — слишком сильное обобщение.

Kaa>Не слишком. Нормальное. Наверное, вы немного неправильно распарсили вопрос Он не содержит всех слов, которые были упущены.

Kaa>Сформулируем его по-другому:
Kaa>Что по скорости управления памятью лучше: HeapXXX или операторы new/delete?

Kaa>В такой постановке (и я именно так понял вопрос, как, видимо, и Алекс) имеются ввиду именно void* ::operator new( size_t ) и соответствующий ::operator delete().

Kaa>Заметьте, что речь идет не и new/delete expression, а о операторах. Операторы только выделяют или освобождают сырую память. Никаких побочных действий. И по скорости два варианта практически равны.

И это тоже слишком сильное утверждение Оно может быть справедливо только для конкретного компилятора/рантайма и только в отсутствие перегруженных операторов new/delete. Например, для того же MS VC 6.0 дебоговская версия new/delete предоставляет дополнительную функциональность (совсем не бесплатную).

Здравствуйте, Sergey, Вы писали:

S>Например, для того же MS VC 6.0 дебоговская версия new/delete предоставляет дополнительную функциональность (совсем не бесплатную).

Да, это аргунент. Я об том не подумал. Имел ввиду именно обычную неперекрытую версию.

Здравствуйте, Patalog, Вы писали:

P>Здравствуйте, Kaa, Вы писали:

P>>>Которые могут быть реализованы разными способами.

Kaa>>... для каждого отдельно взятого компилятора. Но я не верю, что какой-то производитель компилятора сделает что-то такое, что будет тормознее, чем систмные вызовы. Не враг же он себе и своей репутации.

P>Ну, веришь\не веришь — дело десятое. Я к тому, что ставить знак равенства в данном случае весьма и весьма не правильно. Кроме того, при чем tyt производители компиляторов? Не, ну они конечно роль играют , но с другой стороны перегрузку операторов пока не отменили. И ежели я перегружу operator new так, что память у меня будет выделяться к примеру, в другом процессе, то что, тоже equal поставить можно?

Можно даже сказать по-другому: функции (HeapAlloc, HeapFree и др.) работают просто с памятью, а new/delete — с объектами (классами), у которых вполне вероятно может выполняться какая-то инициализация/разрушение внутренних объектов и т.д.

Да чего тут гадать, надо просто знать что, автор имел ввиду. Я например понял этот вопрос как "реализуется ли new, delete через HeepAlloc, HeepFree". А что объекты не объекты, это и так понятно что не об объектах идет речь, т.к. HeepAlloc конструкторов не вызывает
Так что это вопрос на логику

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте Алекс, Вы писали:

WH>HeapAlloc/HeapFree — Это менеджер памяти.
WH>new/delete — Это операторы языка которые кроме выделения/освобождения памяти вызывают конструкторы/деструктор. Они(new/delete) могут быть реализованы через HeapAlloc/HeapFree.

WH>Почувствуйте разницу.

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

Мой ответ означает лишь, то что сабжевые операторы по умолчанию всегда используют средства выделения памяти, предоставляемые системой. HeapAlloc, HeapFree и др. как раз и есть эти средства.

Здравствуйте, Алекс, Вы писали:

А>Мой ответ означает лишь, то что сабжевые операторы по умолчанию всегда используют средства выделения памяти, предоставляемые системой. HeapAlloc, HeapFree и др. как раз и есть эти средства.

А не по-умолчанию? Реальность, мой друг (заметь, ни капли иронии), такова, что память — это ресурс, полностью контролируемый операционной системой. Из этого вытекает, что невозможно написать оператор new или malloc, который бы выделял память, не пользуясь средствами операционной системы (HeapAlloc, VirtualAloc, AllocateUserPhysicalPages) напрямую или косвенно.

P.S. Конечно, можно написать что-то, что будет работать в нулевом кольце и будет выдавать нам память.

Здравствуйте, MaximE, Вы писали:

хъ

ME>А не по-умолчанию? Реальность, мой друг (заметь, ни капли иронии), такова, что память — это ресурс, полностью контролируемый операционной системой. Из этого вытекает, что невозможно написать оператор new или malloc, который бы выделял память, не пользуясь средствами операционной системы (HeapAlloc, VirtualAloc, AllocateUserPhysicalPages) напрямую или косвенно.

Дорогой, Максим. Если ты не отличаешь HeapAlloc от VirtualAlloc, то о чем вообще может идти речь?

ME>P.S. Конечно, можно написать что-то, что будет работать в нулевом кольце и будет выдавать нам память.

Какая разница на каком кольце, главное чтобы адрес выделенной памяти был меньше 0х7FFEFFFF.

Стоп-стоп-стоп.

Господа, а что — все уверены, что HeapAlloc вызывается при каждом new? Насколько помнится, это не так. Некоторые рантаймы создают свой собственный heap и пользуются winapi по мере необходимости. Например, в Borland C++. Кстати, по заявлению Рошаля, билдеровский хеап быстрее оного в VC. Более того, посмотрите CRT от VC6. Напрмиер, макрос WINHEAP в _heap_alloc_base. Так что я считаю правильнее пользоваться там, где это возможно, средставми языка, а не OC, т.к. медленее, чем в Виндовс сделать обычно сложно, если не стараться специально. Да и потенциальных проблем меньше.

Всем успехов.

я часто использую такую раелизацию
inline void *__cdecl operator new (unsigned s) {
return HeapAlloc(GetProcessHeap(), 0, s);
}

inline void __cdecl operator delete (void *d) {
HeapFree(GetProcessHeap(), 0, d);
}

Мне нравиться, у нас StromGame.dll за 10 мин в этих операторах съел <10М тактов на P3 1000

Меня эта скороть устраивает
+ нет необходимости использовать MSVCRT.DLL
+ содержимое памяти 0xBAADF00D
+ можно убить всё скопом (если вместо GetProcessHeap() написать HANDLE h = HeapCreate())
вызовом HeapDestroy()
+ никаких шар по new, delete в разных DLL, если у них HANDLE_to_heap разный
— нет совместимости со стандартом ( delete 0 — падает

программист игры Шторм, Шторм солдаты неба

Ну да, а потом появляются монстры типа Unreal2002....

Если есть возможность сделать быстрее — надо это делать (очевидно, когда требования по размеру уж очень важны, можно и нужно стараться не использовать рантайм), размер нонче не считается особенно важным, тем более что в рантайме есть много приятный функций, например, sprintf (хотя, конечно, приятно, если бинарник маленький). Иначе зачем это все вообще — и уйти писать на VB....