У меня тоже б скручивались... 21-вый век, а ты — РЕГИСТР!

21-й век, у тебя процессор до сих пор из кремния и на переменном токе

Точно на переменном?

21-й век, у тебя процессор до сих пор из кремния и на переменном токе

Я к тому, что у них мотороллер и смузи, а ты им — РЕГИСТР!

Понимать надо!

Вообще-то, гироскутер

а почему "всяко" быстрее? jni-вызов это ж, по сути, dlopen/dlsym на функцию из библиотеки, т.е. однократный хэш-лукап с последующим исполнением уже скомпилированного ahead-of-time бинарного года. А в случае грааля, насколько я понимаю, нужно jit-скомпилить биткод, а потом получить возможные кэш-промахи при загрузке бэйсик-блоков...

первая ссылка в гугле — https://stackoverflow.com/a/7809300

впрочем, я, мягко говоря, не знаток ни джавы, ни дживиэма)

первая ссылка в гугле — https://stackoverflow.com/a/7809300

Спасибо, но пост не отвечает на вопрос. Это абсолютная оценка стоимости JNI-вызовов, а не относительная оценка с граалем. Jit-компиляция и foreign function callы достаточно сложная тема касательно оценки производительности. Оценивать, наверное, нужно на реальных проектах. Поэтому интересно, почему и когда грааль может быть быстрее

@zamazan4ik ты ж уже игрался? Мб, интересно будет забенчмаркать?

Расскажите что-нибудь хорошее про stackless-корутины. По крайней мере, что там в бусте. Я так понял, их «stackless» выражается только в том, что при переходе в работу/ожидание их настоящий стек копируется куда-нибудь в обычныю память и там живёт?

нет. ты просто делаешь статик переменные и они сохраняются между вызовами

а стек копировать весь каждый раз при переключении контекста это такой оверхед жирный

в бусте стеклесс только в асио вроде

в coroutine там стековые. стек выделяется ммапом, как у больших мальчиков

Вот я и удивился. Как тогда можно из корутины вызвать другую корутину?

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

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

То есть, ответ «никак». Напоминает разницу между питонами, где в обоих есть генераторы, но в третьем есть yield from, а во втором люди обмазываются костылями.

разве никак? Может я конечно неправильно их понимаю, но вызывать можно. Стаклесс роутина это же (условно) обьект со всеми переменными + индекс текущего участка кода, куда мы прыгнем во время очередного входа в рутину. Что мешает вызывать из рутины повыполнять другую рутину и вернутся?

То есть, ответ «никак». Напоминает разницу между питонами, где в обоих есть генераторы, но в третьем есть yield from, а во втором люди обмазываются костылями.

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

разве никак? Может я конечно неправильно их понимаю, но вызывать можно. Стаклесс роутина это же (условно) обьект со всеми переменными + индекс текущего участка кода, куда мы прыгнем во время очередного входа в рутину. Что мешает вызывать из рутины повыполнять другую рутину и вернутся?

Получается, что вместо системного стека сами корутины соберутся в связный список?

Выходит что так, если хендлер рутины не глобальный. Но тут я не очень уверен. Я бы хотел поиграться с текущей реализацией пропозала рутин, но я так понимаю она есть только в msvc

Дано: источник - массив чаров назначение - под какой-то Что лучше кастануть первое ко второму или второе к первому?

Дано источник: строка, назначение: файл, что лучше, прочитать строку из файла или записать строку в файл? Можно все же как-то побольше осмысленности?)

Дано источник: строка, назначение: файл, что лучше, прочитать строку из файла или записать строку в файл? Можно все же как-то побольше осмысленности?)

Нет байтики и так и так одинаково присвоятся

Ну вот ты и ответил на свой вопрос!)

Может там есть разница?

Или стилевая хотябы

Что-то мне подсказывает что каст источника + оператор= хуже

Да, если кастануть под в массив - будет нечитаемая обрывающаяся на первом 0 строка, а если массив в под - будет както забитый данными под

Может все же расскажешь, что ты пытаешься сделать?

Может все же расскажешь, что ты пытаешься сделать?

Это не я, просто пришло в голову что я не могу выбрать если плпадется

Обосновать выбор не могу

А видео будет? я бы про самопальные фьючеры посмотрел

24 мая в Санкт-Петербургском офисе компании JetBrains пройдет встреча, организованная C++ User Group. На встрече Денис Кормалёв расскажет о реализации Future и Promise своими силами, и как он с его коллегами пришли к такому решению. Подробности и регистрация - по этой ссылке: https://www.meetup.com/ru-RU/St-Petersburg-CPP-User-Group/events/250081776/?eventId=250081776 #meetup #jetBrains #cppUserGroud #спб #питер #future #promise #async

хотя ссылки на гитхаб мне бы хватило )

