Гх...

Хорошо.

@Triang3l

Да. Может быть, это не очень удобно, но зато не привыкнешь выделять где попало

Из-за чего у тебя в итоге аллокатор станет узким местом

Короче рефкаунтер там atomic fetch_add

Вопросов больше нет

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

это хороший путь, но кмк, он слишком тернист. Говорю, как человек, собравший кучу шишек на таких подсистемах) (частично это связанно с тем, что я, как и все люди, ошибаюсь, и в некоторых местах забывал добавлять зеркальный clean. Собственно ,из-за этой причины я своего бота почти сразу на C++ переделал, т.к. мне тупо надоело добавлять вручную очистки херни :) )

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

https://stackoverflow.com/questions/14482830/stdshared-ptr-thread-safety

Гм... Харашо.

Зачем тогда это ввели?

Если там внутри атомик счётчик.

это на атомарное изменение самого указателя

Ну, я спрашивал про безопасность счетчика ссылок.

Короче рефкаунтер там atomic fetch_add

вон сказали тут

Оно всё ещё может зарейсить с проверкой..

Нет.

Блин. Ты понимаешь разницу между атомарностью рефкаунтера и атомарностью самого объекта shared_ptr?

Разные вещи совсем.

А, дошло, затупил, прошу простить.

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

Я бы предпочел plain rust

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

Не умеешь буст - пиши с cpr

Не умеешь буст - пиши с cpr

Не умеет переиспользовать подключения, да и у libcurl в принципе проблемы с производительностью возникают (сам не встречался, но наслышан).

Более того, я бы не хотел иметь в древе зависимостей две реализации HTTP, так как мне ещё надо оперировать веб-сокетами, у которых в добавок нет особо вариантов кроме ASIO-based.

Собственно, хочется задать вопрос, почему у C++ так худо с сетью?

Задачи не те? Сетевое I/O везде, ибо коммуникации. C++ позиционирует себя, как универсальный язык, в чём дело?

Собственно, хочется задать вопрос, почему у C++ так худо с сетью?

Потому что на дворе древний 2018 год, неуместно требовать развития 22 века находясь в 21-м)

Да я всё ещё надеюсь на C++2a.

Модули, концепты, рефлексия, нетворкинг. Вот бы всё влили, да не успеют навернае.

Не надейся, там будет асио

Потому что асио это в целом хорошо

Но раз ты его не умеешь - используй cpr

Не надейся, там будет асио

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

Надеюсь комитет имеет хоть каплю common sense и подрежет мелополезные мелочи дизайна.

Модули, концепты, рефлексия, нетворкинг. Вот бы всё влили, да не успеют навернае.

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

Да, с рефлексией там тяжко, слышал.

повезёт, если рефлексия будет в С++23

нетворкинг - не совсем понимаю, чего они там тянут с ним так

Жаль, я уже хотел SFINAE-хаки закапывать.

(я про трейты)

Жаль, я уже хотел SFINAE-хаки закапывать.

все хотели бы. но не судьба

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

За эти три года между C++20 и C++23.

Получим аналог SFINAE-хаков, но чуть получше.

В итоге комитет прогнётся под легаси и будет менять концепты под эти хаки, вместо работы над важными вещами.

Я так думаю, что так же с SFINAE-хаками произошло.

Не ввели нормального средства, коммьюнити надо было средство, прижились костыли, от которых страдают все.

@berkus я тоже хочу написать какой-то домашний проект на растике, для самообразования

но ума не приложу, какой

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

Не думаю, что это касается нашего случая.

Трейты в C++ используются во многих вещах.

Что в c++ называют трейтами?

Compile-time требования к типу, а точнее — функции для их проверки.

Посмотри содержимое стандартного хедера <type_traits>.

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

ну-ну. Сериализаторы без рефлексии писать особенно весело

Кстати да, валидный юзкейс.

ну-ну. Сериализаторы без рефлексии писать особенно весело

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

Лучшеб вместо ASIO полноценный корутинный AIO сделали.

да, именно так. Именно поэтому от этого избавляться надо

Лучшеб вместо ASIO полноценный корутинный AIO сделали.

Они там уже пилят корутинки, было бы очень неплохо, если Networking TS обвязали с ними.

Надеюсь комитет имеет хоть каплю common sense и подрежет мелополезные мелочи дизайна.

Доооооо

но ума не приложу, какой

Ну когда придумаешь, кричи

Лучшеб вместо ASIO полноценный корутинный AIO сделали.

Ну корутины надо запилить сначала. Там челы делают демки с асио+корутины

Лишь бы не в шарпостиле.

А чем тебе асинк авейт не нра?

На std::future вязать, топ будет.

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

А на стейтфул корутинах НЕ awaitable-ных я писал тонны кода — это очень удобно.

Пишешь — ни о чем не думаешь. Обычный синхронный код, а он «магически» работает как асинхронный.

Ну это вроде забыли завезти, там co_await в пропозале же

На std::future вязать, топ будет.

Он кривой настолько что нам пришлось писать полностью свой

Он кривой настолько что нам пришлось писать полностью свой

+

Лучше бы раст-лайк каналы завезли.

Гм, ну хорошо, я его не использовал, что в нём не так?

Он кривой настолько что нам пришлось писать полностью свой

В 20-м поправят)

Ну, проблемы с ним начались еще с того момента, когда кажется PJ Plauger некомплаентно стандарту написал его деструктор.

а что не так с дтором

В гнутых либстд и по стандарту деструктор у шареного объекта должен вызывать wait, а у мсвц он не вызывал.

Странно, конечно, что он нарушил стандарт, зная его.. нафиг он это сделал..

Но это так, не очень большая беда. Больше всего критики конечно в том, что разворачивать и обрабатывать значение всё равно приходится в контексте владеющем фьючером.