На скриншоте показано всё взаимодействие с консолью. Никаких посторонних команд, как можно заметить, нету
В 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 себя изжил что ли?
И что под этим подразумевается? UTF-16 наверное? В любом случае, не рекомендую использовать блокнот. Поставьте любой заменитель (Notepad++, AkelPad, тысячи их) и забудьте про него.
В паскале такого нет, только в .NET, насколько я понял. Так что, или file of char или text.
Там можно импортировать разные штуки из .NET, как и например в Free Pascal можно импортировать функции из библиотек написанных на C, но вы же не будете для таких базовых вещей брать библиотеки, написанные на других языках, если аналог есть в самом языке (тип Text и File of … в паскале)?
Вы видимо не понимаете, как построен PABC.NET. Это платформа .NET, к которой прилеплен синтаксис паскаля. Крайне дилетантское объяснение, но этого должно быть достаточно, да и углубляться не хочу
Так что всё, что есть в .NET, также работает и в паскале
Не в паскале, а в PascalABC .NET. Но при этом в других имплементациях паскаля не работает, а значит использовать это можно только в крайнем случае, если нет альтернатив.
А в данном случае — альтернативы есть, следовательно про существование FileInfo лучше забыть.
Именно
Не вижу ни одной причины
type
t0 = class
i := 3;
end;
t1 = record
i := 5;
o := new t0;
end;
begin
var a := new t1;
var p := @a; // потому что ^t1 это глупость - без присвоения и объявить не даст
New(p); // А теперь собственно выделяем память
System.GC.Collect;
var o2 := new t0; // У меня без этого выводит 3 а не 0. У вас может и упасть с ошибкой прав доступа
p^.o.i.Println;
//System.GC.KeepAlive(o2); // На всяк, если у вас оптимизатор JIT-а прешит удалить o2
end.
Потому что контролировать управляемые ссылки, которые оказались в неуправляемой (средой выполнения, включая сборщик мусора) области памяти - занятие в целом бесполезное.
Их типизация ничего не значит после этапа компиляции. В отличии от ссылок, имеющих строгую типизацию и во время выполнения (что позволяет эффективно использовать is и as), для слежения за ссылками, оказавшимися под другими ссылками.
В .Net есть средства для борьбы с такими проблемами.
GC.KeepAlive это одно из них, но полезное только для локальных переменных. По сути это вызов процедуры, которая ничего не делает и удаляется при оптимизации, но переданная в неё переменная не может быть так же удалена.
Есть ещё System.Runtime.InteropServices.GCHandle, но оно связывает руки сборщику мусора. И добавляет ещё больше бойлерплейта, поверх явных Dispose-ов, необходимых с указателями.
Где GCHandle должно использоваться - так это как тут, где ресурс передаётся в вызов неупрвляемого кода, и надо чтоб пока неуправляемый код работает - этот ресурс нельзя было удалить.
То есть, как я уже сказал раньше, всё с указателями должно использоваться только для связи с неуправляемым кодом.
Нет, достаточно просто посмотреть на все перегрузки функций типа Reset, Rewrite и т.п.
Вы как то странно на это смотрите. Системные библиотеки .Net-а подключаются и загружаются всегда. И большая часть их информации хранится единожды для всех запущенных программ. Так что никакого урона ни производительности, ни тем более размеру .exe от них нет.
Другое дело, PABCSystem, да и сахар языка, дают более сладкий доступ к тому что есть в .Net . Но это не всегда правда. К примеру вы не сможете использовать тип text чтоб прочитать файл, зашитый внутрь .exe-шника. Если нужен общий метод, работающий на все ситуации - надо брать стандартные типы и методы .Net-а.
Потому что их так и задумывали - чтоб во всех .Net языках был, к примеру, один тип string, не требующий дополнительного перевода при пересылке между программами и .dll-ками. И типов вроде System.IO.Stream и FileInfo это так же касается.
Кроме того, у этих типов значительно проработаны детали. К примеру метод вроде FileInfo.Refresh нужен очень редко, так что даже если бы в PABCSystem была обёртка FileInfo (отдельно от типов вроде text и file, не дающих прямого доступа к его возможностям) - его небыло бы смысла добавлять. Но когда он нужен - единственной альтернативой будут external подпрограммы.
Такой вопрос. А можно ли как то сделать для своих функций такие же подсказки по параметрам, как, например, тут?
Или это всё где то в недрах IDE прописано?
/// <summary>
/// Просто описание
/// </summary>
/// <param name="параметр">Описание параметра</param>
procedure p1(параметр: byte) := exit;
begin
end.
Тут можно использовать документацию по C# - там всё так же:
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021