|
|
|
освобождение памяти в функции после return
|
|||
|---|---|---|---|
|
#18+
Давно не работал с си++ так что извиняйте за (может быть) не умный вопрос перешел на .NET и забыл про управление памятью... Вопрос заключается в следующем Есть функция вида (все это находится в dll -ке написанной с помощью VC++6 char * send(char * Buffer) { //Здесь происходит выделение буффера наверно с помощью оператора new(буфер типа void *) char * result= этот буфер... далее нужно вернуть этот буфер .... return result но удалить его нужно здесь после return можно ли это сделать как-то ???? (может с помощью finally )или нет ? Какие есть варианты ? } ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2007, 14:27 |
|
||
|
освобождение памяти в функции после return
|
|||
|---|---|---|---|
|
#18+
вы возвращаете указатель на выделенную внутри функции область памяти.... если бы вам тут ее удалось грохнуть, то что с этим указателем должен делать вызвавший функцию управляющий код? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2007, 15:03 |
|
||
|
освобождение памяти в функции после return
|
|||
|---|---|---|---|
|
#18+
нужно в dll завести free_buffer функцию в которую из клиентского кода передавать ссылку на буфер после того как он стал ненужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2007, 15:14 |
|
||
|
освобождение памяти в функции после return
|
|||
|---|---|---|---|
|
#18+
Спасибо ... так в принципе и думал сделать думал есть какой-то более изящный метод.... (уж слишком пресытился .NET кодом... -) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2007, 15:28 |
|
||
|
освобождение памяти в функции после return
|
|||
|---|---|---|---|
|
#18+
schmidt1234 wrote: > //Здесь происходит выделение буффера > наверно с помощью оператора new(буфер типа void *) > char * result= этот буфер... > далее нужно вернуть этот буфер .... > return result вы выделяете буфер при помощи, например new. Тогда, если вы его освободите внутри функции, получатель буфера получит AccessViolation при попытке его прочитать. Вывод - буфер должен освобождать получатель. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2007, 16:59 |
|
||
|
освобождение памяти в функции после return
|
|||
|---|---|---|---|
|
#18+
schmidt1234Спасибо ... так в принципе и думал сделать думал есть какой-то более изящный метод.... (уж слишком пресытился .NET кодом... -) Есть. Могу предложить такой, если можете менять исходники библиотеки. Для char * можно сделать объект прокси, который будет хранить ваш указатель. Для него будет необходимо добавить оператор преобразования типа к char *. Схема действий следующая. send возвращает этот объект, который преобразовывается к указателю и отдает указатель. Далее он используется в этом же операторе, потом временный объект удаляется, освободая память. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2007, 09:26 |
|
||
|
освобождение памяти в функции после return
|
|||
|---|---|---|---|
|
#18+
Вот пример: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. результат A::opeator char* text string A::~A В функции func использовался конструктор A с одним аргументом, как оператор преобразования типа. Поэтому вам в фунции даже ничего не прийдется менять. При выводе же использвовался неявный преобразователь типа operator char*(). На счет хранения указателя как const, возможно я не прав, т.к. объект изменяет переданные ему данные, в следствии чего в деструкторе пришлось применять оператор снятия const с данных. Но это мелочи. Можно рассмотреть варианты со стандартными интеллектуальными указателями, но они имеют, имхо, больше недостатков, по сравнению с данным классом в текущей области применения.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2007, 09:48 |
|
||
|
освобождение памяти в функции после return
|
|||
|---|---|---|---|
|
#18+
Akh Можно рассмотреть варианты со стандартными интеллектуальными указателями, но они имеют, имхо, больше недостатков, по сравнению с данным классом в текущей области применения.. не подходит такой вариант Если учесть, что автор говорил, что эта функция должна быть в dll, то любая RAII обертка, при условии, что буффер выделяется в библиотеке, а освобождается клиентским кодом, может приветсти к куче проблем плюс к падению программы из-за возможного различия рантайм библиотек. так что так... поэтому лучше в dll память и освобождать. и ещё хороший вопрос, как из dll вызвращать объекты класса, кроме как не по указателю:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2007, 11:43 |
|
||
|
освобождение памяти в функции после return
|
|||
|---|---|---|---|
|
#18+
daevaorn Akh Можно рассмотреть варианты со стандартными интеллектуальными указателями, но они имеют, имхо, больше недостатков, по сравнению с данным классом в текущей области применения.. не подходит такой вариант Если учесть, что автор говорил, что эта функция должна быть в dll, то любая RAII обертка, при условии, что буффер выделяется в библиотеке, а освобождается клиентским кодом, может приветсти к куче проблем плюс к падению программы из-за возможного различия рантайм библиотек. так что так... поэтому лучше в dll память и освобождать. и ещё хороший вопрос, как из dll вызвращать объекты класса, кроме как не по указателю:) Ну, на счет памяти вы погорячились, конечно. Т.к., кто вым сказал, что память будет освобождаться не dll кодом? А вот, возвращение объекта по значению, совсем другое дело. Здесь, конечно, не приветсвуется передача даных кроме простых встроенных типов. Но, думаю, что для определенных сочетаний компиляторов (dll и exe) передача по значению будет корректна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2007, 11:56 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=34630648&tid=2028584]: |
0ms |
get settings: |
8ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
157ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
| others: | 214ms |
| total: | 472ms |

| 0 / 0 |
