Раст набрал свою популярность за счет того, что плюсовики устали дебажить и фиксить баги, копаясь в тоннах тухлого легаси. От того, что кто-то научился ходить не наступая на грабли, он умнее не становится, он просто зазубрил маршрут. Иногда складывается впечатление, что вот такие фанатики/защитники плюсов своими выпадами пытаются хоть как-то оправдать те годы мучений и страданий с этим недоразумением. Такая тактика приведет, и уже приводит, к ровно противоположному.
наконец-то battle.net начал нормально запускаться и нормально работать. исплоьзую раннер от kron4ek. но все равно после закрытия всех игр и приложения battle.net повторный запуск фейлится, приходится запускать через скрипт:
#!/bin/bash
BOTTLE_NAME=Blizzard
WINEPREFIX="$HOME/.var/app/com.usebottles.bottles/data/bottles/bottles/$BOTTLE_NAME"
for pid in $(ps -eo pid=); do
if grep -qaz "WINEPREFIX=$WINEPREFIX" /proc/$pid/environ 2>/dev/null; then
kill -9 $pid
fi
done
/usr/bin/flatpak run --command=bottles-cli com.usebottles.bottles run -p Battle.net -b $BOTTLE_NAME
Тестирую в виртуалке, пока остаюсь на 12. По поводу /tmp так я первым делом после установки ее в озу монтировал, за месяц аптайма (рабочая станция) 250 Кб использовано
Ну вот это огромное заблуждение. Я не говорю, что UB — это недостижимый код! Я говорю о том, что компилятор может и будет оптимизировать полагаясь на то, что UB никогда не происходит. Например, удаляя "лишние" с его точки зрения бранчи, в которых есть UB.
То, что оно случается, это правда. Только не иногда, а практически в любой достаточно большой кодовой базе.
UB означает, что может произойти все что угодно! Это не поведение, которое зависит от железа или компилятора! UB — это буквально недостижимый код с точки зрения компилятора, то, чего не может случиться никогда, и на что компилятор рассчитывает, применяя оптимизации. Потому что если это случилось — значит код, который был скомпилирован, буквально НЕ является программой на С/С++.
потому что при реализации delete/remove в lock-free структурах данных вы не можете просто вызвать деструктор, а использование Arc (shared_ptr) для каждой ноды это слишком дорогое удовольствие и лучше уж использовать тогда mutex. ну как вариант - использование hazard pointers или Epoch-Based Reclamation (который и можно считать тем самым mini-gc)
проблемы начинаются тогда, когда вы пытаетесь реализовать что-то по типу ConcurentHashMap с java. В языках без gc вам так или иначе придется написать свой мини-gc или использовать блокирующие алгоритмы.
проблемы начинаются тогда, когда вы пытаетесь реализовать что-то по типу ConcurentHashMap с java. В языках без gc вам так или иначе придется написать свой мини-gc или использовать блокирующие алгоритмы
здесь все очень просто, unwrap() буквально означает "я ожидаю получить значение, иначе это баг в приложении". собственно, паника существует именно для таких ситуаций. если в приложении баг - его не надо обрабатывать, максимум залогировать.
не важно, реализован Copy или нет, в любом случае данные на стеке всегда копируются побитово, для абсолютно любой структуры без исключения. только Pin препятствует этому. все, что делает Copy, так это позволяет использовать обе переменные, а без него старое значение просто считается невалидным/не инициализирован мы/отсутствующим.
Раст набрал свою популярность за счет того, что плюсовики устали дебажить и фиксить баги, копаясь в тоннах тухлого легаси. От того, что кто-то научился ходить не наступая на грабли, он умнее не становится, он просто зазубрил маршрут. Иногда складывается впечатление, что вот такие фанатики/защитники плюсов своими выпадами пытаются хоть как-то оправдать те годы мучений и страданий с этим недоразумением. Такая тактика приведет, и уже приводит, к ровно противоположному.
У меня были аналогичные требования, остановился на Asus RT-AX59U. Есть USB, целых 2 штуки.
ну да, зачем фиксить критические уязвимости, если и с ними все работает, иногда даже быстрее, чем с фиксами
наконец-то battle.net начал нормально запускаться и нормально работать. исплоьзую раннер от kron4ek. но все равно после закрытия всех игр и приложения battle.net повторный запуск фейлится, приходится запускать через скрипт:
Тестирую в виртуалке, пока остаюсь на 12. По поводу /tmp так я первым делом после установки ее в озу монтировал, за месяц аптайма (рабочая станция) 250 Кб использовано
Использовать
push_frontчтобы позже превратить коллекцию в итератор — это тоже плохой паттерн. В модулеstd::iterесть много полезного, например:Я привел аналогию, а не определение. Не надо придираться к словам.
Ну вот это огромное заблуждение. Я не говорю, что UB — это недостижимый код! Я говорю о том, что компилятор может и будет оптимизировать полагаясь на то, что UB никогда не происходит. Например, удаляя "лишние" с его точки зрения бранчи, в которых есть UB.
То, что оно случается, это правда. Только не иногда, а практически в любой достаточно большой кодовой базе.
UB означает, что может произойти все что угодно! Это не поведение, которое зависит от железа или компилятора! UB — это буквально недостижимый код с точки зрения компилятора, то, чего не может случиться никогда, и на что компилятор рассчитывает, применяя оптимизации. Потому что если это случилось — значит код, который был скомпилирован, буквально НЕ является программой на С/С++.
потому что при реализации delete/remove в lock-free структурах данных вы не можете просто вызвать деструктор, а использование Arc (shared_ptr) для каждой ноды это слишком дорогое удовольствие и лучше уж использовать тогда mutex. ну как вариант - использование hazard pointers или Epoch-Based Reclamation (который и можно считать тем самым mini-gc)
проблемы начинаются тогда, когда вы пытаетесь реализовать что-то по типу ConcurentHashMap с java. В языках без gc вам так или иначе придется написать свой мини-gc или использовать блокирующие алгоритмы.
проблемы начинаются тогда, когда вы пытаетесь реализовать что-то по типу ConcurentHashMap с java. В языках без gc вам так или иначе придется написать свой мини-gc или использовать блокирующие алгоритмы
в данном случае уместней использовать
"hello".to_owned()здесь все очень просто, unwrap() буквально означает "я ожидаю получить значение, иначе это баг в приложении". собственно, паника существует именно для таких ситуаций. если в приложении баг - его не надо обрабатывать, максимум залогировать.
Зачем в обычном статическом счетчике использовать
Orgering::SeqCstкогда там всегда достаточноOrdering::Relaxed?не важно, реализован Copy или нет, в любом случае данные на стеке всегда копируются побитово, для абсолютно любой структуры без исключения. только Pin препятствует этому. все, что делает Copy, так это позволяет использовать обе переменные, а без него старое значение просто считается невалидным/не инициализирован мы/отсутствующим.
есть отличный пример от google
https://github.com/google/iosched
Насчет повторной отправки я не понимаю, в чем проблема. Есть каналы, которые отлично решают эту проблему: