Обновить
0
0

Пользователь

Отправить сообщение

Раст набрал свою популярность за счет того, что плюсовики устали дебажить и фиксить баги, копаясь в тоннах тухлого легаси. От того, что кто-то научился ходить не наступая на грабли, он умнее не становится, он просто зазубрил маршрут. Иногда складывается впечатление, что вот такие фанатики/защитники плюсов своими выпадами пытаются хоть как-то оправдать те годы мучений и страданий с этим недоразумением. Такая тактика приведет, и уже приводит, к ровно противоположному.

У меня были аналогичные требования, остановился на Asus RT-AX59U. Есть USB, целых 2 штуки.

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

наконец-то 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 Кб использовано

Использовать push_front чтобы позже превратить коллекцию в итератор — это тоже плохой паттерн. В модуле std::iter есть много полезного, например:

    let first = "first".to_owned();
    let rest = vec!["second".to_owned(), "third".to_owned()];
    std::iter::once(first).chain(rest)

Я привел аналогию, а не определение. Не надо придираться к словам.

Ну вот это огромное заблуждение. Я не говорю, что 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

Насчет повторной отправки я не понимаю, в чем проблема. Есть каналы, которые отлично решают эту проблему:

class MyViewModel(repository: MyRepository) : ViewModel() {
    private val trigger = Channel<String>(Channel.CONFLATED)

    fun setQuery(query: String) {
        trigger.trySend(query)
    }

    val results: Flow<SearchResult> = trigger
    		.receiveAsFlow()
    		.mapLatest { query -> repository.search(query)}
    		.stateIn(
        		scope = viewModelScope,
        		started = SharingStarted.WhileSubscribed(5000L),
        		initialValue = SearchResult.EMPTY
    		)
}

Информация

В рейтинге
5 415-й
Зарегистрирован
Активность