shared_ptr разумно в многопоточных программах использовать

а как же shared_ptr поможет в многопоточных программах? Хотелось бы посмотреть пример, хотя бы простенький.

а как же shared_ptr поможет в многопоточных программах? Хотелось бы посмотреть пример, хотя бы простенький.

Пример чего? Просто создавай ptr, создавай тред, передавай туда птр и завершай текущую функцию.

и будет гонка за деструктором.

а как же shared_ptr поможет в многопоточных программах? Хотелось бы посмотреть пример, хотя бы простенький.

В определении владения ресурсом поможет, если уже определен менеджер памяти(где атомарных 2 счетчика и водятся)

Пример чего? Просто создавай ptr, создавай тред, передавай туда птр и завершай текущую функцию.

понял, спасибо.

ну, все равно. Стоимость атомарного инкремента это где-то 10-20 инструкций (не уверен за точность, может сильно ошибаюсь), а async_connect это syscall должен быть.

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

В однопоточной программе shared_ptr имхо в 99% случаев можно заменить на uniq_ptr

Здрасьте, приехали.... Как поточность вообще связана с необходимостью shared ? Shared нужен когда владение коллективное.

Здрасьте, приехали.... Как поточность вообще связана с необходимостью shared ? Shared нужен когда владение коллективное.

?

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

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

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

Системный вызов за абстракцией boost asio io_context и на тот момент вообще не вызывается, а только ставится в список задач, которые будут исполнены вообще другим потоком, в котором boost::asio::io_context::run вызовится, так что уже 2 потока используют атомарные переменные при копии std::shared_ptr

Системный вызов за абстракцией boost asio io_context и на тот момент вообще не вызывается, а только ставится в список задач, которые будут исполнены вообще другим потоком, в котором boost::asio::io_context::run вызовится, так что уже 2 потока используют атомарные переменные при копии std::shared_ptr

спасибо

Здрасьте, приехали.... Как поточность вообще связана с необходимостью shared ? Shared нужен когда владение коллективное.

Никак не связана, нет связи. Но есть корреляция

Никак не связана, нет связи. Но есть корреляция

Да нет вообще.

https://godbolt.org/z/1LHVm1 ( ͡° ͜ʖ ͡°) ( ͡☉ ͜ʖ ͡☉) ( ͡◉ ͜ʖ ͡◉)

хе-хе, трай-кетч в списке инициализации, норм

В однопоточной программе shared_ptr имхо в 99% случаев можно заменить на uniq_ptr

вот есть у меня 2 разных индекса над набором данных - и мне нужен shared_ptr, хоть у меня и один поток

вот есть у меня 2 разных индекса над набором данных - и мне нужен shared_ptr, хоть у меня и один поток

Что будет в shared_ptr?

указатель?

вот есть у меня 2 разных индекса над набором данных - и мне нужен shared_ptr, хоть у меня и один поток

А с каких пор индексы владеют данными?

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

linux embed это значит никакого C++17 и STL или не все так плохо?

linux embed это значит никакого C++17 и STL или не все так плохо?

кто сказал?

я вообще под stm32 пишу на С++17 и мне норм

а под линукс тем более все хорошо

я вообще под stm32 пишу на С++17 и мне норм

А какие могут быть ограничения в использовании STL если в вакансии пишут arm, Linux embedded?

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

Может я с 99% хватил конечно. Но о рефакторинге я бы задумался в однопоточной программе если вижу shared_ptr - выглядит как что-то неправильное.

А какие могут быть ограничения в использовании STL если в вакансии пишут arm, Linux embedded?

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

Современный «linux embed» — это небось «воткнуть в качестве контроллера малинку», а на ней не то что c++17, третью кваку без проблем запустить можно.

linux embed это значит никакого C++17 и STL или не все так плохо?

у нас в железоотделе linux 4.17 и gcc 8.

так что всё ок.

а вот просто embed, без linux - там уж как повезёт.

а вот просто embed, без linux - там уж как повезёт.

может там ваще говнокод 5 летней давности на си :)

может там ваще говнокод 5 летней давности на си :)

5 лет — это очень неплохо ещё )

может там ваще говнокод 5 летней давности на си :)

Я видел говнокод 12 летней давности на вперемешку C/C++ так что не страшно (: +winapi

5 лет — это очень неплохо ещё )

ну, по стилю кодирования может быть как K&R C

