В PascalABC.NET возникают большие проблемы при использовании динамических переменных, создаваемых в традиционном стиле с помощью вызова New, в случае, когда создаются записи, содержащие поля типа string. Совершенно корректная программа, работающая в Turbo Pascal, Delphi, и даже в PascalABC (без .NET) перестает работать в ABC.NET: в какой-то момент поля string превращаются в nil. При не очень большом объеме данных может и работать, но только при очень небольшом.
Вот пример ситуации, когда возникают проблемы:
type
tPtr = ^tNode;
tNode = record
___word: string;
___left, right: tPtr;
end;
var
___tree: tPtr;
…
New(tree);
…
Это кусочек программы (подчеркивания вместо отступов) для получения словаря заданного текста с помощью построения и последующего обхода двоичного дерева. Если нужно, могу привести программу целиком, она не очень большая.
Строки string собираются сборщиком мусора. Используйте shortstring, короткие строки фиксируются в памяти и не собираются сборщиком мусора (если используются в неуправляемой памяти)
А можно неприличный вопрос? Для чего изобретать очередной велосипед, если словарь Dictionary уже есть готовый? Ну не нравится язык, где много готовых компонентов - пишите и отлаживайте на FPC сутками то, что тут можно за полчаса сделать… Зачем в среду .NET лезть со всеми этими пещерными ссылками и указателями?
Согласен, вопрос неприличный.
Видите ли, готовые словари, кто-то когда-то написал. И этот кто-то изучал когда-то, как это все устроено. Этот процесс еще называют образованием.
procedure New(var p: ^T);
Выделяет динамическую память размера sizeof(T) и возвращает в переменной p указатель на нее. Тип T должен быть размерным
и
Отметим, что динамическая память, выделяемая процедурой New, не находится под управлением сборщика мусора, поэтому нуждается в явном освобождении вызовом процедуры Dispose. Именно поэтому работа с обычными указателями считается в PascalABC.NET устаревшей и не рекомендуется к использованию.
Собственно, самое главное здесь: Тип T должен быть размерным. А у Вас в записи - ссылочный тип.
Явно не говорится, но это так: нельзя делать неуправляемые указатели на управляемую память. Потому что в один прекрасный момент управляемая память переносится сборщиком мусора в другое место.
Ну то есть, Вы должны с этим что-то сделать. Например, сказать, что PascalABC.NET вместе с его сборщиком мусора - плохая система - и не пользоваться ей. Или - принять новые правила игры. Например, заменить string на integer или использовать только ссылки:
Если изучать “как устроено”, милости просим в мир С++. Там Вы “по самое нехочу” наиграетесь в ссылки, указатели, сборку мусора, утечки памяти и т.д… Рискну предположить, что основа PascalABC.NET написана не на Паскале с последующим бутстрэппингом, а на совсем ином языке))
Как раз не путаю. Именно потому, что нет автоматической сборки, я и и пишу “наиграетесь”. О чем свидетельствует дальнейшее “утечки памяти”. Их нет при автоматической сборке.
Давайте, Вы воздержитесь от дальнейшего троллинга. Ответа на заданный вопрос Вы не знаете. А давать советы про то, зачем мне эта программа, я не просил. Пока, пока.
Ещё раз повторю по сути вопроса - надо понять, что с этим делать.
Два мира - неуправляемые указатели и управляемые ссылки - невозможно помирить между собой. Поэтому нужны какие-то компромиссы. Компромисс, который предлагает PascalABC.NET, - не использовать эти два мира совместно.
Станислав Станиславович, я, признаться, не понимаю, в чем тут технические проблемы и почему “невозможно помирить”. Но, видимо, я понимаю не все. В любом случае огорчительно, что программа. которая корректно работает во всех известных мне системах программирования на Паскале, не работает в PascalABC.NET. Разумеется, я могу это обойти. Но программа учебная, сюжет классический и хотелось бы, чтобы классические примеры на Паскале не переставали работать.
Технические проблемы вот в чём. New хранит указатель на неуправляемую динамическую память, в которой содержится ссылка на управляемую динамическую память. В некоторое время когда памяти перестаёт хватать, включается сборщик мусора, который переносит всю управляемую память, упаковывая её и исправляя ссылочные переменные, которые на неё указывают. Поиск ссылочных переменных он начинает искать с так называемых корневых ссылок, содержащихся в статической памяти.
Неуправляемая динамическая память не управляется сборщиком мусора, поэтому она продолжает хранить старые ссылки на уже несуществующую управляемую память.
В Вашем случае это несомненно плохо. Обеспечить обратную совместимость именно в этом случае не удалось.
Вообще, странно: в остальных случаях мы ссылочные поля явно запрещаем, а в случае строк они разрешены. Я возьму некоторую паузу - надо вспомнить, почему у нас так сделано.
Рискну предположить, что если позволить “вручную” создавать указатели на произвольные области в управляемой памяти, то сборщик мусора (GC), вызванный по нехватке памяти, не сможет разобраться, “жив” указатель или нет. А если не разберется - вот она, утечка управляемой памяти по ошибках в программе.
Можно было сделать всё - это несомненно. Но New и неуправляемая память реально нужны для ряда приложений. Например, в модуле Graph они активно используются для взаимодействия с неуправляемым кодом. Так что, поэтому было принято другое решение.
Ваше решение - хорошее, но оно затрагивает половину компилятора и его реализация приведет к обеднению Паскаля - в нём нельзя будет работать с неуправляемым кодом
А что такое неуправляемая память? Та, что не подчиняется сборщику мусора? Но ведь память, предоставляемая через New, тоже должна каким-то образом диспетчеризоваться. А что такое неуправляемый код?
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021