я смог получить выход похожий на protobuf файл, но я не уверен, что это оно. Завтра, только проверить смогу...

Вот, интересно, может кто нибудь тут делал уже такое

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

Потому что надо сначала лэйаут родителя сломать (удалить), потом таскать, потом можно новый лэйаут задать

А stderr?

С чего он небуферизированный ?

С чего он небуферизированный ?

ну там чо-то в POSIX какие-то гарантии были. или не было?

С чего он небуферизированный ?

The stream stderr is unbuffered. The stream stdout is line-buffered when it points to a terminal.

могут вот здесь - @supapro

могут вот здесь - @supapro

спасибо

Такс, профессионалы

под маком у valgrind много траблов?

@Artalus

под маком у valgrind много траблов?

А он точно нужен? Шланговые санитайзеры уже многое умеют лучше него

А он точно нужен? Шланговые санитайзеры уже многое умеют лучше него

А как же massif?

Многое != все)

А так, быстрый heap profile есть в jemalloc, massif я лично не пробовал

btw, в openbsd можно маллок системный подменить, чтобы находить всякие проблемы с памятью

недавно на линуксовке узнал

под маком не было траблов с valgrind, нормально работал

Щя продублирую сюда

btw, в openbsd можно маллок системный подменить, чтобы находить всякие проблемы с памятью

Что такое системный malloc? Либсишный может?

Кто-нибудь пробовал memoro?

btw, в openbsd можно маллок системный подменить, чтобы находить всякие проблемы с памятью

А так, jemalloc/tcmalloc не только в опенбсд бывают)

btw, в openbsd можно маллок системный подменить, чтобы находить всякие проблемы с памятью

везде можно

Смотрите, если кратко то волгринд агриться на то, что память создаваемая в insertAll не освобождается

https://github.com/Worsell/SomeSimpleProjects/tree/SimpleBinaryTree

bool insertAll(iter begin, iter end) { //std::sort(begin, end, std::less<T>()); auto *tmp = new SimpleSearchTree<T>(); int b = 100; for (auto i = begin; i != end; i++) { tmp->insert(*i); if ((tmp->size != 0) && (tmp->size % b == 0)) { if (root == nullptr) { root = tmp->root; } else { Node<T> *const node = getParent(tmp->root->getElement(), root); if (node->getElement() > tmp->root->getElement()) { node->setLeft(tmp->root); tmp->root->setParent(node); } else { node->setRight(tmp->root); tmp->root->setParent(node); } } size += (tmp->size); tmp = new SimpleSearchTree<T>(); } } if (root == nullptr) { root = tmp->root; } else { if (tmp->size != 0) { Node<T> *const node = getParent(tmp->root->getElement(), root); if (node->getElement() > tmp->root->getElement()) { node->setLeft(tmp->root); tmp->root->setParent(node); } else { node->setRight(tmp->root); tmp->root->setParent(node); } } } size += (tmp->size); return true; }

я тупо создаю древо, и подвешиваю его к уже существующему

scr/SimpleTree.h

leak definitly lost

модель удаления древа - рекурсивная

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

virtual ~Node() { delete left; delete right; right = nullptr; parent = nullptr; left = nullptr; }

деструктор ноды все делает

В чате для нубов обсудили

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

потому что код простой и тут тупо не может быть утечек

Что такое системный malloc? Либсишный может?

да, libcишный

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

да, использовать unique_ptr вместо сырых указателей

bonus: пока перелопатишь, поймешь где была утечка)

ну умные указатели там просто все переписать будет

я думаю так и поступлю

ну умные указатели там просто все переписать будет

не так уж и много, на самом деле - заменить сырые указатели, new на make_unique, убрать ручные деструкторы да расставить std::move по вкусу

ну я про это же

там чисто сахар переписать

в реализации BST это строк 20-30 поменять, на вскидку

ну у меня не больше

