**int _CrtIsValidHeapPointer() - verify pointer is from 'local' heap
*
*Purpose:
* Verify pointer is not only a valid pointer but also that it is from
* the 'local' heap. Pointers from another copy of the C runtime (even in the
* same process) will be caught.
*
*Entry:
* const void * pUserData - pointer of interest
*
*Return:
* TRUE - if valid and from local heap
* FALSE otherwise
******************************************************************************
---
Одно-единственное НО - все-таки если и exe, и dll пишутся в рамках одного комплекса, то я не вижу смысла в статической линковке с рантаймом. Ну а при динамической линковке все сработает без проблем.
The GlobalAlloc function allocates the specified number of bytes from the heap. In the linear Win32 API environment, there is no difference between the local heap and the global heap.
так что куча одна на всех. А конкретная реализация malloc - это дело компилятора имхо. И если кроме GlobalAlloc при этом ваша программа помечает гдето у себя что этот кусок выделен malloc'ом - то естественно длл не сможет его освободить. это тока мое имхо, а проверять на деле - влом. Мот те кто уже накомпилял dll и exe попробую вместо malloc и (это вообще изврат) new/delete заюзать GlobalAlloc / VirtualAlloc -самому интересно.
Лучше HeapAlloc26.02.03 14:13 Автор: amirul <Serge> Статус: The Elderman
> The GlobalAlloc function allocates the specified number of > bytes from the heap. In the linear Win32 API environment, > there is no difference between the local heap and the > global heap. > так что куча одна на всех. А конкретная реализация malloc - > это дело компилятора имхо. И если кроме GlobalAlloc при > этом ваша программа помечает гдето у себя что этот кусок > выделен malloc'ом - то естественно длл не сможет его > освободить. это тока мое имхо, а проверять на деле - влом. > Мот те кто уже накомпилял dll и exe попробую вместо malloc > и (это вообще изврат) new/delete заюзать GlobalAlloc / > VirtualAlloc -самому интересно. Но весь сыр-бор из-за того, что у майкрософта руки кривые сделать СТАНДАРТНУЮ библиотеку так, чтоб она работала как описано в спецификации. GetProcessHeap использовать можно, но она не стандартизирована ANSI. Вот и вспоминается анекдот про то, что мелкософту легче объявить темноту новым стандартом, чем вкрутить лампочку.
[C++] Да, будет.25.02.03 10:38 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
А в чем собственно сомнения? Ну отхватила вызываемая функция кусок памяти, передала начальный адрес вызывающей функции, а та освободила его. Функции free побарабану кто вызывал malloc, ей передали адрес куска, который высвободить надо, она и освобождает. Главное, чтобы этот кусок был распределен функцией malloc или calloc, но не alloc. В противном случае выползет какая-нибудь ошибка, или будет все благополучно, если free этот кусок проверит (симантековская функция это делает v7.2).
[C++] Да, будет.25.02.03 13:49 Автор: chaka Статус: Незарегистрированный пользователь
Это будет работать за исключением одного сценария: если функция, выделяющая память находится в dll (win32), то попытка освободить эту память из функции, находящейся в .exe-модуле приведет, к тому, что память была веделена из одной кучи, а освобождена в другой. И вот тогда ой!
Да ты что ?!25.02.03 16:13 Автор: PS <PS> Статус: Elderman
> Это будет работать за исключением одного сценария: если > функция, выделяющая память находится в dll (win32), то > попытка освободить эту память из функции, находящейся в > .exe-модуле приведет, к тому, что память была веделена из > одной кучи, а освобождена в другой. И вот тогда ой!
Правда что ли ?
А можно поподробней о разных кучах ? А может у dll и exe вообще разные адресные пространства ? Может указатели из ф-ий dll в ф-ии exe и передавать то нельзя ?
Да ты что ?!25.02.03 17:05 Автор: cb <cb> Статус: Member
все зависит от реализации run-time библиотек которые ты используешь - run-time от msvc ведет себя следующим образом:
- при статической линковке run-time библиотек каждый собранный модуль (dll/exe) получает собственную кучу откуда выделяется память (malloc/alloc), соответственно при попытке освободить память в модуле отличном от того в котором эта память была выделена - приведет к ошибке.
- если же run-time библиотека линкуется как внешняя dll - то у этой dll будет своя собственная куча и соответсвенно память будет браться всегда из нее и приблем с выделением/освобождением не будет...
В общем-то на мой взгляд память должна быть освобождена тем кто ее выделял - это как минимум безопасней...
> Может указатели из ф-ий dll в ф-ии exe и передавать то нельзя ?
см. выше.
cb.
Посмотрел на календарь...25.02.03 18:04 Автор: PS <PS> Статус: Elderman
> все зависит от реализации run-time библиотек которые ты > используешь - run-time от msvc ведет себя следующим > образом: > - при статической линковке run-time библиотек каждый > собранный модуль (dll/exe) получает собственную кучу откуда > выделяется память (malloc/alloc), соответственно при > попытке освободить память в модуле отличном от того в > котором эта память была выделена - приведет к ошибке.
Бред. Даже не поленился сейчас тестик написать. Все работает нормально (что и не удивительно). В противном случае куча проектов бы давно отвалились, это раз, а два: весь COM основан на передаче указателей между модулями (мы говорим сейчас об одном процессе ! так что, умных слов типа "маршалинг" - не надо !).
> - если же run-time библиотека линкуется как внешняя dll - > то у этой dll будет своя собственная куча и соответсвенно > память будет браться всегда из нее и приблем с > выделением/освобождением не будет... >
ничего не понял.
> В общем-то на мой взгляд память должна быть освобождена тем > кто ее выделял - это как минимум безопасней...
> Бред. Даже не поленился сейчас тестик написать. Все > работает нормально (что и не удивительно). В противном > случае куча проектов бы давно отвалились, это раз, а два:
Вот это уже обидно. Зачем сразу бред? Ты действительно сделал, проверил, работает. Отлично, а теперь запусти тоже самое но под отладчиком (или просто debug-версию) и получишь объяснение моего бреда. - Assertion Failed! _CrtIsValidHeapPointer(pUserData). А в релизе, где у тебя все работает - ты освобождаешь кусок адресного пространства в куче исполняемого модуля и раз "у тебя все работает", то довольно успешно, но, вот когда кто-то в этом исполняемом модуле совершенно случайно вместо своих данных в куче найдет там "бред", то не обижайся, просто, при освобождении памяти, выделенной в dll ты с чистой совестью грохнул данные, предназначенные совершенно для других целей (им просто не повезло, они находились по тому же (или смежному) адресу, что и данные, выделенные в dll, только в ДРУГОЙ КУЧЕ).
P.S. А если у тебя никаких предупреждений не всплывет в debug-версии программы, то, возможно ты компилируешь exe и dll-модули, связанные с библиотекой времени выполнения по динамике, ну, а если crt у тебя скомпонована по статике, то советую подумать о смене компилятора или замене библиотеки времени выполнения (CRT).
> весь COM основан на передаче указателей между модулями (мы > говорим сейчас об одном процессе ! так что, умных слов типа > "маршалинг" - не надо !).
Весь COM построен на принципе подщета ссылок, а не передаче указателей.
В результате подсчета ссылок если Release() возвращает 0, то память, выделенная под объект, освобождается, но это происходит в коде того модуля, КОТОРЫЙ ВЫДЕЛИЛ память под класс. Это происходит потому, что фабрика по созданию объектов и сам объект (который сам себя уничтожает) находятся в ОДНОМ модуле (exe или dll)
> Даже не поленился сейчас тестик написать. Все > работает нормально (что и не удивительно).
в студию....
> В противном > случае куча проектов бы давно отвалились, это раз, а два: > весь COM основан на передаче указателей между модулями (мы > говорим сейчас об одном процессе ! так что, умных слов типа > "маршалинг" - не надо !).
никаких умных слов - я их просто не знаю...
> ничего не понял.
"учите матчасть" (C).
> Это верно, но на счет Dll и Exe - полный бред.
см. выше.
cb.
В студию так в студию...25.02.03 18:29 Автор: PS <PS> Статус: Elderman
1. Exe делаешь MFC Wizard'ом. На диалоге. На OnOk Пишишь простейший код:
void CTestDllAllocExeDlg::OnOK()
{
char* m = myalloc();
free( m );
MessageBox( "OK" );
CDialog::OnOK();
}
---
2. Dll делаешь тоже визардом (что б долго не трахаться) и заводишь в ней одну ф-ию:
char* myalloc()
{
return (char*)malloc( 10 );
}
---
И ты хочешь сказать, что эта хрень не работоспособна ?
P.S. А если криворукие программеры из Борладна не умеют писать свой инструментарий под ОС от Microsoft, и их dll начинает конфликтовать с exe или dll созданом на других инструментах - то тут только можно развести руками.
[C++] В студию так в студию...25.02.03 18:56 Автор: chaka Статус: Незарегистрированный пользователь
**int _CrtIsValidHeapPointer() - verify pointer is from 'local' heap
*
*Purpose:
* Verify pointer is not only a valid pointer but also that it is from
* the 'local' heap. Pointers from another copy of the C runtime (even in the
* same process) will be caught.
*
*Entry:
* const void * pUserData - pointer of interest
*
*Return:
* TRUE - if valid and from local heap
* FALSE otherwise
******************************************************************************
---
Одно-единственное НО - все-таки если и exe, и dll пишутся в рамках одного комплекса, то я не вижу смысла в статической линковке с рантаймом. Ну а при динамической линковке все сработает без проблем.
все так25.02.03 19:24 Автор: chaka Статус: Незарегистрированный пользователь
Статику я использую из следующих соображений:
проекты, как правило, пишуться и отлаживаются с одним crt-шником, но работают потом где угодно. Я не мог даже предположить, на какие машины заказчики умудраются ставить потом это ПО (от первых пней и до пром-машин у которых оперативки больше чем у меня винчестера), так что и операционные системы, даже в пределах win32 у конечного пользователя тоже варьюруются, поэтому для уверенности в том что все мои глюки это исключительно мое творение - я компонуюсь по статике (потому что включать в инсталяху еще и crt - это не очень хорошая идея). Хотя, конечно, раздувание проекта таким образом мне не очень по душе, но более веских аргументов для использования динамической компоновки у меня пока нет. Если кто убедит - буду признателен :)
> Статику я использую из следующих соображений: > проекты, как правило, пишуться и отлаживаются с одним > crt-шником, но работают потом где угодно. Я не мог даже > предположить, на какие машины заказчики умудраются ставить > потом это ПО (от первых пней и до пром-машин у которых > оперативки больше чем у меня винчестера), так что и > операционные системы, даже в пределах win32 у конечного > пользователя тоже варьюруются, поэтому для уверенности в > том что все мои глюки это исключительно мое творение - я > компонуюсь по статике (потому что включать в инсталяху еще > и crt - это не очень хорошая идея). Хотя, конечно, > раздувание проекта таким образом мне не очень по душе, но > более веских аргументов для использования динамической > компоновки у меня пока нет. Если кто убедит - буду > признателен :)
Я предпочитаю именно вставлять crt в дистрибутив :) Естественно, не копируя его в системный каталог. Плюсы - при активном использовании функций из crt получаем выигрыш по памяти, получаем уменьшенный размер апдейтов, ну и не спотыкаемся на такие вот неочевидные глюки.
все так25.02.03 19:52 Автор: chaka Статус: Незарегистрированный пользователь
Это неплохое решение, но для меня оно выглядит не более убедительным чем, скажем увеличение размера и т.д. Дело в том, что мое участие в проектах как правило сводится к написанию библиотек, следовательно бал заказывают разработчики исполняемых модулей, по этому статика в нашей организации - своего рода традиция, а менять тардиции по пустякам, как правило никто не хочет :)
> Это неплохое решение, но для меня оно выглядит не более > убедительным чем, скажем увеличение размера и т.д. Дело в > том, что мое участие в проектах как правило сводится к > написанию библиотек, следовательно бал заказывают > разработчики исполняемых модулей, по этому статика в нашей > организации - своего рода традиция, а менять тардиции по > пустякам, как правило никто не хочет :)
Оно, конечно, дело вкуса, но просто меня бы жаба задушила, глядючи как десяток мелких dll занимается инициализацией рантайма и на ровном месте отжирает лишний мегабайт-другой :)
а вот25.02.03 19:34 Автор: PS <PS> Статус: Elderman
Да я не сомневаюсь, что у них все есть, я имею ввиду ВЕРСИИ, клиент может обладать версией библиотеки, отличной от той, с применением которой тестировалось ПО, по этому я компонуюсь по статике, чтобы быть уверенным, что си-библиотека времени выполнения работает так, как она работала у меня. И это не значит, что в этой библиотеке были или будут ошибки, это лишь значит то, что на своей версии crt я ТЕСТИРОВАЛ свое програмное обеспечение и если я, скажем что то сделал не так и МОЯ версия crt-это пропустила (т.е. это небыло вызвано побочных явлений), то я хочу, чтобы так было и впредь. Вот и все!!!