Тут все очень специфично, зависит от менеджера памяти. Свободной может быть предостаточно, но если она сильно фрагментирована, может не влезть даже небольшой блок.
Тут не про Java, разумеется про языки с ручным управлением памятью. Там где сборка мусора, или совсем динамика, или VM конечно другие механизмы. С другой стороны, раз в Java есть OutOfMemoryError, тоже может сработать. Мне понравилась простота решения, иногда хотя бы сохранить протокол ошибки, со Stack Trace и прочим - крайне важно. Потом пусть падает.
Неплохо, но мне кажется это только часть причин, есть еще мода, бездумное желание все автоматизировать (оркестраторы оркестраторов систем деплоя систем сборок), т.ч. винить во всем страшные корпорации - перебор, на мой взгяд. Общество изменилось: в левой руке сникерс, в правой руке марс.
Я с вами согласен, просто уточнил, что для записей constructor, это не тот конструктор, как обычно он понимается. А философские рассуждения является Initialize конструктором или нет - оставим философам, на мой взгляд смысл одинаков, ну может почти одинаков.
Полностью поддерживаю, видел комментарий выше, но только добрался до хабра. Я бы with уничтожил. Конечно поздно уже, но можно через директивы их угнать в obsolete.
Правда погорячились, и про конструкторы тоже. Они хоть и есть, но по факту это не конструкторы, т.к. записи в принципе не динамические объекты (не в куче они лежат).
Про SP на records, их у меня тоже есть, но как вы верно заметили, это только с версии 10.4.2 (по моему) есть Initialize, Finalize и Assign. Кроме того, по факту, там надо делать тот-же ARC, только руками.
Вот только сегодня столкнулся с интереснейшей ситуацией с дочерними процессами созданными через CreateProcess. Ситуация следующая, есть Win32 приложение, которое регулярно порождает дочерние, коротко живущие, процессы, все это дело завернуто в Job. И все это генерирует вполне заметную утечку памяти. Исследование показало, что при создании первого дочернего процесса создается еще и print driver host, в принципе это нормально, но оно начинает жрать память, которая не освобождается при завершение дочерних процессов. Т.е. каждый запуск дочернего процесса вызывает отжор памяти всего джоба, которая не возвращается. Краткое исследованные показало, что такое поведение проявляется только при обращении к функциям модуля Vcl.Printers. Я пока не разобрался, почему это вызывает утечку, баг это в нашей системе, или в системном модуле (он какой-то слегка странный), это еще предстоит выяснить, что не так с Printers и почему, даже при завершении процесса, spooler продолжает жрать память. Но, в реальной жизни, эти дочерние процессы, функции печати используют крайне редко. Завернув получение текущего принтера в Deferred я практически избавился от проблемы, конечно, в данной ситуации, это не 100% процентов корректное решение (с этим еще предстоит разбираться), но тем не менее...
Мне интересно было посмотреть изменения именно в базовом API, что нового. А в остальном там конечно есть изменения, и уверен, будут еще. Вот ссылка на https://docs.microsoft.com/en-us/windows/apps/get-started/make-apps-great-for-windows. По большей части это относится к WinUI, а он не привязан к непосредственно к версии Windows, т.ч. является ли это функциональностью именно Windows 11? Тем более WinUI 3 на подходе.
Про новые возможности Windows 11. Решил проверить а что нового в API, может есть что-то новое и интересное в WinAPI? Если коротко - ничего нет.
Снял Dll дампы системных библиотек для Windows 10 и 11 (kernel32, user32, advapi32, wsock32). Разница абсолютно минимальная. Единственное, что меня удивило, так это удаление некоторых функций, но их не много, хотя, как по мне, нарушение обратной совместимости.
Вот за что тут минус? Фанат FoxPro?
Тут все очень специфично, зависит от менеджера памяти. Свободной может быть предостаточно, но если она сильно фрагментирована, может не влезть даже небольшой блок.
Turbo Vision кстати клевая вещь была, но толком заюзать не успел. Перескачил уже на другое.
Я так и знал, что кто-то это уже придумал )
Ответил выше, да, хотя бы сохранить лог.
Маловато... - даже не знаю, я же не обзор нового айфона пишу.
Реализация тривиальна на любом ЯП. Что тут тестировать?
Где тут вопрос? Просто поделился идеей, простой и полезной, как мне кажется.
Тут не про Java, разумеется про языки с ручным управлением памятью. Там где сборка мусора, или совсем динамика, или VM конечно другие механизмы. С другой стороны, раз в Java есть OutOfMemoryError, тоже может сработать. Мне понравилась простота решения, иногда хотя бы сохранить протокол ошибки, со Stack Trace и прочим - крайне важно. Потом пусть падает.
Неплохо, но мне кажется это только часть причин, есть еще мода, бездумное желание все автоматизировать (оркестраторы оркестраторов систем деплоя систем сборок), т.ч. винить во всем страшные корпорации - перебор, на мой взгяд. Общество изменилось: в левой руке сникерс, в правой руке марс.
Парсер сожрал угловые скобки, но думаю смысл понятен. Буду учиться пользоваться местным редактором.
Я с вами согласен, просто уточнил, что для записей constructor, это не тот конструктор, как обычно он понимается. А философские рассуждения является Initialize конструктором или нет - оставим философам, на мой взгляд смысл одинаков, ну может почти одинаков.
var Printer := DeferredRef(function: TPrinter begin Result := Vcl.Printers.Printer; end);
Полностью поддерживаю, видел комментарий выше, но только добрался до хабра. Я бы with уничтожил. Конечно поздно уже, но можно через директивы их угнать в obsolete.
Правда погорячились, и про конструкторы тоже. Они хоть и есть, но по факту это не конструкторы, т.к. записи в принципе не динамические объекты (не в куче они лежат).
Про SP на records, их у меня тоже есть, но как вы верно заметили, это только с версии 10.4.2 (по моему) есть Initialize, Finalize и Assign. Кроме того, по факту, там надо делать тот-же ARC, только руками.
Вот только сегодня столкнулся с интереснейшей ситуацией с дочерними процессами созданными через CreateProcess. Ситуация следующая, есть Win32 приложение, которое регулярно порождает дочерние, коротко живущие, процессы, все это дело завернуто в Job. И все это генерирует вполне заметную утечку памяти. Исследование показало, что при создании первого дочернего процесса создается еще и print driver host, в принципе это нормально, но оно начинает жрать память, которая не освобождается при завершение дочерних процессов. Т.е. каждый запуск дочернего процесса вызывает отжор памяти всего джоба, которая не возвращается. Краткое исследованные показало, что такое поведение проявляется только при обращении к функциям модуля Vcl.Printers. Я пока не разобрался, почему это вызывает утечку, баг это в нашей системе, или в системном модуле (он какой-то слегка странный), это еще предстоит выяснить, что не так с Printers и почему, даже при завершении процесса, spooler продолжает жрать память. Но, в реальной жизни, эти дочерние процессы, функции печати используют крайне редко. Завернув получение текущего принтера в Deferred я практически избавился от проблемы, конечно, в данной ситуации, это не 100% процентов корректное решение (с этим еще предстоит разбираться), но тем не менее...
Можно расшифровать, в чем усложнение?
Можно тут продублировать? Что-то меня в QC не пускает (давно не заходил).
Это из мира C#. Удобно конечно, но синтаксис сомнительный, на мой взгляд.
Согласен, проверка лишняя
Мне интересно было посмотреть изменения именно в базовом API, что нового. А в остальном там конечно есть изменения, и уверен, будут еще. Вот ссылка на https://docs.microsoft.com/en-us/windows/apps/get-started/make-apps-great-for-windows. По большей части это относится к WinUI, а он не привязан к непосредственно к версии Windows, т.ч. является ли это функциональностью именно Windows 11? Тем более WinUI 3 на подходе.
Про новые возможности Windows 11. Решил проверить а что нового в API, может есть что-то новое и интересное в WinAPI? Если коротко - ничего нет.
Снял Dll дампы системных библиотек для Windows 10 и 11 (kernel32, user32, advapi32, wsock32). Разница абсолютно минимальная. Единственное, что меня удивило, так это удаление некоторых функций, но их не много, хотя, как по мне, нарушение обратной совместимости.
На всякий случай, список экспортированных функций: https://disk.yandex.ru/d/aaF-qgXB1GZqfA
Получается, что кроме интерфейсных изменений, ничего больше и нет.