вы лучше скажите, почему оно агриться:(((((

вы лучше скажите, почему оно агриться:(((((

потому что может

delete tmp

virtual ~Node() { delete left; delete right; right = nullptr; parent = nullptr; left = nullptr; }

в какой институт поступить, чтобы такому научиться?

в какой институт поступить, чтобы такому научиться?

такому - это чему?

зачм нуллить указатель на уже удалённый объект?

зачм нуллить указатель на уже удалённый объект?

потому что delete ничо не нулит?

вот проверку на нул делать не надо, это да

зачм нуллить указатель на уже удалённый объект?

а если случайно второй раз его делетнуть будет еще веселей

зачм нуллить указатель на уже удалённый объект?

На самом деле конечно это не нужно если два раза и более delete не вызываешь. Но для отладки бывает весьма полезно. Ещё полезнее правда умные указатели использовать...

зачм нуллить указатель на уже удалённый объект?

первое правило кастоменых делитеров - не писать кастомные делитеры

На самом деле конечно это не нужно если два раза и более delete не вызываешь. Но для отладки бывает весьма полезно. Ещё полезнее правда умные указатели использовать...

для какой блин отладки?

В отладчике.

двойная аллокация памяти (пох что по 8 байт всего) это сильно...

двойная аллокация памяти (пох что по 8 байт всего) это сильно...

двойная деаллокация это сильнее

в деструкторе всмысле

аллокация памяти в деструкторе? o_O

аллокация памяти в деструкторе? o_O

а шо, не плохо, убить себя сразу

Ну, может человеку надо, а исключения он перехватывает все...

ну надо, так надо.. непонятно просто зачем

delete tmp

Tmp не в куче ж лол

зачм нуллить указатель на уже удалённый объект?

Удобно

На самом деле конечно это не нужно если два раза и более delete не вызываешь. Но для отладки бывает весьма полезно. Ещё полезнее правда умные указатели использовать...

Ну я это на смарт переписал

Щя задебажим и норм будет

TEST(SimpleSearchTree, SimpleAddAll) {     auto *test = new std::vector<int>();     auto *const trees = new ::myLibrary::SimpleSearchTree<int>();     test->reserve(5); Весёлые тесты, однако. Извращение какое-то, всё на куче выделять.

for (std::__1::__tree_const_iterator<int, std::__1::__tree_node<int, void *> *, long>::value_type i: *test) {         ASSERT_EQ(true, trees->contains(i)); А это вообще супер ?

for (std::__1::__tree_const_iterator<int, std::__1::__tree_node<int, void *> *, long>::value_type i: *test) {         ASSERT_EQ(true, trees->contains(i)); А это вообще супер ?

auto для неудачников?

TEST(SimpleSearchTree, SimpleAddAll) {     auto *test = new std::vector<int>();     auto *const trees = new ::myLibrary::SimpleSearchTree<int>();     test->reserve(5); Весёлые тесты, однако. Извращение какое-то, всё на куче выделять.

Пацифист, во время теста ниодин объект не был убит

auto для неудачников?

Для заставших C++11, тут мб легаси доисторического периода? Иначе хз что за мазохизм

О да

До моего кода добрались ???

TEST(SimpleSearchTree, SimpleAddAll) {     auto *test = new std::vector<int>();     auto *const trees = new ::myLibrary::SimpleSearchTree<int>();     test->reserve(5); Весёлые тесты, однако. Извращение какое-то, всё на куче выделять.

На утечки ж

Да бес с ним, с auto. Мне интересно, сколько времени человек потратил, чтобы этот внутренний тип выкопать, и не лень ведь было.

for (std::__1::__tree_const_iterator<int, std::__1::__tree_node<int, void *> *, long>::value_type i: *test) {         ASSERT_EQ(true, trees->contains(i)); А это вообще супер ?

Там оно стояло Но чёт как то печально с ним Явное лучше чем не явное

Да бес с ним, с auto. Мне интересно, сколько времени человек потратил, чтобы этот внутренний тип выкопать, и не лень ведь было.

Одной кнопкой

В ide:)))

Для заставших C++11, тут мб легаси доисторического периода? Иначе хз что за мазохизм

но ведь в коде выше используется auto ?

Там оно стояло Но чёт как то печально с ним Явное лучше чем не явное

кек

Там оно стояло Но чёт как то печально с ним Явное лучше чем не явное

Wt?