размер блока памяти, выделенного из кучи

[Алексей++]

заинтерисовался вот чем. К примеру, есть память, выдененная через new

BYTE* p=new BYTE[100];

нельзя ли, не зная числа 100 как-то узнать длину блока в байтах ? Система же откуда то знает

[McZim]

Алексей1153++, размер BYTE?

[Алексей++]

McZim, размер блока памяти p[?]

[McZim]

Алексей1153++, наверное ошибаюсь, но р указатель на блок памяти размером BYTE.

З.Ы.: пойду учить мат часть

[McZim]

Вот нашел в нете...

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

[McZim]

Алексей1153++, может все таки лучше malloc, там ты указываешь какой размер тебе необходим.

[RXL]

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

Леш, штатных методов нет.
Другой вопрос, что если затачиваться под определенную версию run-time библиотеки, то можно тупым просмотром в дебагере найти поле в блоке, предшествующем указанному, хранящее размер. MSVC, если не ошибаюсь, именно там хранит информацию о блоке.

[Алексей++]

McZim, ты вопрос не понял

меня не интерисует размер BYTE и вообще какой либо размер типа, хочь там будет

MyStruct* p=new MyStruct[100];

malloc тоже ни при чём , зная размер типа и количество выделенных элементов я всегда найду размер блока в байтах:

sizeof(*p)*100

Вопрос вот в чём: к примеру, известно, что "void* pv" - это указатель на память, выделенную из кучи (неважно, что там).
Так вот, зная только указатель - можно ли где то в системе вырыть информацию о блоке памяти - размер блока ?

[Алексей++]

Ром, дебаг идёт лесом Программа, скажем, в релизе бегает

[RXL]

Леш, ксати, ты не можешь в ф-ии ввести ограничение, чтобы передаваемый указатель указывал в динамически выделенную область, а не в автоматически или статически выделенную. Потому подобные ф-ии обычно принимают еще и параметр длины.

[zubr]

Алексей1153++, смотри в сторону Heap-функций: HeapCreate, HeapAlloc, HeapSize

[Алексей++]

zubr,

в HeapSize:
SIZE_T HeapSize(
  HANDLE hHeap,
  DWORD dwFlags,
  LPCVOID lpMem
);

hHeap  - Handle to the heap in which the memory block resides. This handle is returned by either the HeapCreate or GetProcessHeap function.

а хендл мне откуда взять, если использовано было new ?

[zubr]

Ну так используй апишные функции для своей задачи, раз такая необходимость появилась.

[McZim]

а как быть если не Windows?

[Алексей++]

zubr, слава Богу, необходимость не появилась Это просто любопытство

[marat_]

значит, всё-таки никак не узнать?

[Finch]

zubr, Это для работы с кучей, а не с операторами выделения памяти в С++. Когда запускается приложение, также иницилизируется менеджер памяти. Который запрашивает у винды кучу и там уже будет размешаться та память, которая востребуется оператором new. Насколько я знаю, штатных средств для этого не сушествует. Да вроде в стандарте не прописаны структуры менеджера памяти, так что все решения скорее всего будут очень сильно компиляторо зависимые.
Скорее всего, исходили из того, что программист, писавший программу должен сам изначально знать, сколько он выделил памяти.

[zubr]

Finch, ну это понятно, что в "чистом" C размер блока памяти знает только программист, инициализируя переменную. Но ведь в части вопроса был текст:

Система же откуда то знает

Вот от менеджера памяти (в винде) она и знает.

[Finch]

zubr, Мы наверно говорим чуть чуть о разном. Менеджер памяти винды и менеджер памяти самой программы, в моем понимании это разные веши и решают разные вопросы. И это не зависит от языка программирования.  В Linux я так далеко не копал, но так понял, что все управление памятью производится через одну библиотеку libc. По крайней мере я пока не встречал понятий кучи или чего нибудь подобного.

[npak]

Вообще говоря, код run-time для MS VC открыт - можно посмотреть непосредственно в исходниках.

В MS VC 6 рантайм сам управляет своей памятью. Библиотека языка С держит аллоцированную кучу, в которой хранится список аллоцированных блоков + свободная память. В этой опитимизации важно то, что эта память уже захвачена у операционной системы, и, следовательно, операции new/delete и malloc/free сравнительно дешевы и не увеличивают размер виртуальной памяти процесса. Разумеется, когда новый блок невозможно уместить в свободное пространство кучи, аллоцируется дополнительная память, но разбиение на блоки находится под управлением рантайма. Размер блока равен размеру запроса + 4 байта (8 байт на Win64).

В MS VC 2005 рантайм не заботится управлением блоками внутри кучи - всякий запрос на аллокацию памяти перенаправляется в вызов HeapAlloc виндового интерфейса Win32. Я провел эксперимент. Оказалось, что вызов new char[100] не изменил размер виртуальной памяти процесса. Возможно, что оптимизация по размеру блока переместилась из malloc в HeapAlloc.