Break. Гы?

Здравствуйте, 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().

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

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

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

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

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

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

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

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

[]

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

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

А>Не надо меня учить как жить!

Ага, лутше помогите материально.

А>Вопрос поставлен абсолютно некорректно, и ежели он бы меня заинтересовал, я бы высказался более подробно.

Ежели не заинтересовал, зачем отвечать?
Даже ежели вопрос не корректен (а ето действительно так), то ето не повод некорректно на него отвечать.

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

И эти _в_том_числе.

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, а о операторах. Операторы только выделяют или освобождают сырую память. Никаких побочных действий. И по скорости два варианта практически равны.

Здравствуйте, 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 конструкторов не вызывает
Так что это вопрос на логику

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

А>Мой ответ означает лишь, то что сабжевые операторы по умолчанию всегда используют средства выделения памяти, предоставляемые системой. 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....

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

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

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

Кто сказал что это работает медленно ?

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

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

А>хъ

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

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

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

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

Ёоу!!! Алекс, ты читаешь че-нить из постингов?

Господа, чтобы говорить предметно, рекомендую всем почитать Heap: Pleasures and Pains и другие статьи из этого же раздела.

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

[]

P>И эти _в_том_числе.

Спасибо, что напомнил.

Ну вот, поругались, друг другу нулей понаставили... А в результате? Может, проще было тест работы с хипом написать, и проверить на различных компилерах, системах etc. Привести эти данные — вот тогда было бы о чем поговорить, это и правда интересно... Кстати, где то уже подобная статья проскакивала. Но давно дело было.

Успехов и давайте жить дружно.

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

[]

AS>Успехов и давайте жить дружно.

А я со всеми живу дружно, кроме тех, кто со мной не дружит.

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

[]

P>>И эти _в_том_числе.

А>Спасибо, что напомнил.

Незачто

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

AS>Ну вот, поругались, друг другу нулей понаставили... А в результате? Может, проще было тест работы с хипом написать, и проверить на различных компилерах, системах etc. Привести эти данные — вот тогда было бы о чем поговорить, это и правда интересно... Кстати, где то уже подобная статья проскакивала. Но давно дело было.

Вроде ето уже обсуждалось http://www.rsdn.ru/Forum/Message.aspx?mid=32309&amp;only=1

Автор:
Дата: 28.02.02

. Правда линк, который дается, дохлый.

Судя по заданному вопрсу человек не понимает что езть такое new и delete в принципе. Иначе етот вопрос задавался бы несколько по иному. И поетому я посчитал, что отвечать ему в форме сабж: equal несколько не правильно. На что я и обратил внимание (и не только я, кстати). А товарисч Алекс видать глыбоко абыделся и атамстил. Ну, да ето его дело.

AS>Успехов и давайте жить дружно.

Ага

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

хъ

P>Судя по заданному вопрсу человек не понимает что езть такое new и delete в принципе. Иначе етот вопрос задавался бы несколько по иному. И поетому я посчитал, что отвечать ему в форме сабж: equal несколько не правильно.

Несколько не правильно нуля не стоит.

P>На что я и обратил внимание (и не только я, кстати). А товарисч Алекс видать глыбоко абыделся и атамстил. Ну, да ето его дело.

Да не то чтобы очень глубоко. На кого обижаться-то? И на что?

P>Ага

Если бы ты по меньше нулей ставил, все и так бы жили дружно.

З.Ы. 2Модератор: Сори за офтопик.

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

R>SUBJ

Круто заданный вопрос, ничего не скажешь, столько народу тут из-за него передралось, нолики друг другу понаставили.

А ставить-то их нужно вам, драгоценный reptile.

И вообще, провокаторов в истории, бывало, на реях вешали .

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

[]

P>>Судя по заданному вопрсу человек не понимает что езть такое new и delete в принципе. Иначе етот вопрос задавался бы несколько по иному. И поетому я посчитал, что отвечать ему в форме сабж: equal несколько не правильно.

А>Несколько не правильно нуля не стоит.

Полуправда суть хужее чем не правда. (с) не помню, народ наверное.

P>>На что я и обратил внимание (и не только я, кстати). А товарисч Алекс видать глыбоко абыделся и атамстил. Ну, да ето его дело.

А>Да не то чтобы очень глубоко. На кого обижаться-то? И на что?

Зачем тогда изволили _мне_ нули поставить? В чем я не прав?

P>>Ага

А>Если бы ты по меньше нулей ставил, все и так бы жили дружно.

Я свой обосновал. Слово за Вами.

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

[]

KP>Кто сказал что это работает медленно ?

Ну, ежели выделения\добавления не так много, или память там экономить, то наверное покатит. А иначе, как по твоему, зачем такое понятие как Memory Pool?

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

[]

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

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

[]

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

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

P>Ну, ежели выделения\добавления не так много, или память там экономить, то наверное покатит. А иначе, как по твоему, зачем такое понятие как Memory Pool?

Pool — понятие для тех, кто считает что тот или иной метод выделения памяти по их мнению медленный

Как тут правильно заметили, все эти разговорчики никчему пока не будет общего теста на производительнось

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

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

P>>Ну, ежели выделения\добавления не так много, или память там экономить, то наверное покатит. А иначе, как по твоему, зачем такое понятие как Memory Pool?

А>Pool — понятие для тех, кто считает что тот или иной метод выделения памяти по их мнению медленный

Пацчему именно выделение? На удаление объектов тоже стоит обратить внимание.

А>Как тут правильно заметили, все эти разговорчики никчему пока не будет общего теста на производительнось

Каккого такого общего теста производительности? operator new vs HeapAlloc? Ето то же самое что my_super_puper_alloc vs HeapAlloc. Еще раз, new бывает разный. Тогда уж надо говорить operator new, который в стандартной поставке MS Visual C++, который релизный, который ... (нужное вписать) vs HeapAlloc.