Доброго всем времени суток...

Сразу скажу, что при написании топика почитал эту и эту тему, выданные мне форумом как "похожие темы", ответы там не сильно помогли, поиском тоже пользовался - не айс...  между тем вопрос по большому счету не стОит и того количества букв, которые я тут напишу, но тем не менее, постараюсь в красках и примерах на пальцах объяснить суть ментального геморроя...
Итак, недавно пришлось переводить кое-какой код с Дельфи на С++ и столкнулся с интересной для себя теоретической проблемой, которая подспудно грызла меня давно, но как-то не было случая с ней основательно разобраться... Дело в том, что есть, допустим, гипотетический код на дельфи:Как видно из этого примера - размер возвращаемой строки заранее неизвестен, компилятор автоматически выделяет в стеке необходимый буфер под строку, расширяя по необходимости, и затем возвращает её... Теперь пытаюсь сделать то же самое на С++:Возникают следующие вопросы:
1) Очевидно, что если я оставлю функцию в таком виде - я гарантирую себе весёлую жизнь с утечками памяти, ибо delete\free нигде не вызываются и память по выходу из функции утекает. В итоге - закономерный вопрос: где необходимо освобождать память? Выделять память до вызова функции нет смысла, ибо размер буфера неизвестен; освобождать внутри функции - бессмысленно; выделять внутри, а освобождать после выхода - некрасиво (и есть небезосновательное подозрение, что неправильно)...
2) Как вообще правильно действовать в таких случаях? Использование разнообразных классов типа std::string не предлагать, сам знаю, что они для этого и предназначены, но так же помню, что разнообразные библиотечные функции, работающие с char * - работают вполне корректно и возвращают указатели на вполне валидные буферы. Да, я понимаю, что там используется несколько другой подход - передаются указатели на буферы, где необходимо разместить ответ, но не до конца понимаю, где происходит выделение памяти под эти буферы? (Тот же strcpy - как и где выделяет память под char *strDestination?). Единственный более-менее внятный ответ на похожий вопрос от _hunter'а я увидел у RAN, но и там возник вопрос: а что если память под параметр char* param выделена не через new, а допустим, через malloc (при условии, что я не знаю точно)?

В общем, буду признателен, если помимо ответов "ха-ха, ты далпайоп!" и "кури маны, дятел!" (как любит говорить мне мой друг) будут более содержательные разъяснения 

ну если посмотреть апишные функции, то как правило им передаётся буфер и размер, а они возвращают количество записанных символов и, если что, количество символов, которые не влезли.
По большому счету мне непонятны твои сомнения относительно new или malloc. Ведь полюбому буфер надо выделять перед вызовом и функции  побарабану как он получен (хоть массив в стеке). Возвращать из функции имеет смысл если возвращается const char* заранее определененый, а в твоем случае нужно подготовленный буфер передавать и заполнять его.

Добавлено через 5 минут и 2 секунды
если смотреть твой код

неправильно это. Плохо делать выделение памяти внутри функции. Так ты делаешь вызывающий код зависимым от реализации этой функции. 

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

Правильно понимаете. Это чревато следующей ошибкой, которая ловится, зачастую только под отладчиком. Если Вы передаёте адрес как аргумент, то работаете с локальной копией указателя, и внешний мир ничего не знает о выделенном участке. Это будет бесцельная трата памяти. Если же вы используете адрес в качестве возвращаемого значения, то аргументом передавайте размер, Ваша функция будет выполнять роль оболочки над malloc. Напишите обратную функцию - оболочку над free.
Библиотечные функции и strcpy в том числе используют именно преопределённые буферы, за выделение и освобождение которых отвечаете Вы.
Попробуйте представить иной пример, тогда найдём в открытых исходниках аналог и разберёмся. Пока я такого не встречал.  

PS Пока инет глючил, Fazil6 опередил.

Это сообщение отредактировал(а) Walker - 6.6.2008, 10:54

как вариант сначала запрашивать размер буфера, а потом выделять буфер и вызывать GetString, но честно говоря я бы так не делал. 
По любому используя С++ лучше контейнер (стандартный или самодельный) вместо char* 

strcpy не выделяет память. Выделение памяти - это проблемы вызывающего  strcpy кода.


курить std::string (c++)
и realloc  ©

вот те раз... приехали... нигде он ее не выделяет. Оба буфера выделены до вызова. 

realloc курить сюда.

зы! опять мои посты не склеились >ОДНАКО<

Это сообщение отредактировал(а) Mayk - 6.6.2008, 10:56

А можно ли вообще возвращать адрес локальной переменной?
Компилятор по-этому поводу предупреждает!

Оно, конечно, может и лучше, но... фиг знает, иногда бывает необходимо и на чистом С писать, а тогда иметь на вооружении знания о работе с char* оказывается полезным...
Да, это так, но я хочу пока рассмотреть простую ситуацию, где нет переопределения функции new... 
Да, здесь я возможно просто неправильные примеры привел, сейчас так сходу не рожу что-нить покорректнее, но суть основного вопроса от этого меняется не сильно... Как работать с памятью при такой ситуации, как я описал?

