Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
0
char* szOwnedData = reinterpret_cast <char*> (m_bOwner && szData != NULL ?
realloc (szData, nLength + 1) :
malloc (nLength + 1));Ha ha, classic.
Запостил: 
codemonkey,
(Updated )
1. szData и szOwnedData - две разных переменных, после неудачного realloc szData никуда не утечёт.
2. из условия можно убрать szData != NULL и покормить realloc нулями, но всё равно из-за m_bOwner тернарник никуда не уйдёт.
3. питушки кукарекают из-за malloc/realloc/free? А какие альтернативы? И какие проблемы, если эта питушня инкапсулирована в классе?
4. или дело в nLength + 1? Ну то есть szData был nLength, а тут к нему прихерачивают ещё один байт вместо православного увеличения в два раза? Но для того, чтобы это подтвердить, не хватает контекста.
Вывод: данный кусок - не говно.
P.S. Какой оналог realloc в плюсах?
Типа:
Petuh petuh = new Petuh;
ZhirnyPetuh petuh2 = new ZhirnyPetuh(petuh)
//дисклеймер: я не крестоблядь
>массив
а разве не нужно взять list, и list::resize() ?
Или я пижжу?
Нужно увеличить питуха в 2 раза.
ну у него же есть ресайз?
Именно для этого придумали «std::vector::data()».
Не ты аллоцировал — не тебе освобождать.
Если есть malloc, значит на том же уровне абстракции должен быть фри.
Если есть add, должен быть remove.
Если есть шаг -- должен быть след
Если есть тьма -- должен быть свет
А когда
Четыре тысячи петухов
И четыре тысячи индюков
пишут, например, Лиснук, им трудно не создавать абстракций, а не запутываться в них еще сложнее
#песни
Ты освобождал, где не аллочил, и собирал, где не рассыпал; посему надлежало тебе отдать память мою немедля.
И я, придя, получил бы моё.
Ибо всякому освобождающему дастся и приумножится, а у занимающего отнимется и то, что имеет.
А негодному отбросу дайте скриптуху: там будет плач и скрежет зубов.
И соберутся пред Ним все кодеры; и отделит одних от других, как пастырь отделяет бояр от скриптухов; и поставит бояр по правую сторону, а биомусор — по левую.
Тогда скажет и тем, которые по левую сторону: идите от Меня, проклятые, в огонь вечный, уготованный скриптухою
Ибо Я был на хабре, и заминусовали Меня; был на ЛОРе, и забанили Меня; был на ГК и смеялись надо Мной; был в блоге, и не посетили Меня.
И сольются сии в хламину вечную, а блаженные праведники в Сишку вечную.
Тогда скажет Царь тем, которые по правую сторону Его: придите, благословенные, наследуйте Царство, уготованное вам от создания Сишки.
И Царь скажет им в ответ: истинно говорю вам: так как вы сделали это одному из сих бояр Моих меньших, то сделали Мне.
Например у вектора resize.
Перейти на другую архитектуру, где указатели шире/уже.
Да и sizeof(укоззатель) же в конпайл тайме же работает же, как ты ево ресайзнуть собираешься? Регистры программно расширять чтоли умеешь?
есть
pituh1 = (int*)malloc(100500*sizeof(int))
есть
pituh2 = new int[100500]
есть
realloc(pituh1, 2001000*sizeof(int))
как c pituh2 сделать?
Вопрос понятен?
Почему он не может быть вектором, массивом, строкой и тюпю?
зачем есть char* и string?
Помнится, в делфи и сибилдере можно было ресайзить массив. И что в итоге? Макаки умудрились нахуевертить Алгоритм Шлемиэля почти в каждой проге. С вектором это сделать сложнее, он не реаллочится на каждый чих.
Мы там про демонические массивы ничего не знали, у нас всё сатаничесоке былдо.
А ещё нам про джвухмерные матрицы ничего не рассказывали, представляете, как я заебался, когда в первый раз пытался напесать крыстики-нолики?
Я теоретическую возможность спрашиваю.
Вектор же как-то реаллочит свои кишки внутри?
Если делаешь new int[] или malloc, выделяется непрерывный кусок памяти. Если нет свободного места, чтобы его реаллочить на месте, приходится выделять новый кусок памяти, копировать туда все элементы, потом удалять старый кусок.
std::vector не обязан размещаться в непрерывном куске памяти. Доступ к его элементам не по сишному указателю с арифметикой, а через перегруженный оператор []. Чтобы реаллочить std::vector, не нужно выполнять пердолинг из предыдущего абзаца, достаточно выделить в произвольном месте памяти блок для новых элементов. Перегруженный оператор [] автоматически направит тебя на старый или на новый блок.
Верно или я нафантазировал?
А у new int[] вся выделенная память задействована, поэтому для добавления даже одного элемента нужно делать полный реаллок.
Лол што? Он тоже создаст новый кусок, и удалит старый. Но я думаю он позовёт realloc или его аналог.
А он тут не поможет, память же облапали.
А это очень редко работает, на самом деле. Особенно в многопоточной проге.
Ну и у вектора есть reserve() если ты примерно знаешь сколько в нём будет элементов и хочешь чтобы он лишний раз не реаллочился.
>даже если можно расширить текущий кусок памяти
В других языках типа Йажи, те же проблембы. Разве что gc память дефрагментирует. Но всё равно перепитушня.
> я думаю он позовёт realloc или его аналог.
Вот в С++42 допилят move-семантику моей мечты для нетривиальных конструкторов. И она будет делать realloc, схлопывать new+delete, превращать воду в вино и творить прочие чудеса.
1. выделить новый кусок
2. если новый кусок выделен (не NULL) и не равен старому (расширение), удалить старый
Тогда между этими этапами в случае, если новый кусок выделен и не равен старому, можно использовать placement питушню. И всё как надо будет.
Вектор всё равно не смог бы юзать такой массив в качестве бекенда. Ему ещё capacity надо, а не только size. Так что это просто бесполезный атавизм от первых версий крестов.
Ну а что ещё сказать, если это ненужный атавизм от первых версий крестов, у которых ещё вектора не было?
ЗЫ. Ты мудак, зачем тебе это нужно. Зачем? Зачем?
Шлемазла
умнички какие.
У жабоебов тоже есть лист, и он тоже аллокейтится с запасом именно от таких вот долбоёбов
Отвечаю на комент твой.