@DenisKormalev

хотя ссылки на гитхаб мне бы хватило )

closed source

closed source

тогда видос

тогда видос

если джетбрейнс сделает, то будет :) говорят, что обычно делают

круто

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

ок, после митапа дёрну, возьму все, что есть )

@zamazan4ik ты ж уже игрался? Мб, интересно будет забенчмаркать?

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

ASIO (или буст вообще) как-то можно научить в error_code::message писать больше информации? а то прилетело в лог http request, и сиди раскапывай, что волшебное число 336027804 прилетело к тебе из openssl и означает SSL23_GET_CLIENT_HELLO, причем в самом openssl оно непонятно как формируется

Можно. Завдите issue на Asio https://github.com/boostorg/asio

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

Нет

народ, кто-нибудь юзает критор для своих make-based проектов?

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

да, shared_ptr, unique_ptr

это не GC

Это не он

это базис под него, как я понимаю

для подсчёта ссылок

это не GC

это он и есть

В си++ просто не пишут так чтобы был нужен gc обычно, потомучто объекты в стеке

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

ну да

это грустное "ну да"

потому что в славном D на нём завязана удобная работа с массивами, строками, и проч

ну да

на худой конец, аллокаторы заюзай

но я щас очень жёстко наебнулся об него

Насколько я знаю в Д он отключаемый

плохо знаешь

ERROR: S client not available

это он и есть

гц циклические ссылки может (иногда) собрать

отключишь и потеряешь часть полезного функционала

чуть не до обработки исключений

гц циклические ссылки может (иногда) собрать

да, с помощью weak_ptr-a

Насколько я знаю в Д он отключаемый

отключаемый, но стандартная либа без GC не пашет

гц циклические ссылки может (иногда) собрать

да, при наличии слабых ссылок

отключаемый, но стандартная либа без GC не пашет

есть проекты по nogc-stdlib

типа для контроллеров

но я щас очень жёстко наебнулся об него

А чо там?

и раздуть применимость betterC

есть проекты по nogc-stdlib

есть проекты и работает без GC прямо сейчас - разные вещи

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

так как сама либа должна без GC работать, а вот само приложение - это уже на вкус и цвет

А чо там?

есть три объекта, создаются в дочернем потоке, владеют друг другом по схеме: A -> B -> C в деструкторе A пишу "передай привет В". привет заключается в вызове метода класса B (нестатического) программа при завершении сегфолтится отладка показала, что тред успешно завершается, вся память под объекты в нём становится недоступна, и начинает затираться в рандомной последовательности. в итоге когда взывается деструктор А, объекта В чаще всего уже не существует и всё это в порядке нормы, "так и должно быть" а конструктива для финализации объектов не придумано кроме: - юзай без ГЦ (отвал исключений и прочих радостей) - юзай в scope (объект заворачивается в структуру и финализируется нормально) - дёргай финализатор ручками

даже когда баба бросила не было так больно

да, с помощью weak_ptr-a

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

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

удивительно

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

а, да, точно? года два назад я слышал, что циклическое владение без слабых ссылок успешно сливает память

в яве, кнешн

https://stackoverflow.com/questions/1910194/how-does-java-garbage-collection-work-with-circular-references

есть три объекта, создаются в дочернем потоке, владеют друг другом по схеме: A -> B -> C в деструкторе A пишу "передай привет В". привет заключается в вызове метода класса B (нестатического) программа при завершении сегфолтится отладка показала, что тред успешно завершается, вся память под объекты в нём становится недоступна, и начинает затираться в рандомной последовательности. в итоге когда взывается деструктор А, объекта В чаще всего уже не существует и всё это в порядке нормы, "так и должно быть" а конструктива для финализации объектов не придумано кроме: - юзай без ГЦ (отвал исключений и прочих радостей) - юзай в scope (объект заворачивается в структуру и финализируется нормально) - дёргай финализатор ручками

100% такого в детерминированной программе происходить не может

если A владеет B, B владеет С, и создавались они в этой же последовательности, то кровь из носа они уйдут из жизни только при уничтожении A.

100% такого в детерминированной программе происходить не может

это у вас в С++ объекты детерминированно дестроятся в Ди ГЦ похуй вплоть до того, что поле объекта может быть уничтожено раньше чем вызовется деструктор объекта у меня это и происходит. поле-объект уничтожается раньше вызова деструктора владеющего класса

это у вас в С++ объекты детерминированно дестроятся в Ди ГЦ похуй вплоть до того, что поле объекта может быть уничтожено раньше чем вызовется деструктор объекта у меня это и происходит. поле-объект уничтожается раньше вызова деструктора владеющего класса

погоди, мы о D?

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

сорри, выбился из контекста

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

потому он тупо в рандомном порядке её затирает?

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

как-то так