хотя там куча крутых людей сидит как я понял

по старинке на емейлы писать

Слава, результат был отрицательным?

На попытку два указателя -> сброс?

у меня нет слаки :(

в браузере открой

Все "крутые чуваки" имеют как минимум электронную почту. Лучше всего именно через email и обращаться.

/stat@combot

Я например принципиально не стану решать вопросы в чатиках. Только email и с подписью ЭЦП.

Слава, результат был отрицательным?

пока не успел затестить, еще только на работу еду)

Я например принципиально не стану решать вопросы в чатиках. Только email и с подписью ЭЦП.

ишь ты какой принципиальный

ишь ты какой принципиальный

Ага. В чатике твой собеседник потом скажет: "Ничего я не помню, о чём мы с тобой договаривались". А в случае email всё здесь, с подписями и служебными заголовками. От своих слов отказаться уже не выйдет.

ну это... такой... дикарский подход несколько

ничем не отличается от "по емейлу ничего не докажешь, а вот на бумаге с гербовой печатью - вот оно всё"

Поэтому у нас вся переписка либо ведётся через email, либо в баг-трекере. Всё остальное - просто общение.

ничем не отличается от "по емейлу ничего не докажешь, а вот на бумаге с гербовой печатью - вот оно всё"

Как раз таки докажешь. ЭЦП + служебные заголовки - доказательство для суда.

а, ну если все вопросы через суд решать тогда конечно

рекомендую гербовую печать

а, ну если все вопросы через суд решать тогда конечно

Да не обязательно. Рабочие вопросы тоже лучше через email и баг-трекер ибо очень много людей, которые любят потом от своих слов отказываться.

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

сфера большая, где-то и такие пригодятся

кроме того в чатике другие люди могут ответить

кроме того в чатике другие люди могут ответить

Для этого списки рассылки есть.

У нас в Fedora Project именно в списках рассылки решаются вопросы. Письма также должны быть подписаны GPG.

Для этого списки рассылки есть.

щас бы в 2к17 получать сотни ненужных мейлов в день

воу воу

щас бы в 2к17 получать сотни ненужных мейлов в день

Советую осилить почтовые клиенты и фильтры.

список рассылки это отлично... просто прекрасно. а за оверквотинг вы там что делаете?

У нас в Fedora Project именно в списках рассылки решаются вопросы. Письма также должны быть подписаны GPG.

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

или почтовый тред 40 уровневой вложенности это норма?

список рассылки это отлично... просто прекрасно. а за оверквотинг вы там что делаете?

Большинство научились цитировать только нужное. 😊

Советую осилить почтовые клиенты и фильтры.

освоил, количество мейлов не уменьшилось😌

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

IRC чат в помощь, в т.ч. для разработчиков по инвайтам.

освоил, количество мейлов не уменьшилось😌

У меня в день приходит более 500.

IRC? то есть логи чатов еще и отдельно хранить

божечки

IRC чат в помощь, в т.ч. для разработчиков по инвайтам.

это все лишь бы не использовать что-нибудь придуманное в 21 веке?)

IRC? то есть логи чатов еще и отдельно хранить

Для трёпа IRC, для решения вопросов - списки рассылки и баг-трекер. Так в большинстве опенсорц проектов.

это все лишь бы не использовать что-нибудь придуманное в 21 веке?)

Слишком много ретроградов. Их не заставишь перейти в Telegram. Хотя у нас есть и Telegram чатик для разработчиков.

Есть рабочие IRC чаты ?

я могу только сказать - УДОБНО, ОЧЕНЬ УДОБНО

Есть рабочие IRC чаты ?

Да куча их. Смотри на сеть FreeNode.

Ок, спасибо!

Для этого следует согласовать время аудио-видеоконференции Через email

Слишком много ретроградов. Их не заставишь перейти в Telegram. Хотя у нас есть и Telegram чатик для разработчиков.

ну вот, в этом проблема в итоге

перешли б на гитхаб+гиттер например, как бы было удобно

https://groups.google.com/a/isocpp.org/d/msg/std-proposals/4wOU-1_3D0A/lVkUWPgpAQAJ

я тут вообще зашиваюсь, так что сейчас поспрашиваю соседей, может кто захочет поревьюить

