А можно, кстати, пояснить, что имелось ввиду подробнее? Да, при ручном создании списка в виде последовательности структур с указателями друг на друга, после того как они станут не нужны, следует пройти по списку и освободить память с помощью dispose.
Какие конкретно проблемы с памятью могут/должны возникнуть при таком использовании? Если можно, сразу с примером кода.
Можно. А нужно?
Я вам так скажу, сейчас преподают питон 
Тогда пусть решает на бумажке\в уме\полным прописыванием логики с begin и end (нужное подчеркнуть)
Тогда пусть в уме решают
Ага. @RAlex, что было-то?
Открыт в юникоде. В ANSI вывод аналогичен консоли
Предположу, что утечка в связи с оставлением мусора, потому что
неудобно. А если ещё и вспомнить, что мы говорим о школьниках… А, и да, чуть не забыл - указатель легко может сбиться (с почти абсолютной вероятностью собьётся) в результате работы GC
Было. Серьезно вышел из строя сервер, на котором находится ПО, поддерживающее форум.
Ну вон, видишь — как раз на тех тестах, которые ты не стал проводить, ABC и фейлится.
Жесткие диски тоже накрылись? Сообщения-то некоторые пропали.
А я что и говорю. А RAlex почему-то не согласен.
Если он сбивается — значит компилятор кривой и ни для какой серьёзной работы не пригоден. Должен по идее отключать GC для структур, созданных с помощью new.
Я так и не понял, причём тут паскаль. Консоль не смогла отобразить, блокнот тоже. Ничего из этого к паскалю отношения не имеет. Скорее даже наоборот, IDE не ударила в грязь лицом - вывела на встроенную консоль всё точно так, как и должно выглядеть
Ну не согласен и ладно. Вы боитесь, что его несогласие помешает школьникам думать на экзамене?
Насколько я помню, именно так и работает ключевое слово unsafe в шарпе - запрещает перемещать объекты в памяти в некоторой области кода. Как с этим в паскале - не в курсе
Потому вам и говорят - хотите забивать гвозди - положите микроскоп на место. Не предназначены ЯП высокого уровня для работы с указателями
Вы знаете какой-то другой способ создания экземпляра типа? 
Обычное для этого господина передергивание. Он меня утомил, поэтому уже не отвечаю, считая что он элементарно троллит нас, прекрасно на самом деле понимая что и откуда. Как раз-таки я тоже считаю, что Паскаль совершенно правильно поступает с консолью.
Одна только фраза “Должен по идее отключать GC для структур, созданных с помощью new.” показывает, что человек намеренно чушь городит. Вызов конструктора должен запрещать сбор мусора для создаваемого объекта - это как и зачем? Точнее даже, а для чего тогда вообще сборщик мусора, если практически для всего вызывается конструктор, пусть даже неявно?
Дорожки у дома подметать
Странно, что вы этого не поняли. Консоль-то прекрасно отображает юникод в принципе (наберите команду dir, увидите имена файлов на любых языках), но программа, скомпилированная ABC этого не делает — значит или не выполняет chcp 65001 (кстати попробуйте выполнить эту команду, а потом из той же консоли вызвать программу на ABC, может тогда сработает) или криво компилирует как-то. Хотя консоль в виндовс действительно реализована кривовато и с ней сложно работать правильно.
А с блокнотом — ну попробуйте открыть полученный файл той же ABC IDE, тогда или нормальным редактором вроде Notepad++. Проблема в том, что файл сформирован криво, скорее всего, а это опять же, баг компилятора PascalABC. Но чтобы убедиться точно, можете приложить файл к сообщению, я скачаю и проанализирую, что с ним не так.
Что вы понимаете под ЯП высокого уровня? Насколько я знаю, общепринятое определение включает в их число всё кроме ассемблера и автокодов. И в паскале указатели есть, а значит для работы с ними он предназначен.
В общем, я имею ввиду процедуру new, вызываемую для указателя. Естественно, что созданная таким образом переменная должна быть освобождена с помощью dispose.
В смысле?
Вообще-то можно почитать справку по языку. Там написано, цитирую:
Отметим, что динамическая память, выделяемая процедурой New и контролируемая указателями, не находится под управлением сборщика мусора, поэтому нуждается в явном освобождении вызовом процедуры Dispose.
Что я и говорил. В выделенную явно процедурой New сборщик мусора лезть не должен. Если на самом деле лезет, вопреки описанному в справке — это очень серьёзный дефект.
И правда, зачем? В нормальном паскале как-то без него обходятся, да и в C тоже.
Нет
Если вы запускали собственную программу, то должны были видеть, что всё нормально выводится. Если нет - то всё нормально выводится
Да, чепуху ляпнул. Они не для языков с автоматической сборкой мусора
Можно. Тогда выяснится, почему не рекомендуется работать с указателями, что GC не трогает объекты, к которым отсылаются указатели, и многое другое
Да ладно вам, раньше и на ассемблере писали…
Странно. Это после команды chcp 65001 (выставляет кодировку UTF-8 в текущей консоли) или до? Вроде
Если вы запускали собственную программу, то должны были видеть, что всё нормально выводится.
Запускал в линуксе через Free Pascal — да, всё отлично и в консоли и в файле и в его имени. А в винде как видите — облом-с…
Если нет - то всё нормально выводится
Где именно?
Тогда выяснится, почему не рекомендуется работать с указателями, что GC не трогает объекты, к которым отсылаются указатели, и многое другое
Ну так это так и должно быть. В чём проблема?
Да ладно вам, раньше и на ассемблере писали…
Почему раньше? И сейчас пишут и новые версии ассемблеров продолжают выходить.
Они не для языков с автоматической сборкой мусора
Ну так тогда вообще не понятно зачем её прилепили к паскалю АБЦ.
На скриншоте показано всё взаимодействие с консолью. Никаких посторонних команд, как можно заметить, нету
В IDE. И в её консоли, и в пространстве для кода
Ну так это так и есть. В чём проблема?
Крупные проекты целиком на ассемблере не пишут. Думаю мне не надо объяснять, почему так
Это паскаль к ней прилепился, а если точнее - к платформе .NET
Шрифт в настойках консоли нужно поменять, может у вас там какой-то не юникодный
Блокнот в юникоде показывает то же
Вы до сих пор не поняли, что говорите о “неправильной” операционной системе, в которой запущен “неправильный фреймворк”, под которым работает “неправильный компилятор” с “неправильного” языка ? Слово “неправильный” я тут использовал из соображений этики.
Существует более одной системы представления юникода (UTF, Unicode Transformation Format), например UTF-8, USC-2, UTF-16le, UTF-16be, UTF-32le, UTF-32be и ещё несколько более редких. Если говоришь о кодировках, нужно обязательно уточнять, о каких именно, поскольку все эти UTF друг с другом не совпадают.
Шрифт в настройках консоли попробуйте поменять. Нажимаете на значок в углу слева, там менюшка, там Свойства, и там где-то шрифт меняется. Надо выбрать такой, в котором есть юникод.
И открывайте в редакторе, который позволяет поменять кодировку. Хотя блокнот тоже позволяет, но как-то криво.
У вас неправильные пчёлы и они делают неправильный мёд!
@Catcher прав (частично) в плане наличия до сих пор проблемы с корректным вводом/выводом Unicode-строк:
Имя файла в тесте создается правильное. Проблема только в том, что в консоли винды может быть настроен не-юникодный шрифт (по умолчанию?). Если поменять его, напр., на Lucida Console, то имена многоязычных файлов будут отображаться корректно (внутри NTFS, кстати, используется UTF-16LE, а не UTF-8).
Ввод/вывод в процедурах writeln/readln на внешнюю консоль, похоже, всегда сейчас перекодируется в однобайтовую кодировку win-1251 (@admin это прибито гвоздями или зависит от региональных настроек?), что неправильно, т.к. все строки внутри .NET хранятся уже в кодировке UTF-8. Это нужно исправлять.
То же самое касается и ввода/вывода в файл через эти процедуры – пора менять дефолтную кодировку на UTF-8 и/или вводить новую директиву компилятора с настройкой текущей кодировки ввода/вывода.
Почему частично?
внутри NTFS, кстати, используется UTF-16LE, а не UTF-8
Ну да. Увы, но когда эту файловую систему разрабатывали, про UTF-8 не знали. А когда узнали, менять было поздно.
Ввод/вывод в процедурах writeln/readln на внешнюю консоль , похоже, всегда сейчас перекодируется в однобайтовую кодировку win-1251
Что? Вообще-то в консоли Windows русской версии по умолчанию CP866 (DOS) кодировка, поэтому CP1251 заведомо некорректная кодировка для вывода на консоль, даже в Windows 9x и DOS. Хотя с помощью chcp 1251 можно сделать, чтобы оно отображалось правильно, но это сломает отображение в большей части других программ.
То же самое касается и ввода/вывода в файл через эти процедуры – пора менять дефолтную кодировку на UTF-8
Видимо, так. Вряд ли кому-то нужна кодировка кроме этой в текстовых файлах. Ещё с концами строк нужно что-то сделать, так как файлы с CR LF в UNIX-подобных ОС некорректны, а вот файлы с LF в конце строки работают везде кроме парочки устаревших программ (вроде Notepad из Windows).
Если нужны другие кодировки, то можно просто брать file of char вместо text и использовать процедуры конвертации кодировки, там уже явно можно будет произвольные бинарники выводить, включая файлы в устаревших кодировках.
Скорее винда уже сама перекодирует в CP866, если chcp явно в юникод не выставлен, а промежуточный вывод идет в win-1251, как и в случае дисковых файлов. Но я не углублялся, это чисто предположение. Главное, что в однобайтовой всегда выводит, хотя должно быть UTF-8 по уму.
Частично правы – потому что имя файла в юникоде создает нормально, а вот сам ввод/вывод текста недоработан. Кроме того, в PascalABC.NET есть масса других методов ввода/вывода в файл с явным указанием кодировки или предварительным перекодированием. Проблема у нас только со стандартными процедурами writeln/readln/println и устаревшей дефолтной кодировкой.
И насколько я помню, во FP и Delphi с кодировками и строками тоже не все так просто – там исторически кучу разных типов понаделали несовместимых между собой (но нужных в разных случаях на низком уровне), а реализация UTF-8 урезанная (BMP – только 65K кодпойнтов) и неполная (не все стандартные компоненты ее пока поддерживают, вроде). Обычные строки используют UTF-16/UCS-2 и требуют медленного перекодирования в/из UTF-8, если не использовать везде явно UTF8String. В .NET изначально приняли UTF-8 как стандарт для строк. При этом UTF-16/BMP всегда двухбайтовый и легко индексируется. В каждом подходе есть свои плюсы и минусы.
Насчет принудительного использования везде LF окончаний строк – очень спорно. У каждой платформы свой стандарт, UNIX тут не эталон, а их поддержка в продвинутых или специализированных редакторах в винде – еще не аргумент для отказа от нативного стандарта. Конечно, вся эта легаси-борода и нестыковки мешают и доставляют иногда на практике, но вот так слепо бросаться и ломать совместимость на родной платформе никто не рискнет. Слишком радикально.
Вообще-то обычные строки (ShortString) по умолчанию в CP_ACP, которая на большинстве платформ UTF-8. См. wiki. То же самое касается и AnsiString (рекомендуемый тип для строк).
То есть wordpad продвинуты или специализированный? Или pABCide? Последняя файлы паскаля с LF нормально открывает, правда при сохранении пишет в прибитый гвоздями формат. CRLF — это нативный стандарт для DOS и древних телетайпов. Сейчас он устарел даже на винде.
Ну, раз компилятор pabc есть для линукса, значит он должен учитывать разные концы строк и при выводе строк в файлы и в терминал и не должен добавлять CR. Не знаю как на практике.
Не знаю, как виндовая консоль отнесётся к выводу файла с концами строк LF, нормально или нет? Если нормально — то можно и на винде отказаться от CR LF
Юникод
Там два дополнительных шрифта, некоторые символы представлены квадратами в обоих
Ага, есть такое ощущение
Что-то я сомневаюсь… Хотя кто знает? В любом случае, все желающие могут полазить по исходникам
Полезная информация
Зачем? Такой класс, как FileInfo себя изжил что ли?
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021