Насколько я понимаю, weak_ptr разделяет управляющую структуру с shared_ptr и пока существует хотя бы одна ссылка (weak_ptr или shared_ptr), то управляющая структура не будет освобождена и соответственно ее память не может быть повторно использована, а в этой структуре указано был ли освобожден shared_ptr, что будет влиять на результат expired и lock.
Тут некоторые хакеры пошли дальше и реализовали возможность запускать единожды собранный бинарник (исходный код, которого написан на С) под распространенные платформы типа Windows, Linux, MacOS - Actually Portable Executable (justine.lol)
Как уже написали выше это может быть полезно при низкоуровневой реализации различных протоколов или форматов хранения данных. FAM позволяет компактнее разместить данные и повысить их локальность в памяти, уменьшить фрагментацию памяти.
Ваш текст "я взял за основу 16 Мб и всё что меньше идёт через CalcMapFast" - так что вы маленькие файлы читаете полностью в ОЗУ и они полностью влезают в ваши 16Мб, если читать их через CalcMapFast, так что ограничение на Int.MaxValue оно не про ваш случай. И в вашем цикле в CalcMap чуть меньше телодвижений (как раз про сдвиги смещений). И вы таже будете вычитывать данные в массив пока не прочтете весь файл (даже если он маленький и ОС будет вам отдавать его частями).
Эквивалентность кода довольно очевидна, но убеждать вас я не хочу.
Не "call stack ошибка", а call stack или stack trace ошибки. Т.е. список вызовов до вызова, который выбросит исключение. В данном случае вызов любой системной функции внутри блока try/catch может выбросить исключение, которое будет отловлено в блоке catch и выброшено снова, но без информации об оригинальном списке вызовов.
Несмотря на то, что я разделяю, в определенной степени, ваши восторги относительно наличия MDBX и ее реализации (@yleo проделал колоссальную работу, за что ему огромное спасибо) - но:
появляется понятие версионности данных не доступно на пользовательском уровне.
захват блокировки пишущими транзакциями не самая быстрая операция (т.к. используются файловые блокировки, что несколько дороже даже мютексов)
Snapshot Isolation и Copy-on-Writer приводят к необходимости сборки мусора - что тоже не самая быстрая операция, а долгие читающие транзакции не рекомендуется делать
Нужно просто доделать враппер над этой MDBX, чтоб он пользовательские объекты представлял с автоматическим маппингом в этои самые key-value - это не просто, в том смысле что вам надо будет принять некоторые решения с точки зрения вашего API
Книжек про то как реализовать MDBX или аналог действительно не очень много, но его API не требует каких-то больших усилий для использования. Концепция Snapshot Isolation очень сильно упрощает пользовательский код, до той степени, что есть ощущение, что пишешь однопоточный код. Но вопрос согласованности пользовательских данных лежит полностью на ваших плечах, а не MDBX.
mutex в кодовой базе libmdbx встречается более 200 раз, наверное иначе не умеют даже там.
Подтверждаю, в нашем опыте тоже было проще писать XAML, а если уж использовался PRISM - то тем более.
Но даже если XAML писался "вручную" - всегда можно было открыть параллельно WYSIWYG редактор в студии и убедиться, что View компонуется так как и ожидается.
я лидер Python-компетенций трайба ИСУ в Сбере
Какой кринж /s
Насколько я понимаю, weak_ptr разделяет управляющую структуру с shared_ptr и пока существует хотя бы одна ссылка (weak_ptr или shared_ptr), то управляющая структура не будет освобождена и соответственно ее память не может быть повторно использована, а в этой структуре указано был ли освобожден shared_ptr, что будет влиять на результат expired и lock.
weak_ptr
Тут некоторые хакеры пошли дальше и реализовали возможность запускать единожды собранный бинарник (исходный код, которого написан на С) под распространенные платформы типа Windows, Linux, MacOS - Actually Portable Executable (justine.lol)
Есть неплохой визуализатор различных аттракторов и фракталов - BrutPitt/glChAoS.P: 3D GPUs Strange Attractors and Hypercomplex Fractals explorer - up to 256 Million particles in RealTime (github.com)
Простите, но первое предложение это здравый смысл, а второе демагогия.
Наверное вот тут довольно не плохо описано - The benefits and limitations of flexible array members | Red Hat Developer.
Как уже написали выше это может быть полезно при низкоуровневой реализации различных протоколов или форматов хранения данных. FAM позволяет компактнее разместить данные и повысить их локальность в памяти, уменьшить фрагментацию памяти.
Ваш текст "я взял за основу 16 Мб и всё что меньше идёт через CalcMapFast" - так что вы маленькие файлы читаете полностью в ОЗУ и они полностью влезают в ваши 16Мб, если читать их через CalcMapFast, так что ограничение на Int.MaxValue оно не про ваш случай. И в вашем цикле в CalcMap чуть меньше телодвижений (как раз про сдвиги смещений). И вы таже будете вычитывать данные в массив пока не прочтете весь файл (даже если он маленький и ОС будет вам отдавать его частями).
Эквивалентность кода довольно очевидна, но убеждать вас я не хочу.
В ReadAllBytes практически такой же цикл как у вас.
Не "call stack ошибка", а call stack или stack trace ошибки. Т.е. список вызовов до вызова, который выбросит исключение. В данном случае вызов любой системной функции внутри блока try/catch может выбросить исключение, которое будет отловлено в блоке catch и выброшено снова, но без информации об оригинальном списке вызовов.
Хм, если это вопрос ко мне - то тут нет языка Ассемблера и нет рекурсии. Поэтому не понимаю, о чем вы спрашиваете.
Вы же в курсе что вы таким образом теряете оригинальный callstack ошибки?
Ваш вариант CalcMapFast принципиально ничем не отличается от CalcMap, можете посмотреть на реализацию ReadAllBytes
Ну вот и началось в деревне лето. Оказывается у циклов не достаточно семантики, чтобы без комментариев обойтись.
Если уж SICP начали преподавать на Python, то нет ничего странного, в том чтобы писать книгу про алгоритмы для новичков на Python.
Например, WhyRE2 · google/re2 Wiki (github.com) или Иголка в стоге сессий, или Байт-код регулярных выражений / Хабр (habr.com)
Если кому-то интересно, то смотреть сюда - P0593R6: Implicit creation of objects for low-level object manipulation (open-std.org)
Несмотря на то, что я разделяю, в определенной степени, ваши восторги относительно наличия MDBX и ее реализации (@yleo проделал колоссальную работу, за что ему огромное спасибо) - но:
появляется понятие версионности данных не доступно на пользовательском уровне.
захват блокировки пишущими транзакциями не самая быстрая операция (т.к. используются файловые блокировки, что несколько дороже даже мютексов)
Snapshot Isolation и Copy-on-Writer приводят к необходимости сборки мусора - что тоже не самая быстрая операция, а долгие читающие транзакции не рекомендуется делать
Нужно просто доделать враппер над этой MDBX, чтоб он пользовательские объекты представлял с автоматическим маппингом в этои самые key-value - это не просто, в том смысле что вам надо будет принять некоторые решения с точки зрения вашего API
Книжек про то как реализовать MDBX или аналог действительно не очень много, но его API не требует каких-то больших усилий для использования. Концепция Snapshot Isolation очень сильно упрощает пользовательский код, до той степени, что есть ощущение, что пишешь однопоточный код. Но вопрос согласованности пользовательских данных лежит полностью на ваших плечах, а не MDBX.
mutex в кодовой базе libmdbx встречается более 200 раз, наверное иначе не умеют даже там.
Подтверждаю, в нашем опыте тоже было проще писать XAML, а если уж использовался PRISM - то тем более.
Но даже если XAML писался "вручную" - всегда можно было открыть параллельно WYSIWYG редактор в студии и убедиться, что View компонуется так как и ожидается.
Думаю этот вопрос стоит задать юристам.
Ну поддержка покупается отдельно - нужна ли там лицензия - я так глубоко не смотрел.