Вот вопрос...

[iGrok]

Насчёт строк. Выделяй globalalloc'ом, и освобождай globalfree. И никаких проблем.
Другой вопрос, что хорошим тоном, вроде как, считается освобождение памяти на том же уровне, где она выделялась, но это не аксиома.

[Хакер]

Насчёт строк. Выделяй globalalloc'ом, и освобождай globalfree. И никаких проблем.

Буэ, она устарела.

Канонические решения здесь такие:

1. Вызываемая функция не выделяет память, а получает указатель на (заранее выделенный вызывающей стороной) буфер. И пишет туда, если размер подходящий. Соответственно, отвечает за буфер вызывающая сторона.
2. Для любой функции, которая что-то выделяет, создаётся парная функция, которая это что-то уничтожает. CreateXXX/DestroyXXX.
3. В COM исповедуется концепция аллокатора: есть объект-аллокатор, поддерживающий интерфейс IMalloc. И вызывающая, и вызываемая сторона владеет аллокатором, так что память, выделенная в вызываемой стороне, может быть спокойно высвобождена в вызывающей вызовом к тому же аллокатору. Причём аллокаторов может быть много.

[SLIM]

Вызываемая функция не выделяет память, а получает указатель на (заранее выделенный вызывающей стороной) буфер. И пишет туда, если размер подходящий. Соответственно, отвечает за буфер вызывающая сторона.

Да, но я вот говорю что нет гарантии (теоретически) что вызывающая сторона правильно сможет очистить буфер. Вдруг это будет программа на Java, сможет ли она корректно освободить участок, созданный с помощью malloc на C++?

Для любой функции, которая что-то выделяет, создаётся парная функция, которая это что-то уничтожает. CreateXXX/DestroyXXX.

Этот вариант я описал, но немного иначе. Только не парную функцию создавать, а одну функцию по очистке памяти, которая разом все очистит. Просто я представил как было бы программировать если бы на каждую выделяющую внешнюю функцию пришлось бы вызывать дополнительно другую. А если их 100, получается нужно еще 100 для очистки памяти. Много однако

В COM исповедуется концепция аллокатора: есть объект-аллокатор, поддерживающий интерфейс IMalloc. И вызывающая, и вызываемая сторона владеет аллокатором, так что память, выделенная в вызываемой стороне, может быть спокойно высвобождена в вызывающей вызовом к тому же аллокатору. Причём аллокаторов может быть много.

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

Я вот вспомнил концепцию WIN API, а именно функции, которые возвращают указатели на какие-то буфера. Все таки высвобождение перекладывается на вызывающий сторону всегда. Они же не боятся что что-то произойдет не так. Почему? Ведь функции API могут использоваться везде. Почему MS не боится что произойдет неверная очистка памяти.
Хотя, если опять таки вспомнить, для строк мы передаем вызывающей стороне уже готовый буфер, а иногда, с указанием размера того буфера. Тогда проблем не должно возникать. Мы передаем всего лишь указатель на кусочек памяти, и предлагаем его заполнить вызываемой стороне. Вызываемая сторона не работает с памятью вовсе, а просто заполняет буфер. Причем если не вошло - это проблема вызывающей стороны.
Вот кажется одно из решений

[Хакер]

Да, но я вот говорю что нет гарантии (теоретически) что вызывающая сторона правильно сможет очистить буфер. Вдруг это будет программа на Java, сможет ли она корректно освободить участок, созданный с помощью malloc на C++?

Ну ты трудный фантазёр. У тебя вызывающая сторона на Java или на С++. Уж определись, ибо одновременно быть написанной на обоих языках она не может.

Только не парную функцию создавать, а одну функцию по очистке памяти, которая разом все очистит

Эталон кривизны и дебилизма.

[Twister]

Прежде чем задаваться такими вопросами, стоит поглядеть на то, как это организовано в ОС. А организовано оно двумя способами, которые перечислил Хакер. И это вполне обосновано и логично. Выделять же память на вызываемой стороне можно только в том случае, если сторона вызывающая использует аналогичные методики memory-management'а.

Ну, а по поводу "одной функции, которая разом все очистит", это конечно бред. Как ты представляешь себе её работу? Смотри: у тебя выделено 100 кусков памяти, 50 из них еще в работе, 50 уже не нужны. Тебе нужно отдать свободную память. Как ты это сделаешь?

[SLIM]

Ну, а по поводу "одной функции, которая разом все очистит", это конечно бред. Как ты представляешь себе её работу? Смотри: у тебя выделено 100 кусков памяти, 50 из них еще в работе, 50 уже не нужны. Тебе нужно отдать свободную память. Как ты это сделаешь?

