Возможно банку предоставляется правильное время, но на самой карточке печатается фейковое.
Таким образом отчетность правильная, а всякие интернет-магазины видят John Smith.
Если что-то где-то «прибыло», то совершенно однозначно где-то что-то «убыло».
Прибыла необходимость (иногда) прописывать лайфтаймы, но в основном и без них всеп росто работает.
Ручное управление памятью сложнее
циклической конструкции
Опять же, по моему опыту (который, естественно, очень специфичный), подсчет ссылок нужен довольно редко (я использую его на пару с мьютексами), а ручное управление памятью — еще реже. В основном, мой код прекрасно ложится на деструкторы. И я не думаю, что добавление 100500 правил бизнес-логики приведет к циклическим ссылкак. Даже если приведет — можно конкретно для этих высокоуровненых объектов бизнес-логики включить GC (например, в Linux Kernel есть сборщик файловых дескрипторов). При этом большая часть проекта продолжит работать без него и не получит его минусов.
А по поводу его минусов — достаточно запустить CodeBlocks и CLion (TL;DR — на слабых компах, пока запустится clion или visual studio можно успеть установить CodeBlocks).
Естественно. Большая часть фич раста, и RAII в том числе, — баян. Даже довольно новаторские (например лайфтаймы) уже были в других языках. Но я и не говорил другого. Вы же сами предлагали сравнивать два конкретных языка, а не язык Х с объединением фич всех остальных язык.
Действительно, деструкторы не относятся к система типов, они реализованы "сбоку" (по крайней мере в расте). Но лайфтаймы к системе типов относятся.
А то, что деструкторы не работают на языках с GC — это имхо топ-2 причина не использовать GC (первая — это производительность).
Да-да, охотно верю…
Когда все инварианты выражены на уровне системы типов, паники уже не нужны.
Сложная система типов никак не защищает от выстрелов в ногу. Честно-честно.
Пример 1, реальный. https://doc.rust-lang.org/nightly/std/fs/struct.File.html
(этот тип позволяет работать с файлами)
Сложная система типов в расте (а именно, деструкторы и правила владения) гарантирует, что файл обязательно будет закрыт. Мне вообще не нужно думать про какие-то там defer f.Close() — оно просто работает.
(Формально, конечно, можно добиться утечки, но это надо сделать явно.)
Пример 2 — зависимая типизация (Тут где-то в комментах deadf00d ходит, он хорошо умеет ее впаривать)). Она позволяет выразить на уровне типов сколь угодно сложные инварианты, в том числе:
Сокет, в который записали нечетное количество байт.
Тройка из векторов, где у первого и третьего одинаковый размер, а второй длиннее.
Она позволяет вообще гарантировать отсутствие паник в рантайме и доказать корректность программы.
Таким образом, сложные системы мешают выстреливать себе в ногу — в общем-то, это и есть их главное предназначение.
Пусть есть пустой стол на 4 места и частично занятый на 3, и пришла группа из 3 людей.
Поэтому просто искать первый стол с достаточным количеством мест нельзя.
Ну я не уверен, насколько мой вариант хорош, но суть ваших претензий не совсем понимаю. В linux потоки — нечто, не слишком отличное от процесса, и запуск потока это вроде как clone(CLONE_VM|CLONE_THREAD).
Из того, что я лично натыкался: (это из clone)
CLONE_STOPPED (since Linux 2.6.0-test2)
If CLONE_STOPPED is set, then the child is initially stopped (as though it was sent a SIGSTOP signal), and must be resumed by sending it a SIGCONT signal.
This flag was deprecated from Linux 2.6.25 onward, and was removed altogether in Linux 2.6.38.
Сейчас это значение переиспользовано для вроде CLONE_NEWCGROUP.
Т.о. старый код будет работать на новых ядрах совсем некорректно.
Тогда в чем проблема, когда программа на каком-то объекте вызывает rem(), сразу вычистить все? Это позволит выпилить из ВМ целую подсистему.
Не каждый, а когда он заполнен до отказа.
Оверхед по памяти от 0 до 3 раз. Но вообще, меняя границы реаллока, можно добиваться разных компромиссов между оверхедем по памяти и производительностью, но в любом случае O(N) памяти и времени.
В принципе, вы можете организовать стек как односвязный список блоков, т.е. каждый блок имеет указатель на предыдущий, и буфер на, скажем, 256 элементов. Тогда оверхед по памяти вообще крошечный, время работы — О(1) на любой запрос. Единственная потеря — сложная и медленная индексация, но вам это вроде как не нужно.
But repository doesn't show any activity since July 2018(
Возможно банку предоставляется правильное время, но на самой карточке печатается фейковое.
Таким образом отчетность правильная, а всякие интернет-магазины видят John Smith.
Я школьник)
Прибыла необходимость (иногда) прописывать лайфтаймы, но в основном и без них всеп росто работает.
Опять же, по моему опыту (который, естественно, очень специфичный), подсчет ссылок нужен довольно редко (я использую его на пару с мьютексами), а ручное управление памятью — еще реже. В основном, мой код прекрасно ложится на деструкторы. И я не думаю, что добавление 100500 правил бизнес-логики приведет к циклическим ссылкак. Даже если приведет — можно конкретно для этих высокоуровненых объектов бизнес-логики включить GC (например, в Linux Kernel есть сборщик файловых дескрипторов). При этом большая часть проекта продолжит работать без него и не получит его минусов.
А по поводу его минусов — достаточно запустить CodeBlocks и CLion (TL;DR — на слабых компах, пока запустится clion или visual studio можно успеть установить CodeBlocks).
Один байт — один репозиторий.
Кстати, так можно радикалько снизить их количество благодаря переиспользованию.
А вообще, так выглядит 90% JS-библиотек
Если в тексте нет ни \n, ни \r, то будет выполнен третий поиск, который гарантированно ничего не найдет.
Естественно. Большая часть фич раста, и RAII в том числе, — баян. Даже довольно новаторские (например лайфтаймы) уже были в других языках. Но я и не говорил другого. Вы же сами предлагали сравнивать два конкретных языка, а не язык Х с объединением фич всех остальных язык.
А то, что деструкторы не работают на языках с GC — это имхо топ-2 причина не использовать GC (первая — это производительность).
Когда все инварианты выражены на уровне системы типов, паники уже не нужны.
Пример 1, реальный.
https://doc.rust-lang.org/nightly/std/fs/struct.File.html
(этот тип позволяет работать с файлами)
Сложная система типов в расте (а именно, деструкторы и правила владения) гарантирует, что файл обязательно будет закрыт. Мне вообще не нужно думать про какие-то там defer f.Close() — оно просто работает.
(Формально, конечно, можно добиться утечки, но это надо сделать явно.)
Пример 2 — зависимая типизация (Тут где-то в комментах deadf00d ходит, он хорошо умеет ее впаривать)). Она позволяет выразить на уровне типов сколь угодно сложные инварианты, в том числе:
Она позволяет вообще гарантировать отсутствие паник в рантайме и доказать корректность программы.
Таким образом, сложные системы мешают выстреливать себе в ногу — в общем-то, это и есть их главное предназначение.
Пусть есть пустой стол на 4 места и частично занятый на 3, и пришла группа из 3 людей.
Поэтому просто искать первый стол с достаточным количеством мест нельзя.
Для широкой общественности есть однофакторная.
Или, возможно, reversed.
А, ну тогда вообще круто — один kill, и все потоки остановлены.
Ну я не уверен, насколько мой вариант хорош, но суть ваших претензий не совсем понимаю. В linux потоки — нечто, не слишком отличное от процесса, и запуск потока это вроде как clone(CLONE_VM|CLONE_THREAD).
В C/C++ есть трюк с
Ну типа
for pid in thread_list
kill(pid, SIGSTOP)
И еще завернуть это в цикл, пока что-то было остановлено
Из того, что я лично натыкался: (это из clone)
CLONE_STOPPED (since Linux 2.6.0-test2)
If CLONE_STOPPED is set, then the child is initially stopped (as though it was sent a SIGSTOP signal), and must be resumed by sending it a SIGCONT signal.
Сейчас это значение переиспользовано для вроде CLONE_NEWCGROUP.
Т.о. старый код будет работать на новых ядрах совсем некорректно.
Отправить им SIGSTOP?
СемВер — это про интерфейс. Интерфейс ядра — это системные вызова. Значит их и нужно версионировать. Вырезали флаг — +1 к мажорной версии.
Скачиваете исходник утилиты и патчите, в чём проблема?
А почему паника хуже чем непойманный эксепшн? И там и там аварийное завершение, и там и там стектрейс.
Оверхед по памяти от 0 до 3 раз. Но вообще, меняя границы реаллока, можно добиваться разных компромиссов между оверхедем по памяти и производительностью, но в любом случае O(N) памяти и времени.
В принципе, вы можете организовать стек как односвязный список блоков, т.е. каждый блок имеет указатель на предыдущий, и буфер на, скажем, 256 элементов. Тогда оверхед по памяти вообще крошечный, время работы — О(1) на любой запрос. Единственная потеря — сложная и медленная индексация, но вам это вроде как не нужно.