В смысле, верится с трудом. А если это действительно так… То все гораздо хуже, чем я предполагал. Получается, имеем великовозрастного несостоявшегося недопрограммиста, который не имеет базовых понятий о том, как читать документацию, не проверяет факты, которые излагает, грязно выражается в не предназначенных для этого местах, и чересчур серьезно в плане разработки относится к языку программирования, созданному в основном для обучения школьников и первокурсников. Да, реально печаль. Спасибо. Made my day. Moar plz.
Когда выполнение доходит до строчки (370 в файле BlockFileOfT):
raise new FileNotOpenedException(fi.FullName);
Программа сжирает всю оперативку за пару секунд и нагинает комп. Я посмотрел на IL код - вроде всё нормально. Ещё я поставил readln до и после этой строчки.
@Admin, мне уже 2 раза пришлось сделать принудительную перезагрузку. Пожалуйста, попытайтесь сделать что то в не сокращённом варианте программы.
Ну, там много что не касается проблемы, я не сокращал программу (не убирал лишнее). Я же говорю, это нереально, уже 2 раза пришлось делать принудительную перезагрузку.
Ну, скиньте хотя бы .exe который у вас получается, тоже посмотрю… Или может кто то поможет, у кого тоже СтакОверфлоу, а не зависание винды целиком? (.exe всё равно скиньте).
А, нашёл… Ошибка глупая… А сколько оно в у вас оперативки тратило перед тем как дать StackOverflowException? Посмотрите, пожалуйста, через что то типа Мониторинга ресурсов.
Да, но многопоточности нет в конструкциях самого Паскаля – это уже фичи чистого .NET, который никто не запрещает использовать, если очень надо. Поэтому именно в данном языке иметь базовые неизменяемые типы никакой практической ценности нет.
Разные библиотеки, стандартные и не очень, могут кишеть (? ) чем угодно, но это еще не делает их реализацию частью возможностей самого языка. С помощью родных конструкций Паскаля нельзя управлять многопоточностью, с помощью классов .NET, псевдоязыка CIL и среды CLR – можно. Но мы же говорим не о скрытых трюках, а о стандартных возможностях языка и его стандартных типах.
Кроме того, для надежной многопоточности в языке хорошо иметь поддержку неизменяемых переменных любого типа, а не неизменность отдельных типов, прибитых гвоздями.
Что касается неизменяемости строк в управляемых языках – это вообще оптимизация для более эффективной организации кучи и сборки мусора, а не для многопоточности.
Есть какое-то противоречие в вашей фразе. Оно странное. Вы сравниваете язык Паскаль и классы .NET. Тогда давайте будем уже сравнивать языки PascalABC.NET и C#.
Ваши попытки сказать, что .NET - библиотеки к PascalABC.NET не имеют отношения я не понимаю.
Чтобы не быть голословным приведите пожалуйста примеры конструкций языка C#, которые поддерживают многопоточность ну и которых нет в PascalABC.NET. Иначе я не пойму, о чем Вы говорите.
Я их не сравниваю, а просто разделяю понятия. Родные конструкции языка и их возможности – это одно, возможности совместимых библиотек и нижележащей платформы – другое. Они между собой слабо связаны и развиваются независимо.
Они к языку имеют отношение только в том смысле, что их как-то можно подключить и использовать в программах на этом языке. Т.е. они имеют отношение к более широкому понятию системы программирования, а не к самому языку – примерно также, как возможности библиотеки LCL являются стандартной составляющей системы программирования Lazarus, а не диалекта языка ObjectPascal, который реализует компилятор FreePascal.
Иными словами, Lazarus – это система программирования в визуальной RAD-среде (1) на языке ObjectPascal (2) и на базе фреймворка LCL (3). Т.е. существует четкое разделение понятий на среду разработки (1), язык (2), базовую платформу (3) и систему программирования (1+2+3).
В PABC.NET есть постоянная путаница этих понятий, из-за того что нет отдельного названия для языка (точнее своего диалекта), который семантически был бы отделен от названия среды и системы программирования.
По случаю предлагаю своё название: ЮФУ-Паскаль – по аналогии с Борланд Паскаль. Или Ростов-Паскаль Ну, или по-модному: Modern Pascal / Future Pascal / dotPascal.