В смысле отдать? Освободить?

Ну алгоритм примерно следующий
В библе
1. Заводим глобальный массив указателей, изначально каждому присваиваем NULL
2. Как только какая-то ф-я из библы резервирует память, она передает указатель на нее куда-то во вне - в вызывающую сторону, и копирует указатель в первый свободный элемент того самого массива. Определить следующий свободный можно просто проверкой на NULL.
3. Так, функции все выделяют и выделяют - сколько хотят. Но будет одна единственная функция, реализованная в самой библе, которая пройдется по всему массиву, освободит память по указателям память и опять за' NULL-ит указатели. Такую функцию можно периодически вызывать для подчистки памяти.

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

Выделять же память на вызываемой стороне можно только в том случае, если сторона вызывающая использует аналогичные методики memory-management'а.

Вот и я о том же. Поэтому нельзя позволить чтобы память выделялась в вызывающей стороне в принципе. Потому что это библиотека, и не известно где она будет юзаться.

Прежде чем задаваться такими вопросами, стоит поглядеть на то, как это организовано в ОС. А организовано оно двумя способами, которые перечислил Хакер.

Я не спорю. Я в предыдущем посте описал один из методов, просто сначала невнимательно прочитал. Но вот по поводу второго пункта Хакера - я такого в ОС не помню.

Ладно, значит так оно и есть.

Было еще пару доп. вопросов. Кто-нибудь ответит?


UPD::

Выделять же память на вызываемой стороне можно только в том случае, если сторона вызывающая использует аналогичные методики memory-management'а.

Опа...это где такое написано то? Может наоборот, выделять нельзя в вызывающей стороне а не в вызываемой?

[Хакер]

Но вот по поводу второго пункта Хакера - я такого в ОС не помню.

CreateWindow/DestroyWindow
CreateProcess/TerminateProcess
CreateThread/TerminateThread
Ну и т.п.

[Twister]

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

Видать, решение самого первого вопроса в этом топике тебе на ус не намоталось. Напомню: память может освободиться еще до того, как её к себе скопируют. Твоя же функция по очистке это сделает. Да и вообще, что за ересь? Ты так и будешь описывать работу своей библиотеки - "вызывающая сторона должна как можно быстрее скопировать память к себе, так как в любой момент её может уже не быть"? Прежде чем начинать изобретать свой "сборщик мусора" подумай, а зачем он вообще здесь?

Опа...это где такое написано то? Может наоборот, выделять нельзя в вызывающей стороне а не в вызываемой?

Нет, как раз-таки память выделять и освобождать рекомендовано на вызывающей стороне. Я не опечатался. Мало того, я рекомендовал обратить внимание на то, как это реализовано в ОС. Второй пункт ты точно не разбирал, раз вынудил Хакера привести примеры, а теперь я вижу, что и первый не осилил.

Давай посмотрим на GetClassName, к примеру. Второй её параметр - указатель на блок памяти, в котороый ляжет имя класса окна. Т.е. твой код (вызывающая сторона) выделяет память и передаёт указатель на неё в функцию (вызываемая сторона). Функция делает что надо и возвращает тебе управление. Ты делаешь что надо и освобождаешь память.

[SLIM]

Видать, решение самого первого вопроса в этом топике тебе на ус не намоталось. Напомню: память может освободиться еще до того, как её к себе скопируют. Твоя же функция по очистке это сделает. Да и вообще, что за ересь? Ты так и будешь описывать работу своей библиотеки - "вызывающая сторона должна как можно быстрее скопировать память к себе, так как в любой момент её может уже не быть"? Прежде чем начинать изобретать свой "сборщик мусора" подумай, а зачем он вообще здесь?

Я не настаиваю делать так как я говорю. Это лишь один из вариантов. Замечания вполне оправданные, и теоретически есть вероятность того что до того как произойдет копирование памяти она будет освобождена. Но очень маленькая. По поводу описания библиотеки тоже согласен. Это выглядит не очень.

Нет, как раз-таки память выделять и освобождать рекомендовано на вызывающей стороне. Я не опечатался. Мало того, я рекомендовал обратить внимание на то, как это реализовано в ОС. Второй пункт ты точно не разбирал, раз вынудил Хакера привести примеры, а теперь я вижу, что и первый не осилил.

Это я неверно прочитал. Вызывающий-вызываемая. Попутал что у Хакера что у тебя. Я все прекрасно понимаю.

Как бы я многое из топика здесь прекрасно понимаю, а получается что я вообще даун. Просто недопонял.