Управление памятью.

[impersonalis]

Используете ли вы свои реализации операторов new и delete, new[] и delete[]?

Опрос открытый.

[Mr_F_]

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

[impersonalis]

Сообщение от Mr_F_

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

Ну мне интересен именно аспект: использование нестандартных реализаций new/delete

[mr.DIMAS]

Ну мне интересен именно аспект: использование нестандартных реализаций new/delete

Проголосовал за нет. Я еще ни разу не видел необходимости писать свои new\delete. Ну разве что их можно использовать для сборщика мусора и т.п. Если беспокоят утечки памяти, то стоит использовать Visual Leak Detector чем городить что-то непонятное самому( ну или возможности CRT использовать ).

[Mr_F_]

Ну мне интересен именно аспект: использование нестандартных реализаций new/delete

перегружать смысла особо не вижу. т.е. это понятно что можно делать, только если у тебя уже гора кода с new/delete, и надо поменять политику работы с памятью ВДРУГ.
при этом через месяц уже можешь забыть где перегружено, где нет, и гадай как оно работает.
так что, имхо, - если выделяешь память нестандартным образом, то выделяй это читабельным путём, типа mem = myPool.Allocate(size).

---
проголосовал "нет", но приврал - изменял new/delete для классов, которые обязаны были быть выравнены (внутри был _aligned_malloc)

пишу, хотя это не совсем корректно называть каноничным переопределением new\delete

void AddPointer(void * pointer, const char * fileName, unsigned int lineNum, unsigned char type, unsigned int size);
void RemovePointer(void * pointer, const char * fileName, u32 lineNum, u8 type);

void * Allocate(size_t size);
void * ReAllocate(void * pointer, size_t size);
void Free(void * pointer);

#define MM_NEW(__var, __obj) \
{ \
	__var = new __obj; \
	AddPointer(__var, __FILE__, __LINE__, 0, sizeof(__obj)); \
}

#define MM_NEW_S(__obj) \
{ \
	void * __ptr = new __obj; \
	AddPointer(__ptr, __FILE__, __LINE__, 0, sizeof(__obj)); \
}

#define MM_DELETE(__var) \
{ \
	RemovePointer(__var, __FILE__, __LINE__, 0); \
	delete(__var); \
}

#define MM_NEW_A(__var, __obj, __count) \
{ \
	__var = new __obj [__count]; \
	AddPointer(__var, __FILE__, __LINE__, 1, sizeof(__obj) * __count); \
}

#define MM_NEW_S_A(__obj, __count) \
{ \
	void * __ptr = new __obj [__count]; \
	AddPointer(__ptr, __FILE__, __LINE__, 1, sizeof(__obj) * __count); \
}

#define MM_DELEMM_A(__var) \
{ \
	RemovePointer(__var, __FILE__, __LINE__, 1); \
	delete [] (__var); \
}

#define MM_NEW_P(__var, __ptr, __obj) \
{ \
	__var = new (__ptr) __obj; \
	AddPointer(__ptr, __FILE__, __LINE__, 2, sizeof(__obj)); \
}

#define MM_NEW_S_P(__ptr, __obj) \
{ \
	new (__ptr) __obj; \
	AddPointer(__ptr, __FILE__, __LINE__, 2, sizeof(__obj)); \
}

#define MM_DELEMM_P(__var, __destructor_name) \
{ \
	(__var)->__destructor_name; \
	RemovePointer(__var, __FILE__, __LINE__, 2); \
}

как плюс :
1) нету проблем с сторонними либами, потому что либа может содержать в хидерах вызов new\delete и поставляться в уже собранном виде, а мы при подключении хидера переопределим new\delete и всё сломается
2) в дебаге мы следим за каждым выделением, потому если что-то потечет то сразу узнаем где

[HolyDel]

полезно, но это:

unsigned int size

что за фигня, джимон?

стандартом не гарантируется sizeof(int) == sizeof(void*)
например в cl.exe на 64 битный платформах инт 32 битен.

делай уж все размеры связанные с выделением памяти size_t

HolyDel
помарка, виноват хотя это не так критично в данном месте, при выделении больше 4 гигов всего лишь в логе будет неверный размер