копирования url ссылки.
Может норм идея будет взять максимально возможную длину юрл выделить на стеке перед циклом? и в этот буффер копировать юрл?
Зачем тебе вообще что-то там выделять - вот что не понятно...
чтобы сделать deep copy (реальное копирование) юрл ссылки, а не скопировать адресс из указателя
нормальная идея использовать адаптивный подход: char buffer[1024]; char* url = buffer; size_t url_size = sizeof buffer; ... if( url_size < new_size ) { url = malloc(url_size = new_size); if( !url ) return 1; } ... if( url != buffer) free(url); тогда ты в цикле будешь просто подстраиваться под новые требования к capacity, а выделять память будешь только в том случае, если заранее выделенный буфер на стеке мал
Выглядит красиво. спасибо)
А в чём проблема подсчитать длину url, а потом realloc'нуть?
В зависимости от количества запросов на выделение и освобождение памяти что realloc, что код выше может быть дорог по времени. По этой причине и я написал про вариант реализации в std::vector. Т.е. если выделено меньше, чем новый запрос, то выделяем k*size(url_curr). Точнее про код выше я наврал. Там всё отлично, но я бы еще k коэффициент добавил.
Только unique_ptr<char, &std::free> url_buff_in_mem Т.к. исключения никто не отменял.
Чёт я не вдупляю - в конечном итоге std::vector всё равно будет заниматься аллокацией памяти, так зачем городить кучу логики поверх этого?
Разное количество вызовов malloc и free - эти функции достаточно дорогие. В зависимости от реализации или одна или другая будет медленная.
А смысл рассуждать о дороговизне операций, делать какой-то костыль, если невооружённым взглядом видно, что задача ни разу не на уровне книжки с кабанчиком Преждевременная оптимизация - корень всех зол (с)
Потому что мы в чате и тебе здесь описали и решение и возможные проблемы и их решение, но ты как положено июнб в супе начал возмущаться.
Обсуждают сегодня