Могу сказать, что за восемь лет жизни на D я ни разу не нарушил безопасность памяти, т.к. почти всегда мы имеем дело с D-шными массивами, по которым мы проходим с foreach, а если обратиться к несуществующему элементу, будет кинуто исключение. А трогать указатели нам нужно крайне редко, использовать же их арифметику совсем не нужно в обычном коде. Для особых случаев статья рассказывает, как последние нововведения языка помогают избегать проблем. Вспомнил: безопасность памяти я нарушал разве что тогда, когда неправильно портировал Си-шные сигнатуры функций, тогда у меня происходило нарушение работы стека
Можно, например, создать указатель с помощью malloc, арифметикой указателей выйти за пределы выделенной области и передать это чудо в @safe-функцию. Или прямо можно написать любую ерунду вроде void* ptr = cast(void*)0x77 и передать в @safe-функцию, потому что @safe-функция не будет отслеживать всё, что происходит снаружи. Так что программист по-прежнему должен быть адекватен и знать, что он делает, особенно, если это происходит за пределами @safe
Нет, @safe, @trusted, @system друг с другом не компонуются. По умолчанию используется @system, и большую часть своего кода я, например, писал в этом режиме. Основная опасность — это всё-таки работа с указателями, но они редко нужны (в основном для взаимодействия с кодом на Си). Если специально не заморачиваться, ситуации выхода за пределы допустимой памяти невероятны. Ссылки на память из освобождённого стека более вероятны, и как раз написанное в статье помогает избежать проблем, но это тоже специфические случаи
Редко приходится пользоваться, но когда приходится — довольно удобно (можно и continue так же использовать). Плюс в switch-case-конструкциях можно использовать goto для перехода именно к нужному case, но это совсем не пригождалось.
Впечатление, что плагин nvim-tree не работает: "Это не команда редактора: NvimTreeRefresh". Help для nvim-tree работает, но самих его команд не появилось. Во всяком случае, при neovim версии 0.6.1
Не могу согласиться с другими комментаторами: на 7,8 дюймов (у меня Kon-Tiki 2) я вполне читаю DJVU и PDF. Тем более, что при чтении можно "обрезать" лишние белые области
К слову сказать, все подобные картинки не являются правдой. Как человек с цветоаномалией я должен был бы столбец с "обычным зрением" видеть так же, как один из трех следующих. Но они все очень разные
capacity никогда не меняется и странно взаимодействует с size. Непохоже, что перераспределение памяти может работать
Отдалённым аналогом AUR для DEB-дистрибутивов и RPM-дистрибутивов может служить Open Build Service. Сам пользуюсь несколько лет
Потому что там должна быть табуляция вместо пробелов
Спасибо, это верно, ранее я не использовал этот способ. Сделал пару правок в статье.
"Большие модели не более способны в долгосрочной перспективе, если мы можем быстрее итерироваться на маленьких моделях"
Вы точно вычитывали?
Могу сказать, что за восемь лет жизни на D я ни разу не нарушил безопасность памяти, т.к. почти всегда мы имеем дело с D-шными массивами, по которым мы проходим с foreach, а если обратиться к несуществующему элементу, будет кинуто исключение. А трогать указатели нам нужно крайне редко, использовать же их арифметику совсем не нужно в обычном коде. Для особых случаев статья рассказывает, как последние нововведения языка помогают избегать проблем. Вспомнил: безопасность памяти я нарушал разве что тогда, когда неправильно портировал Си-шные сигнатуры функций, тогда у меня происходило нарушение работы стека
Можно, например, создать указатель с помощью malloc, арифметикой указателей выйти за пределы выделенной области и передать это чудо в
@safe
-функцию. Или прямо можно написать любую ерунду вродеvoid* ptr = cast(void*)0x77
и передать в@safe
-функцию, потому что@safe
-функция не будет отслеживать всё, что происходит снаружи. Так что программист по-прежнему должен быть адекватен и знать, что он делает, особенно, если это происходит за пределами@safe
Нет,
@safe
,@trusted
,@system
друг с другом не компонуются. По умолчанию используется@system
, и большую часть своего кода я, например, писал в этом режиме. Основная опасность — это всё-таки работа с указателями, но они редко нужны (в основном для взаимодействия с кодом на Си). Если специально не заморачиваться, ситуации выхода за пределы допустимой памяти невероятны. Ссылки на память из освобождённого стека более вероятны, и как раз написанное в статье помогает избежать проблем, но это тоже специфические случаиВ крапинку
По поводу первого: такое есть и в D (помимо Kotlin)
Редко приходится пользоваться, но когда приходится — довольно удобно (можно и
continue
так же использовать).Плюс в switch-case-конструкциях можно использовать
goto
для перехода именнок нужному case, но это совсем не пригождалось.
Авторы точно что-то знают о современных носителях данных? На российском рынке уже давно можно покупать диски по 20 ТБ, а на зарубежном и на 22 ТБ.
"...на рынке появилось множество хороших браузеров, ориентированных на конфиденциальность."
Какое такое множество?
В Debian пакет присутствует, поэтому можно просто сделать
# apt install python3-plumbum
Отбой тревоги. После :PackerSync вдруг заработало
Впечатление, что плагин nvim-tree не работает: "Это не команда редактора: NvimTreeRefresh".
Help для nvim-tree работает, но самих его команд не появилось. Во всяком случае, при neovim версии 0.6.1
Не могу согласиться с другими комментаторами: на 7,8 дюймов (у меня Kon-Tiki 2) я вполне читаю DJVU и PDF. Тем более, что при чтении можно "обрезать" лишние белые области
Красный, синий и жёлтый — это хороший выбор цветов
К слову сказать, все подобные картинки не являются правдой. Как человек с цветоаномалией я должен был бы столбец с "обычным зрением" видеть так же, как один из трех следующих. Но они все очень разные
Чем только люди не занимаются, лишь бы D не учить
Вам бы фильтр в магазине при поиске книг - "Твёрдый/мягкий переплёт". А то эти мягкие обложки на книгах ценой более 2000 ₽ задолбали