Ага, это если память выделена malloc... А если через new? Делать delete и new заново? Насколько это корректно с точки зрения областей видимости? А если неизвестно - через что выделена память?   
Я написал, что это гипотетический пример и что он явно не рабочий... И вопрос-то как раз в том и стоит - "как мне вернуть динамически сформированную строку"?

можно, но не нужно

Добавлено через 2 минуты и 47 секунд

два варианта
1. отделить функционал от работы с памятью (выделение/освобождение)
2. использовать статический буфер (TLS-буфер в случае многопоточности)

на плюсах это легко:


а не ООП тем и хуже, что ты сам обязан за всем следить

Да я-то и не против следить, мне собственно и нужно знать - КАК следить? Как правильно будет написать возврат строки из функции?
  для моего случая хотя бы на псевдоалгоритме 

См аллокаторы в stl. 

и в С и в С++ работа по выделению памяти внутри функции не этична
но в С++ можно написать оболочку над буффером (чем с данной точки зрения и является std::string)
"стык" между  С и С++ приводится к сишнему виду, со всеми вытекающими проблемами..
поэтому имхо  вопрос должен относится к чистому С, а не к плюсам

Цитата(Alek86 @  6.6.2008,  11:35 )

Код std::auto_ptr<char> GetString(void) {   char *s;   s = new char[1000];   return std::auto_ptr<char>(s); }

перекосило от конструкции, хотя отработает она без проблем. 

думаю имелось в виду сделать 2 функции - получение длины данных и заполнение буфера
тогда

- получил длину
- создал буфер
- заполнил (GetString)
- воспользовался данными
- удалил буфер

а если получение длины неотделимо от GetString, то или выделяй большой буфер и пускай функция выдает ошибку, если его оказалось недостаточно или уж выделяй внутри функции и возвращай


Добавлено @ 11:59

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



если функция внутри dll находится, то плюсы тут наравне с сями, ибо реализация auto_ptr не специализирована и даже размеры классов для борланда и мелкософтового компилеров могут отличаться

Это сообщение отредактировал(а) Alek86 - 6.6.2008, 12:00

Опять же - поднимаемся до уровня библиотеки шаблонов С++. Оно, конечно, введено в стандарт и все такое, но проблема в том, что во многих компиляторах С, применяемых, допустим, в промышленных контроллерах, она попросту отсутствует. Поэтому интересно узнать решение средствами языка, а не каких-то библиотек (даже если это и трудоёмко). Или наоборот - получить подтверждение, что это невозможно...  

Добавлено через 2 минуты и 32 секунды
Во-во, про второй способ поподробнее пожалуйста... На что должен указывать char* p_str?

на начало строки...

delete [] != delete.


Ну так вместо шаблонов передавай указатели на malloc/realloc/free  если так заботишся о обобщенности, делов то.

А память под строку выделена\освобождена где?

ДО вызова/а если требутеся - то ВО время. 

Это сообщение отредактировал(а) Mayk - 6.6.2008, 12:09

можно передавать в функцию не только массив и его размер, но и указатель на функцию изменяющую размер массива...


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

так и с массивом размещенным в стеке

точно
интересно, какой хороший человек решил их разделять...


внутри функции
но это только в том случае, если никак не можешь отделить подсчет необходимой длины от GetString (или он просто будет долго работать)

Хорошо, а на что передавать указатели в случае new\delete? Аналогом realloc, кстати, в этом случае что у нас является?

std::copy блин





На что передаются указатели  в аллокаторы?
На что передаются указатели  в аллокаторы?
На что передаются указатели  в аллокаторы?
На что передаются указатели  в аллокаторы?
На что передаются указатели  в аллокаторы?
На что передаются указатели  в аллокаторы?
На что передаются указатели  в аллокаторы?


Это сообщение отредактировал(а) Mayk - 6.6.2008, 12:14

Lazin, привел хороший пример, но к тебе тот же вопрос...

новый массив = new[] 
memcpy из старого в новый (если нужно)
delete[] старый массив

тут два варианта , или "чистый" виртуальный интерфейс, либо С -подход (не смотря на то что прога на С++)

в си алокаторов и new/delete нету, так к слову...

ama_kid, перед вызовом подобных функций использую предварительное выделение заведомо достаточного объема памяти в стеке, либо хипе (зависит от необходимых размеров). соответственно, память освобождается в той же функции, которая ее выделяла. если максимальный размер возвращаемых данных никак заранее нельзя определить (хотя бы примерно), то, дабы не обременять себя "ментальным геморроем", использую std::string. 

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

поясню:


как-то так, в общем.

хмм.. ну тада уж проще использовать с
std::string 

Добавлено @ 12:20
Повторюсь - что в этом случае с областью видимости в случае использования внутри функции? Ничего, что мы выделяем память, которая будет невалидна потом?
Ну, на самом деле иногда приходится работать со срещенным С\С++ - new\delete есть, а библиотеки шаблонов нет 
Добавлено @ 12:21
В общем-то полностью согласен, и изначальный вопрос родился из мыслей: "а нельзя ли сделать как-нить эдак, чтобы не так?!"