ну, по стилю кодирования может быть как K&R C

но сдругой стороны, может быть и вполне c++11 )

а K&R C и сейчас можно встретить. Тут не угадаешь.

современные компиляторы могут и не дружить с K&R. Там, с параметрами функций вне скобок, варианты с for(int i...);

да, они обычно и не дружат

ну, по стилю кодирования может быть как K&R C

Я однажды собирал код, который старше меня

Он собрался и упал в SEGFAULT

И это при том, что мне уже почти 30

Представляете, какой старинный код?

современные компиляторы могут и не дружить с K&R. Там, с параметрами функций вне скобок, варианты с for(int i...);

gcc отлично дружит

Я к сожалению не помню, был ли это K&R

Покритикуйте пожалуйста https://stdcpp.ru/proposals/6d126adc-7852-41f7-8fdf-d0a8e9cccf72

Делаю DSL для описания аппаратуры на C++, по аналогии с Chisel/Scala https://chisel.eecs.berkeley.edu/ . И столкнулся с тем что нет удобного способа передачи параметров в in-class инициализаторы

Никакого удобного решения на макросах/шаблонах не получается

Есть у кого канал такой как этот, только по java?

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

Это несомненно, просто интересно было прочитать замечания сообщества.

Я однажды собирал код, который старше меня

да, было дело во время диплома искал реализацию нейронечёткой сети, нашёл какую-то сишную - а она 80х годов выпуска, с пропуском типов для int и типами параметров после списка параметров

Никакого удобного решения на макросах/шаблонах не получается

конструировать через статическую функцию класса? а конструктор сделать приватным

конструировать через статическую функцию класса? а конструктор сделать приватным

А как передать параметры в in-class инициализаторы. В этом основная проблема

Пример кода (в конце страницы class Fifo[T <: Data](gen: T, n: Int) extends Module) который хочется повторить https://github.com/freechipsproject/chisel3/wiki/Polymorphism-and-Parameterization

Просто в текущем варианте in-class инициализаторы достаточно бесполезны.

Я понимаю есть аргумент против этого в виде раздельной компиляции (конструктор должен быть в .cpp). Но вроде как модули это должны решить

Т.е. если будут модули, то можно и безболезненно добавить primary constructor

Т.е. комбинация из шаблонных параметров и параметров конструктора описывают интерфейс создания объекта. А тело класса уже содержит код для инициализации

Просто в текущем варианте in-class инициализаторы достаточно бесполезны.

я так понимаю, простой member initializer list не подходит только с точки зрения красоты кода?

member initilizer находится далеко от места объявления поля

Т.е. он работает но ухудшает читаемость кода

А как передать параметры в in-class инициализаторы. В этом основная проблема

вычисляешь их в статической функции класса и передаёшь в приватный конструктор как параметры

вычисляешь их в статической функции класса и передаёшь в приватный конструктор как параметры

Поясни. Они всё равно не будут в области видимости in-class инициализаторов

На данный момент в in-class инициализаторах можно использовать только шаблонные параметры. Но шаблоны это compile-time API, часто хочется иметь возможность параметризовать объекты и в runtime

Пример: template <unsigned RPTR_W = 10> class MyFIFO { public: MyFIFO(unsigned WPTR_W = 10) {} private: sc_int rptr{RPTR_W}; // OK! sc_int wptr{WPTR_W}; // Compile Error! };

Поясни. Они всё равно не будут в области видимости in-class инициализаторов

сори, перепутал с member initialization list

@ripopov https://godbolt.org/z/dIW08_ а такое устраивает?

@ripopov https://godbolt.org/z/dIW08_ а такое устраивает?

а так точно легально делать? гарантируется, что S(int x) вызовется до инциализатора y?

а так точно легально делать? гарантируется, что S(int x) вызовется до инциализатора y?

хороший вопрос)

Гарантируется

ща буит мясо ... а бывают в природе утилиты для профайлинга мейкфайлов? особенно с flamegraph-совместимым выхлопом?

Но агрегатная инициализация для структур это не то

@ripopov вообще говоря, я не совсем понимаю идею primary constructors. Например, не понимаю может ли при этом быть ещё конструктор или он обязан быть единственным? Где бы про это почитать?

@ripopov вообще говоря, я не совсем понимаю идею primary constructors. Например, не понимаю может ли при этом быть ещё конструктор или он обязан быть единственным? Где бы про это почитать?

