Выделение памяти...

Ursus
А зачем всё сообщение-то цитировать было?

Ну это действительно не серьёзно. Даже близко не адекватный пример.

Мы вообще о чём говорим? О методах работы системы с памятью или о средствах, предоставляемых C++. C++ здесь явно не причём. А если Вы об объектах системы/ядра, то и так очевидно, что их нужно освобождать специально предназначеными для этого ф-иями. Ну и наконец, если Вы вдруг решили, что я предлагаю уничтожать дефолтную кучу процесса, то Вы неправы. Наоборот, я говорил о том, что, возможно, создавать свою собственную кучу бывает удобно чаще, чем использовать дефолтную, потому как освобождать дефолтную обычным HeapDestroy очень чревато, а свою можно и удобно.

 

на самом деле в своем хипе можно разместить очень даже сложные списки

банальный пример, скажем есть простой связанный список:

Код (Text):

1. struct test
2. {
3.    char* String0;
4.    char* String1;
5.    char* String2;
6.    char* String3;
7.    int integer1;
8.  
9.   test* pnext;
10. }

гораздо удобний убить кучу, чем циклится и делать хип фри для String0-3, хип фри для самой структуры. при чем на этом хипе может быть созданно множесто различных структур, деревьев или еще чего и чистить память за ними нужно будет лишь 1 коммандой вместо множества процедур.

что касается VirtualAlloc, то она при использовании малого кол-ва памяти - избыточна, а когда требуется большой блок, хип функции винды сами выделят память именно с помощью VirtualAlloc, это описанно в куске из msdn выше

 

l_inc

Скачай полный исходный код в первом посте и открой file.bk, затем открой class.book.inc и сравни секции, в вкратце, если лень копать, то файл состоит из заголовка:

Код (Text):

1. struct BOOK32_HEADER                    ; Заголовок:
2.         signature       db 'BKnew',0    ;  Подпись "BKnew",0
3.         password        dd 0            ;  Пароль
4.         preferred       dd 0            ;  привелегии
5.         count           dd 0            ;  Кол-во секций
6. ends

затем у нас идет массив структур BOOK32_TABLE_ITEM, который я называю просто таблицой:

Код (Text):

1. struct BOOK32_TABLE_ITEM                ; Элемент таблицы описания страниц:
2.         title           db 30 dup (0)   ;  Заголовок
3.         color           dd ?            ;  Цвет
4.         seek            dd ?            ;  Начало текста в файле книги
5. ends

после чего у нас идет массив состоящий из BOOK32_SECTION и текста:

Код (Text):

1. struct BOOK32_SECTION                   ; Секция:
2.         preferred       dd ?            ;  Привелегии
3.         handle          dd ?            ;  Указатель блока памяти для древовидной структуры
4.         lengthof        dd ?            ;  Кол-во байтов в тексте
5.         buffer          dd ?            ;  Буфер для текста, текст идет срузу после структуры
6. ends

так вот в BOOK32_SECTION.handle я перемещаю HGLOBAL, а в BOOK32_SECTION.buffer указатель на буфер, а затем копирую текст, выполнение процедуры открытия файла file.bk длиться сотые секунды для одного элемента...

 

dgs
Прочитал два раза Ваш пост, но так и не понял, к чему он. Это вопрос или замечание?

 

Я это к чему вел, да к тому если в файле 2000 секций, значит и 2000 таблиц и если в каждый секции записано по 1кб текста, то файл получаеться 18б + 38б * 2000 + 16б * 2000 + 1кб * 2000 = 2105кб, это я первый раз выделяю память, затем еще 2000 раз по циклу в треде создаю миниатюрные блоки и затем выделяю еще один, который будет содержать в себе массив адресов и заполним его с помощью DWORD GetProcessHeaps( DWORD dwNumHeaps, PHANDLE pHeaps); и я нутром чуствую, что программа будет не стабильна, может кто даст совет по таким родам задач, с которой я столкнулся? Может как-то проще все можно сделать?

 

Проще вам не подходит, программа по любому должна быть кривая и глючить)

 

Хе... CrystalIC +1

Ребята большое спасибо, очень помогли...

 

Такие ситуации - это не проблема Windows. Скорее проблема написанного кода.

 

AsmGuru62
И винда кривая и код кривой всюду. Помню приличная софтина(_http://jacquelin.potier.free.fr/winapioverride32/) выносилась простым завершение удалённых потоков, изза бага в функции получения слепков. Интересно было смотреть как чужой процесс пытается считать список куч и изза этого приложение падает, да не хило так падает )))

 

А плохому танцору тестикулы мешают, ага

 

Ursus

он правильно сказал - а ты оскорблять начал

 

Хто, я? Даже и не думал никого оскорблять.
И мой ответ по уровню смысловой нагрузки совершенно адекватен его высказыванию

 

Что еще можно ответить на утверждение, что "отладочный останов изза "Heap corrupt detected"" - это из-за того, дескать, что в винде хип устроен слишком сложно ?

 

Ursus
теперь нормально сказал, сразу бы так

 

Ursus
Я знаю почему, это пример был. В отличае от тебя я отлично понимаю что усложнение кода влечёт обычно за собой уменьшение стабильности.

Да, именно поэтому. Те кто создал этот функционал не могли не допустить ошибок по причине высокой запутанности кода.

Для меня ты шелуха, которой тут на форуме множество. Даже просмотрев твои посты, никакого мнения о тебе не могу составить, а твоё мнение как очередного школьнега ничто.

 

О-о, похоже, мальчег всеръез обиделсо, раз пошли оскорбления.

 

Дорогуша, это только школьнег мог сказать, что heap corruption detected - это проблема виндового менеджера хипа.
Потому как даже самый зеленый профессионал знает, что это - проблема кривых рук кодера, допустившего перезапись за пределами выделенног блока памяти. Ы?