e
ну ладно, тогда вот видосик поинтереснее, поможет снизить уровень стресса и избавится тупизны
https://www.youtube.com/watch?v=nII0ralSlRo
https://www.youtube.com/watch?v=nII0ralSlRo
Size: a a a
2020 May 14
G
не смогут
сделали пару лет назад же уже
AZ
❓(возможно глупый)
Почему разработчики языка пошли по пути запинивания объектов и неперемещаемых типов, а не по следующему пути:
Если у нас есть самоссылающаяся структура, то можно после перемещения просто пройтись по всем указателям и пропатчить на новые локации.
Все указатели, которые будут инвалидированы - мы о них знаем, пройтись по ним не проблема.
Да, это медленнее, чем не перемещать такой тип, но если надо перфоманс, просто писать без лишних перемещений.
Зато было бы гибче, меньше запретов от компилятора.
В принципе это можно было бы сделать или я что-то упускаю из вида?
Почему разработчики языка пошли по пути запинивания объектов и неперемещаемых типов, а не по следующему пути:
Если у нас есть самоссылающаяся структура, то можно после перемещения просто пройтись по всем указателям и пропатчить на новые локации.
Все указатели, которые будут инвалидированы - мы о них знаем, пройтись по ним не проблема.
Да, это медленнее, чем не перемещать такой тип, но если надо перфоманс, просто писать без лишних перемещений.
Зато было бы гибче, меньше запретов от компилятора.
В принципе это можно было бы сделать или я что-то упускаю из вида?
по-моему такой вариант предлагался, и был отвергнут. Мне кажется, проблема в сырых указателях, ты про них не знаешь и проапдетить их не сможешь
p
❓(возможно глупый)
Почему разработчики языка пошли по пути запинивания объектов и неперемещаемых типов, а не по следующему пути:
Если у нас есть самоссылающаяся структура, то можно после перемещения просто пройтись по всем указателям и пропатчить на новые локации.
Все указатели, которые будут инвалидированы - мы о них знаем, пройтись по ним не проблема.
Да, это медленнее, чем не перемещать такой тип, но если надо перфоманс, просто писать без лишних перемещений.
Зато было бы гибче, меньше запретов от компилятора.
В принципе это можно было бы сделать или я что-то упускаю из вида?
Почему разработчики языка пошли по пути запинивания объектов и неперемещаемых типов, а не по следующему пути:
Если у нас есть самоссылающаяся структура, то можно после перемещения просто пройтись по всем указателям и пропатчить на новые локации.
Все указатели, которые будут инвалидированы - мы о них знаем, пройтись по ним не проблема.
Да, это медленнее, чем не перемещать такой тип, но если надо перфоманс, просто писать без лишних перемещений.
Зато было бы гибче, меньше запретов от компилятора.
В принципе это можно было бы сделать или я что-то упускаю из вида?
ну представь как это должно быть в компиляторе сделано
JC
Ну, наверное, ты таки представляешь что такое указатель, базовые вопросы работы с памятью, весёлое ручное швыряние битов и байтов, выравнивание полей в структурах, как происходит вызов функций и прочее?
Вот в питоне этого всего не познать, оно скрыто нахрен.
Да там даже можно про разную разрядность целых чисел никогда не узнать.
Вот в питоне этого всего не познать, оно скрыто нахрен.
Да там даже можно про разную разрядность целых чисел никогда не узнать.
Ну это называется абстракции
NL
по-моему такой вариант предлагался, и был отвергнут. Мне кажется, проблема в сырых указателях, ты про них не знаешь и проапдетить их не сможешь
Ну тут с помощью @MikailBag получается такой вывод, что компилятор не может в общем случае определить, является что-то указателем или нет.
Но он ещё добавил:
> Это первая.
Вторая в том, что указатель может быть храниться не напрямую, а в хипе .
Третья в том, что компилятор не знает о всех move-ах.
Но он ещё добавил:
> Это первая.
Вторая в том, что указатель может быть храниться не напрямую, а в хипе .
Третья в том, что компилятор не знает о всех move-ах.
MB
Разверну про вторую:
Допустим мы храним &&str.
Тогда гипотетический фиксер ссылок должен посмотреть, куда указывает &str. Для этого он должен разыменовать внешний &.
А теперь - пусть мы положили этот бокс в MaybeUninit. Тогда этот фиксер ссылок не имеет никакого права взять внутренности MaybeUninit и проинтерпретировать их как корректный указатель. А значит такую вот хитровложенную ссылку MaybeUninit<&&str> пофиксить в рантайме невозможно.
Допустим мы храним &&str.
Тогда гипотетический фиксер ссылок должен посмотреть, куда указывает &str. Для этого он должен разыменовать внешний &.
А теперь - пусть мы положили этот бокс в MaybeUninit. Тогда этот фиксер ссылок не имеет никакого права взять внутренности MaybeUninit и проинтерпретировать их как корректный указатель. А значит такую вот хитровложенную ссылку MaybeUninit<&&str> пофиксить в рантайме невозможно.
NL
Но кстати, в системах со сборщиком мусора многие указатели тоже содержатся в хипе, и по ним тоже можно пройтись и таким образом собрать всех подозреваемых.
MB
Но кстати, в системах со сборщиком мусора многие указатели тоже содержатся в хипе, и по ним тоже можно пройтись и таким образом собрать всех подозреваемых.
Но в них, думаю, нельзя производить копирование указателей посредством memcpy
NL
Разверну про вторую:
Допустим мы храним &&str.
Тогда гипотетический фиксер ссылок должен посмотреть, куда указывает &str. Для этого он должен разыменовать внешний &.
А теперь - пусть мы положили этот бокс в MaybeUninit. Тогда этот фиксер ссылок не имеет никакого права взять внутренности MaybeUninit и проинтерпретировать их как корректный указатель. А значит такую вот хитровложенную ссылку MaybeUninit<&&str> пофиксить в рантайме невозможно.
Допустим мы храним &&str.
Тогда гипотетический фиксер ссылок должен посмотреть, куда указывает &str. Для этого он должен разыменовать внешний &.
А теперь - пусть мы положили этот бокс в MaybeUninit. Тогда этот фиксер ссылок не имеет никакого права взять внутренности MaybeUninit и проинтерпретировать их как корректный указатель. А значит такую вот хитровложенную ссылку MaybeUninit<&&str> пофиксить в рантайме невозможно.
Да, убедил. Спасибо 👍
JC
Ну, наверное, ты таки представляешь что такое указатель, базовые вопросы работы с памятью, весёлое ручное швыряние битов и байтов, выравнивание полей в структурах, как происходит вызов функций и прочее?
Вот в питоне этого всего не познать, оно скрыто нахрен.
Да там даже можно про разную разрядность целых чисел никогда не узнать.
Вот в питоне этого всего не познать, оно скрыто нахрен.
Да там даже можно про разную разрядность целых чисел никогда не узнать.
Не уверен, что все это нужно в первых языках
SP
да это рантайм мусор который не чекает вхождения в сумтип
SP
видя такие штуки думаешь боже как прекрасен раст
JC
Еще б GC в Раст...
JC
p
Еще б GC в Раст...
сделай
JC
да я так
JC
Мне и питон хорош
VS
@hirrolot ну шо таки ты спрашивал про книги про архитектуру и ФП - я таки тут наткнулся на : https://www.amazon.com/Domain-Modeling-Made-Functional-Domain-Driven/dp/1680502549