Это сообщение отредактировал(а) ama_kid - 6.6.2008, 12:27

даже чистый вирт интерфейс не может работать с переменными типов std::auto_ptr и т.п.

естественно ..  однако это не мешает использовать нам их в реализации ..

все будет ОК, что-бы удалить блок памяти, не нужно знать его размер

как-нибудь эдак, конечно, можно. вопрос - нужно ли?  

(шепотом) там народ уже интерфейсы обсуждает )) скоро, чувствую, все сведется к необходимости создания дерева классов со сложной иерархией, наследованием, и прочей модной шелухой =)

тем более вопрос был не об auto_ptr , а о том как избежать проблем с выделением памяти внутри функции

Добавлено через 1 минуту и 11 секунд

))

Удалить-то мы его удалим, а куда денется выделенная по-новой память при выходе из функции?

если изменять память внутри функции надо передаватж в нее ссылку на указатель.. тогда ее можно будет удалить извне ..
но в таком случае саму функцию желательно называть типа newString - чтобы было ясно что внутри происходит выделение памяти ..
а так же желательно чтоб был ее антоним типа deleteString - но такой подход только в особенных случаях
в остальных как и говорилось выше - нужно выделять памятж вне функции 

Опять же - а если вне функции неизвестен размер требуемой памяти?

Хорошо, у меня вроде бы сформировался более-менее основной вопрос, попробую его сформулировать: как после выполнения оператораполучить корректный буфер s (т.е. что должно быть вместо "..." и внутри функции GetString? ), при условиях: 
1) размер строки становится известен только внутри GetString()... 
2) пользуясь new\delete? 
P.S. Для случаев с malloc\realloc\free я более-менее уже понимаю... 

присваивать так низя, юзай strcpy

что передавать в strcpy? 
Ну это гипотетический пример, хоть strcpy, хоть что-то другое , без разницы, главное - на выходе получить валидный буфер


Это сообщение отредактировал(а) ama_kid - 6.6.2008, 13:08

Добавлено через 1 минуту и 8 секунд
кстати 

Fazil6, ага, вариант понятен... В принципе, я так и делал всегда...

Кстати, щас только сообразил, что непроходимо туплю - сам же на свой вопрос вывесил в топике ответ - ссылка ответа от RAN. В связи с этим вопрос - насколько корректен приведённый там пример? Просто никто там после этого не отписался по поводу правильности\неправильности. Если он правилен - тогда вопрос снимается...

Ого, сколько написали...

Подытожу по себе (то есть, как бы это делал я).
Варианта 2:

1) целевой язык - С



2) целевой язык - С++


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

Это сообщение отредактировал(а) JackYF - 6.6.2008, 13:26

ага, а не будет ли в этом случае Access Violation в связи с доступом к невалидному участку памяти? Или участок памяти, выделенный внутри функции будет валидным?

JackYF, в C нет new и delete   

    


как я понял имеется ввиду этот ответ:
http://forum.vingrad.ru/index.php?showtopi...st&p=109698






Это сообщение отредактировал(а) mes - 6.6.2008, 13:33

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

ну вот, приехали. new, оказывается, выделяет память в стеке? или C++ обзавелся хитрым сборщиком мусора, который подтирает всю выделенную в функции память?

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

в коментариях в предыдушем посту это и указано  ))

Это сообщение отредактировал(а) mes - 6.6.2008, 13:48

Не, ну выделить память внутри функции и выдать её наружу вполне себе юзкейс. Так, допустим, malloc поступает

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

mes, прошу прощения, неправильно понял  да, вы правы, param будет указывать в космос

Daevaorn, ну malloc'y на роду написано память внутри себя выделять. а если так будет поступать каждая гордая функция, то что с программой будет твориться, я не представляю

malloc и new тем и хороши что всегда не задумываясь (о том как реализована функция) понятно, что делает функция и одназначно напрашивается вывод о применение ее антонима.
однако, что нужно делать после функции GetString (..) (удалять память или нет)  имхо отнюдь не очевидно   
поэтому (на мой взгляд)  и принято "неписанное " соглашении о использовании внутри функции зараннее выделенного буффера..

Это сообщение отредактировал(а) mes - 6.6.2008, 14:12

а если строка больше чем буфер? Тогда ещё одну функцию заводить, которая вернет размер, потом выделить память, и только потом передать в функцию - много букв

Хотя, конечно, это оптимально с точки зрения прозрачности кода.

  Верно 

вот пример без добавления второй функции 

ну по сути вы её добавили, сделав в GetString проверку `if( p == 0 )`.

В общем, как я понял, сделать средствами new\delete (без привлечения библиотек-контейнеров и выкрутасов с несколькими функциями\вызовами) аналогичный дельфёвому фокус не удастся. Что ж, будет еще один плюс в пользу malloc\realloc   Думаю, тему можно закрывать, потому что обсуждение идет по десятому кругу, всем спасибо за активное обсуждение...  
Хотя, если появятся новые идеи - буду рад увидеть, да и для потомков, думаю, будет полезно...