В доке на котлин понятно написано. Если есть ещё один конструктор, то он обязан вызвать primary

ща буит мясо ... а бывают в природе утилиты для профайлинга мейкфайлов? особенно с flamegraph-совместимым выхлопом?

Я компилировал Make с дебаг символами и юзал perf на нем.

Я компилировал Make с дебаг символами и юзал perf на нем.

мощно а там, питончик, гошечка, nodejs на худой конец?.. пересобирать binutils ну прям вообще DO NOT WANT )

А что мощного? Он вроде в пару команд собирался, ничего сложного.

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

хороший вопрос)

да, кажется гарантируется потому что есть строго определенные правила как инициализируются члены ( http://eel.is/c++draft/class.init#class.base.init-9 ) и есть правила что они инициализируются последовательно как было в обьявлении http://eel.is/c++draft/class.init#class.base.init-13.3

Нет, у него есть нормальные такие сорцы отдельно.

Даже собирается как "cd src && make" ?

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

Упс, вот не совсем. Я в свое время вычислил, какой тип команд тормозил (у меня было куча автогенеренных .s целей).

Тогда можно попытаться повтыкать output в Makefile, ну и дальше дедовскими методами

В общем что-то никто не покритиковыл идею primary конструкторов с точки зрения реализации. Как я понял основной аргумент против: Используйте синтаксис constructor initialization list из C++98 , всё и так хорошо.

Can you provide some feedback for this C++ idea / proposal? Primary constructors for C++ Problem: C++11 allows in-class member initialization. However, in-class initializers have no access to constructor parameters, which makes them useless in many scenarios. Example: template<typename T, unsigned INIT> class MyClass { public: MyClass(unsigned init) {} private: T x0 {INIT}; // OK T x1 {init}; // Error } So essentially in this case C++ favors compile-time template interfaces over run-time constructor interfaces. Possible solution: Primary constructors (similar to Scala, Kotlin and abandoned C# proposal) We can designate one constructor as primary. Parameters of primary constructor should be visible to in-class initializers. All other constructors must call primary constructor in their constructor initialization list. For example, we can use following syntax (similar to Scala/Kotlin): template<typename T, unsigned INIT> class MyClass (unsigned init) { public: // secondary ctor MyClass() : MyClass(42) {} private: T x0 {INIT}; // OK T x1 {init}; // OK }

Думаю залить на какой-нибудь англоговорящий форум за фидбеком. Не посоветуете куда?

reddit?

есть mailing list future proposals можешь туда )

А, я не так понял.

Думаю залить на какой-нибудь англоговорящий форум за фидбеком. Не посоветуете куда?

https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals

Can you provide some feedback for this C++ idea / proposal? Primary constructors for C++ Problem: C++11 allows in-class member initialization. However, in-class initializers have no access to constructor parameters, which makes them useless in many scenarios. Example: template<typename T, unsigned INIT> class MyClass { public: MyClass(unsigned init) {} private: T x0 {INIT}; // OK T x1 {init}; // Error } So essentially in this case C++ favors compile-time template interfaces over run-time constructor interfaces. Possible solution: Primary constructors (similar to Scala, Kotlin and abandoned C# proposal) We can designate one constructor as primary. Parameters of primary constructor should be visible to in-class initializers. All other constructors must call primary constructor in their constructor initialization list. For example, we can use following syntax (similar to Scala/Kotlin): template<typename T, unsigned INIT> class MyClass (unsigned init) { public: // secondary ctor MyClass() : MyClass(42) {} private: T x0 {INIT}; // OK T x1 {init}; // OK }

Чем этот подход лучше чем самому написать primary constructor и в нем поля проинициализировать?

Чем этот подход лучше чем самому написать primary constructor и в нем поля проинициализировать?

В этом случае инициализация отделена в коде от объявления, что снижает его читаемость

Плюс необходимо дублировать имена полей

В этом случае инициализация отделена в коде от объявления, что снижает его читаемость

Пример Что предлагается: class MyClass (int initX, int initY ) { int x = initX; int y = initY; } Что сейчас: class MyClass { int x; int y; public: MyClass(int initX, int initY) : x(initX) , y(initY) {} }

Понятно что на маленьких примерах разница не большая. Но в реальном коде часто бесит от обявлений полей переходить к конструктору чтобы понять как они инициализируются