не принимать :(

не опасно ли хранить shared_ptr на самого себя в самом себе? class Something { protected: std::shared_ptr<Something> _me; public: Something() : _me(this) {} }

блин, жесть

а можно нескромный вопрос: зачем тебе это?

а можно нескромный вопрос: зачем тебе это?

примитив может оборачиваться в Wrapper класс, который передаётся JavaScript движку. За врапер отвечает сборщик мусора JS, за сам примитив отвечаю я. враперу я передаю shared_ptr на примитив чтоб если того удалил gc - он удалил примитив, если тот ещё существует. внутри примитива держу shared_ptr на него же чтобы при желании сказать terminate(), сбавить ref count, но не удалиться, если ещё есть враперы

примитив может оборачиваться в Wrapper класс, который передаётся JavaScript движку. За врапер отвечает сборщик мусора JS, за сам примитив отвечаю я. враперу я передаю shared_ptr на примитив чтоб если того удалил gc - он удалил примитив, если тот ещё существует. внутри примитива держу shared_ptr на него же чтобы при желании сказать terminate(), сбавить ref count, но не удалиться, если ещё есть враперы

Так ведь враппер уже держит shared_ptr на примитив, пусть просто отпускает его и все

вроде похоже на твой кейс https://stackoverflow.com/questions/11711034/stdshared-ptr-of-this

Так ведь враппер уже держит shared_ptr на примитив, пусть просто отпускает его и все

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

Так ведь враппер уже держит shared_ptr на примитив, пусть просто отпускает его и все

если garbage collector удалит врапер, то тот может потянуть за собой сам примитив, НО этого произойти не должно, потому-что примитив представляет собой асинхронную операцию, которая сама решает когда она готова к удалению (внутри она вызывает die() по завершению, это должно декрементировать reference counter, но удалить только если на примитив нет ссылок)

примитив может оборачиваться в Wrapper класс, который передаётся JavaScript движку. За врапер отвечает сборщик мусора JS, за сам примитив отвечаю я. враперу я передаю shared_ptr на примитив чтоб если того удалил gc - он удалил примитив, если тот ещё существует. внутри примитива держу shared_ptr на него же чтобы при желании сказать terminate(), сбавить ref count, но не удалиться, если ещё есть враперы

А тот кто говорит примитиву "terminate" - он как его находит?

если garbage collector удалит врапер, то тот может потянуть за собой сам примитив, НО этого произойти не должно, потому-что примитив представляет собой асинхронную операцию, которая сама решает когда она готова к удалению (внутри она вызывает die() по завершению, это должно декрементировать reference counter, но удалить только если на примитив нет ссылок)

Да, норм, хоть и выглядет немного странно)

А тот кто говорит примитиву "terminate" - он как его находит?

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

Я как-то писал класс-камикадзе с delete this, из-за кривого дизайна внешней библиотеки

просто на данный момент у меня SEGFAULT, и я не совсем уверен где именно, но подозревеаю что это из-за shared_ptr на себя-же

Хм

возможно shared_ptr<T> (this) опасно?

Погони с асаном

возможно shared_ptr<T> (this) опасно?

Не вижу проблемы

Разве что race condition где-то

shared_ptr сам по себе не thread safe

shared_ptr сам по себе не thread safe

shared_ptr не thread-safe как объект и thread-safe как указатель, правильно жи?

а если стрим не нужен? мы вызовем деструктор, который вызовет деструктор _me, который вызовет delete для this тобишь два раза деструктор для стрима разве не?

shared_ptr не thread-safe как объект и thread-safe как указатель, правильно жи?

Ага

.....

Да, вопрос: в определенной версии МС компилятора была "фича", что если класс не имеет полей, деструктор не вызывается. Это была бага или какая-то "фича" стандарта?

всем привет

а если стрим не нужен? мы вызовем деструктор, который вызовет деструктор _me, который вызовет delete для this тобишь два раза деструктор для стрима разве не?

delete this в деструкторе это UB

а если стрим не нужен? мы вызовем деструктор, который вызовет деструктор _me, который вызовет delete для this тобишь два раза деструктор для стрима разве не?

Не, на момент деструктора me не может указывать на себя

Не, на момент деструктора me не может указывать на себя

т.е. shared_ptr(this) = опасно?

надо написать небольшой тест кейс

Наоборот (если объект не удаляется явно через delete и не выделяется на стоке)

template <typename TArgument> inline DWORD WINAPI run_thread__start_routine(LPVOID lpParam) { std::unique_ptr<run_thread__start_routine__param_type<TArgument>> param( (run_thread__start_routine__param_type<TArgument> *)lpParam ); std::shared_ptr<TArgument> argument = std::atomic_load(&param->m_argument); param->m_lpRoutine(argument); return 0; }; template <typename TArgument, typename TEngine> inline void run_thread(void(*lpRoutine)(std::shared_ptr<TArgument>), std::shared_ptr<TArgument> argument, TEngine &engine) { run_thread__start_routine__param_type<TArgument> *param = new run_thread__start_routine__param_type<TArgument>(); param->m_lpRoutine = lpRoutine; std::atomic_store(&param->m_argument, argument); engine.Run(&run_thread__start_routine<TArgument>, (LPVOID)param); }; это жи правильный код запуска треда? :)

и да, меня не волнует вопрос, что будет, если поток будет плеваться исключениями и что engine может запустить winapi thread, не инициализировав правильно C++ runtime