Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
утечка памяти
|
|||
|---|---|---|---|
|
#18+
Взял листинг кода из книги Стивен Прата Язык программирования С++. Меня терзают смутные сомнения нет ли здесь утечки памяти, указатель, определенный в функции buildstr в куче, не очищается в ней. Очищается указатель ps на результат функции. Адреса &ps!=&pstr, указатели указывают на на одну область. Хочу в своей программе сделать похожий подход, функция возвращает указатель на символьный массив Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2015, 01:15 |
|
||
|
утечка памяти
|
|||
|---|---|---|---|
|
#18+
polin11Меня терзают смутные сомнения нет ли здесь утечки памяти Нету. Данный код корректен. Но так делать действительно не очень хорошо. В документации на функцию buildstr мы конечно напишем что она возвращает новый кусок памяти который надо освобождать отдельно, но никто не гарантирует что мы не забудем это сделать. И вот тогда уже будет утечка. Поэтому, обычно в таких случаях память выделяют в вызывающей функции и в вызываемую отдают указатель на подготовленный буфер. Получается типа: Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2015, 01:39 |
|
||
|
утечка памяти
|
|||
|---|---|---|---|
|
#18+
polin11Взял листинг кода из книги Стивен Прата Язык программирования С++. Меня терзают смутные сомнения нет ли здесь утечки памяти, указатель, определенный в функции buildstr в куче, не очищается в ней. Так функция создаёт новую строку и возвращает её. Если её удалить, то возвращать нечего будет. Код предполагает, что вызывающая функция должна освободить память после использования строки. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Поглядим теперь на вызывающий код. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Всё корректно. Заметь, что вызывается не Код: plaintext 1. а Код: plaintext 1. как и положено по стандарту. авторОчищается указатель ps на результат функции. Ничего плохого. авторАдреса &ps!=&pstr, указатели указывают на на одну область. Ну, я не понимаю, что ты не понимаешь. &ps != &pstr -- да, это две разные переменные типа "указатель", их адреса поэтому разные. Но они указывают (в какой-то момент времени) на один и тот же массив символов (строку). Если ещё остались вопросы, задавай, но подробнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2015, 17:12 |
|
||
|
утечка памяти
|
|||
|---|---|---|---|
|
#18+
White Owl Поэтому, обычно в таких случаях память выделяют в вызывающей функции и в вызываемую отдают указатель на подготовленный буфер. Это не так. "Обычно" здесь не прокатывает. Тут нет "обычно". Зависит всё от ситуации, назначения кода и соглашений о программировании в конкретном проекте. А вот что точно в современном С++ уже не принято (хотя это просто традиция и общие идиомы), так это возвращать голые указатели на динамическую память. Тут надо было бы использовать либо smart_pointer-ы, либо вообще использовать std::vector или std::string. Но это видимо учебный пример, т.к. такой функционал точно есть в std::string и он в рельной программе мало кому будет интересен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2015, 17:16 |
|
||
|
утечка памяти
|
|||
|---|---|---|---|
|
#18+
Управление "голой" памятью очень полезно для собственного понимания. Но в большинстве проектов нет необходимости в "сырой" работе с памятью - если только вы не пишете очередной аналог "менеджера ресурсов" навроде умных указателей. Соглашения о кодировании - хорошая штука. Плохо, что компиляторы их не читают. Поэтому, когда кто-нибудь забудет, ничем не помогут. А забыть можно просто - просто "запутавшись" в области видимости и понадеявшись на "соседа". Но современный С++ (С++11.С++14/С++17) позволяет во многих случаях переложить на плечи компилятора эту проблему (код отработает для С++14/С++17, для С++11 нужно "подсказать" возвращаемый тип функции): Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2015, 23:25 |
|
||
|
|

start [/forum/topic.php?fid=57&fpage=44&tid=2018876]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
77ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
143ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 280ms |

| 0 / 0 |
