Следовательно, выгоднее статистически затирать страницы.

Я просто попутно проектирую mm своей микро-ОСи и задумался об эдаких механизмах

В любом случае прога покрэшится: либо ОСь откажет в выдаче памяти в куче, либо попросту обратится в вычищенный кусок. Если полагать, что прог много и все хотят памяти, лучше обеспечить работоспособность всех, ценой убийства одной. Об остальном пусть парится разраб.

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

Так ведь статистика обращений к страницам. Как узнаёт сборщик джавы? Отсутствие ссылок на объект, например.

И как это соотносится с си и плюсами? Может ты в память константную строку загнал, и что случится если её удалить?

Ты можешь сделать свое апи в твоей микрооси, которое включит этот сборщик мусора, но при разработке софта надо будет учитывать этот факт

И как это соотносится с си и плюсами? Может ты в память константную строку загнал, и что случится если её удалить?

Тогда к этой строке будут обращаться.

Кстати, почему парятся людие о засранной памяти, delete, итд, если система отлавливает эти ситуации и при завершении программы попросту помещает страницы в список свободных?

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

Тогда к этой строке будут обращаться.

раз в день, когда приходит отчёт от железки, например?

Да, есть резон

В твоих речах

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

И произойти это может только по вине ос. Сама прога (в идеальном случае) не портит свою память, другие процессы защищены (i386+).

раз в день, когда приходит отчёт от железки, например?

Вотпример. По статистике эта строчка будет вызываться редко, и ее в утиль отправит ос

https://youtu.be/JfmTagWcqoE

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

Тут Саттер рассказывает про "сборщик" на плюсах

Тут Саттер рассказывает про "сборщик" на плюсах

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

Ну да, но смысл то тот же - удаление объектов когда они уже не используются

А ты хочешь, чтобы тебе рантайм ссылки считал, а не на уровне языка?

Только сборщик возвращает память как я понимаю, а тут деструкторы вызываются

смысл любого gc тот же

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

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

это как бы не сборщик в том понимании, какое есть в яве или шарпе, это именно управление временем жизни объекта.

но не такое управление жизнью объекта, как в расте!

не знаком с растом, не могу сравнить :)

https://doc.rust-lang.org/beta/book/lifetimes.html

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

https://doc.rust-lang.org/beta/book/lifetimes.html

или я не понял синтаксиса, или там речь идёт только о статике, которая и может быть вычислена на этапе компиляции (так в плюсах можно то же самое), а не о динамике

Нет. Раст просто умеет на этапе компиляции понимать больше, чем c++. То, что в С++ упадет в рантайме (давайте передадим овнершип unique_ptr куда-нибудь и потом вызовем еще раз), в расте не скомпилируется

Нет. Раст просто умеет на этапе компиляции понимать больше, чем c++. То, что в С++ упадет в рантайме (давайте передадим овнершип unique_ptr куда-нибудь и потом вызовем еще раз), в расте не скомпилируется

auto pint1 = std::make_unique< int > (); auto pint2 = std::move( pint1 ); if ( pint1 ) *pint1 = 10; if ( pint2 ) *pint2 = 42; да, рантайм, но накладных расходов не больше чем с сырыми указателями, и да, если правильно писать не упадёт.

через лет 5 раст будет норм

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

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

в расте это невозможно в принципе?

Выстрелить в ногу? Возможно конечно

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

Раст пока что для энтузиастов

Информацию фильтровать же надо, ну. Если учить все то можно слегка поехать

Питон учить практичнее

Да и проще

Информацию фильтровать же надо, ну. Если учить все то можно слегка поехать

Все сразу не получится в любом случае. Закипит голова

Да и проще

ой ли, я прифигел от отрицатьльных индексов списков...вот кто такое выдумал, и нафига?

Очень удобно

Очень удобно

например?

Обычно это либо -1, либо слайс, описывающий суффикс

Типа, x[-3:]

питон же простой

Вот да

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

Типа, x[-3:]

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

почему вообще понадобились отрицательные индексы

Не очень простое только всякое метапрограммирование и асинхронность на корутинах, тут надо понять вначале

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

Потому что так удобнее? Меньше писать

Меньше кода - лучше читаемость

больше бекграунда для трансляции - ниже скорость, не?

Пфф

ERROR: S client not available

Скорость чего?

выполнения кода. в плюсах, в определённых ситуациях даже for( int i... может быть медленее чем for( size_t i... при прочих равных.

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

Отрицательные индексы превращаются в положительные одним преобразованием на уровне аст, это вообще ни на что не влияет

Но

В питоне не занимаются такой оптимизацией, о которой ты говоришь

Почти всегда тормоза вызываются I/O, базой, сетью

А супер оптимизированные горячие куски кода либо пишутся расширениями на си(++)

Либо если уж хочешь питон, то выполняются в PyPy

А там JIT сам тебе все оптимизирует лучше, чем ты руками

Если твой код не кривой на уровне алгоритма

у меня видимо сильная проф.деформация на фоне плюсов ))) ладно, расслаблюсь и буду читать дальше ?

Да, все именно так)

хехе, питон это не про скорость выполнения

Скорее про скорость написания )

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

>все новое >питон

>все новое >питон

для меня - новое, я ж его не знаю ?

а другой скриптовый язык знаешь?

а другой скриптовый язык знаешь?

bash, lua, vbscript для MSWin не в совершенстве, но именно как скриптописалки.

нафлудили-то )

Что делает enable_if? В документации нихуя не понятно :(

имхо, это в супапро.схх

имхо, это в супапро.схх

там уже есть. )

Что делает enable_if? В документации нихуя не понятно :(

Ломает компиляцию, если условие ложно. )

Ломает компиляцию, если условие ложно. )

В точку!

Можно использовать как аргумент по-умолчанию в шаблоне, если нужно ограничить диапазон типов, с которыми оный шаблон можно использовать. Примерно так template <typename T, typename = typename std::enable_if(std::is_assignable<T, std::string>>