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

https://gcc.gnu.org/bugzilla/createaccount.cgi > …contact gcc-bugzilla-account-request@gcc.gnu.org to request a GCC Bugzilla account. Но да, подсказка от кого-нибудь с опытом может быть в тему, чтобы самому через это не продираться.

Не секрет. gcc ругается на неиспользуемое объявление типа is_transparent в компараторе. using is_transparent = int например.

в каком смысле - в компараторе?

https://wandbox.org/permlink/rxnaVyogc27EpdLf

Без -Wno-unised-local-typedefs ругается на is_transparent. А не должен. Clang молчит и правильно делает

да, интересный баг

Кто может засабмитить баг в gcc?

ну я зареган, так что могу зарепортить 😊

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

Очень странно. Ну, ща вроде ограничения сняты

https://neopg.io/ - кажется неплохим примером миграции огромного проекта на plain c на c++

https://neopg.io/blog/cplusplus/ - особенно это

https://neopg.io/blog/cplusplus/ - особенно это

надо Линусу скинуть это

а хотя у него Си головного мозга

и это не лечится

написать какаху на c++ намного проще, чем на c

поэтому для проектов, где много разработчиков, я бы предпочел plain c :)

зависит от объема проекта. на 10к и больше локов я б точно Си не брал)

написать какаху на c++ намного проще, чем на c

сильное утверждение. С чего бы так?

зависит от объема проекта. на 10к и больше локов я б точно Си не брал)

А я б C++, там и в 100 строчках с шаблонами запутаешься

нет

А я б C++, там и в 100 строчках с шаблонами запутаешься

а кто заставляет паисать двухэтажные шаблоны?

И с умными указателями тем более

И с умными указателями тем более

что тем более? они упрощают менеджмент памяти

а кто заставляет паисать двухэтажные шаблоны?

Ну без них C++ какой-то неполноценный выходит

Ну без них C++ какой-то неполноценный выходит

лол

что тем более? они упрощают менеджмент памяти

Фиг поймёшь, что чем владеет

Фиг поймёшь, что чем владеет

нет, ты просто не осилил семантику их

@zamazan4ik чем сложнее синтаксис языка, тем проще написать неподдерживаемую какаху

@zamazan4ik чем сложнее синтаксис языка, тем проще написать неподдерживаемую какаху

ммм, что насчёт написания обощённых контейнеров на Си? Что насчёт менеджемента памяти? (я на RAII намекаю)

я вот конкретно сейчас переписываю здоровый алгоритм с Си на кресты. Спасибо писателю за сие поделие

это не холивары

ммм, что насчёт написания обощённых контейнеров на Си? Что насчёт менеджемента памяти? (я на RAII намекаю)

Для первых я, вроде, кидал тут ссылку на вектор, размер которого указывается перед самой памятью, а для второго goto

@zamazan4ik ну, я потому и думаю о миграции на c++, да

менеджер памяти на goto - это сильно

кстати, я тут еще вспомнил, что мы хотели во фре pkg tool перевести на c++, но там была проблема с gcc 4.2 :\

а на mips32 и sparc64 до сих пор все тот же gcc 4.2

Для первых я, вроде, кидал тут ссылку на вектор, размер которого указывается перед самой памятью, а для второго goto

ты понимаешь минус goto по сравнению с smart pointers?

кстати, я тут еще вспомнил, что мы хотели во фре pkg tool перевести на c++, но там была проблема с gcc 4.2 :\

это да, согласен

ты понимаешь минус goto по сравнению с smart pointers?

я имел в виду RAII

в этом pkg 99% работы - это дергать sqlite и тупить в хеш таблицы

А вместо умных указателей архитектура, в которой чётко понятно, кто что выделяет и освобождает

Могу точно сказать, что mkl написан на 80% на pure asm

Модульная

А вместо умных указателей архитектура, в которой чётко понятно, кто что выделяет и освобождает

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

c++ более сложный язык, но писать на нем проще и безопаснее - это факт

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

Зачем что-то с памятью делать автоматически, выделять надо редко, но достаточно

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

Пулы использовать всякие

этим занимается аллокатор, зачем в него вмешиваться?

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

кхм, без накладных расходов?

он всяко делает это лучше, чем наколенные пулы

Зачем что-то с памятью делать автоматически, выделять надо редко, но достаточно

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

А вместо умных указателей архитектура, в которой чётко понятно, кто что выделяет и освобождает

Тут были разговоры о том, что std::shared_ptr не очень нужен.

Поищи.

кхм, без накладных расходов?

да, я про std::unique_ptr

я не топлю за повсеместное использование std::shared_ptr, это дорого

Никто еще не знает о накладных расходах. Подразумевается лишь что их не должно быть. Остальное - дело тестов.

поэтому для проектов, где много разработчиков, я бы предпочел plain c :)

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

Есть у подсистемы или под-подсистемы init, есть shutdown, они должны балансировать друг друга, вот и всё, точно не забудешь

Никто еще не знает о накладных расходах. Подразумевается лишь что их не должно быть. Остальное - дело тестов.

они сделаны до тебя. Не веришь - сам посмотри 😊

Может и верю, честно говоря. А ссылка есть ?

Есть у подсистемы или под-подсистемы init, есть shutdown, они должны балансировать друг друга, вот и всё, точно не забудешь

то есть ты считаешь этот путь верным, я правильно понял?

Кстати, а есть хороший пример хорошего использования std::shared_ptr? В тот раз сошлось на том, что надо пилить менеджеры ресурсов нормальные.

Может и верю, честно говоря. А ссылка есть ?

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

Или вообще какие-нибудь списки выделенного использовать, а потом в шатдауне вжух — и всё удаляешь

то есть ты считаешь этот путь верным, я правильно понял?

@Triang3l

Или вообще какие-нибудь списки выделенного использовать, а потом в шатдауне вжух — и всё удаляешь

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

Кстати, а есть хороший пример хорошего использования std::shared_ptr? В тот раз сошлось на том, что надо пилить менеджеры ресурсов нормальные.

@AndreiKr

Кстати, а есть хороший пример хорошего использования std::shared_ptr? В тот раз сошлось на том, что надо пилить менеджеры ресурсов нормальные.

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

std::shared_ptr между потоками... Счетчик ссылок же не потоко-безопасный там?

нет времени при разработке на крестах = больно получать по рукам через N временм

Слушайте, а что по низкоуровневым сетевым библиотекам для C++? Кроме boost/non-boost ASIO.

Есть что-нибудь красивое, современное и быстрое?

Я просто как-то долго страдал с ASIO, а конкретнее — с его надстройкой в лице beast.

С виду простая задача превратилась в какое-то месево, которое ещё и долго компилируется.

Я просто как-то долго страдал с ASIO, а конкретнее — с его надстройкой в лице beast.

Собсно, почему я перекладываю так, beast/ASIO — вроде разные либы, но у первого сказано, что дизайн ASIO-like. Что-то подобный дизайн не способствует продуктивности.

Ещё частенько говорят о неэффективности асинхронных операций ASIO на Linux (epoll).

std::shared_ptr между потоками... Счетчик ссылок же не потоко-безопасный там?

Он безопасен так же как сырой pointer. То есть ты можешь его разыменовывать, копировать и всё такое.

Он безопасен так же как сырой pointer. То есть ты можешь его разыменовывать, копировать и всё такое.

Это с какого стандарта он безопасен? Просто я ещё на C++11 гонял, вроде не очень было с потоками.

Еще с момента когда он был частью буста.