Есть ли у Паскаля будущее?

[debi12345]

На сегодня мы имеем не работу со строками, а некое извращение, где нужно всегда нечто подразумевать в уме.

Алекс, в ФПЦ со строками все прозрачно и четко как часы - если вся программа насквозь юникодная. Объявляешь все текстовые переменные как WideString, используюешь UCS2-based GUI-компонеты - и ни о чем стороннем не думаешь

[mse]

UnicodeString not WideString.

[Лекс Айрин]

mse, главное, что работает.

[SSerge]

и ни о чем стороннем не думаешь

Стороннее - это например о том, как в WideString прочитать из файла с произвольной кодировкой, да?

[debi12345]

как в WideString прочитать из файла с произвольной кодировкой

Эта проблема никоим образом не зависит от языка - тут нужна явная перекодировка, ессно в юникод - чтобы далее в программе не думать о кодировках.

[alexey38]

если вся программа насквозь юникодная

Во-первых, Ваша мысль начинается со слова "если".
Во-вторых, задачи бывают разные. Например, на экранные формы Вам нужно выводить в уникоде, но еще нужно работать с неким устройством, или наследованным софтом (в виде исполняемого файла), который работает с некоторой конкретной однобайтовой кодировкой. Если такую задачу написать на Дельфях, то без всяких "если" не потребуется ни одной функции преобразования. На ФПС и Лазаре потребуется куча функций преобразования кодировок.

[debi12345]

но еще нужно работать с неким устройством, или наследованным софтом (в виде исполняемого файла), который работает с некоторой конкретной однобайтовой кодировкой. Если такую задачу написать на Дельфях, то без всяких "если" не потребуется ни одной функции преобразования.

Даже если устройство "понимает" напрмер CP866 или ISO8859-5 ? Эти преобразования не относятся к языку, а относятся к доп.библиотекам вроде ICONV (или к wrapper-ам к оным из языка). Для CP866 сам написал конвертор (чтобы не тащить в экзешник тяжелый юнит), он для обмена с UCS2 - протсейший.

[alexey38]

Даже если устройство "понимает" напрмер CP866 или ISO8859-5 ? Эти преобразования не относятся к языку

А для чего это относить к доп.коду и доп.библиотекам? Если это все прекрасно и более качественно решается на уровне компилятора, особенно конвертация строковых констант (зачем их конвертить в реалтайме?).

15 лет назад я очень активно писал на ассемблере, применял там широко макросы, которые обеспечивали циклы, условия и т.п., т.е. метки самому не приходилось ставить вообще, в этом смысле код не сильно был сложнее паскаля. Основной гемор был со строками и математикой, и был вынужден вернуться с асма на паскаль. Вернулся именно на паскаль, а не на С++, как раз ради того, чтобы не думать при работе со строками.

Вот есть целочисленные типы данных: smallint (int16), integer (int32), int64. Мы легко делаем преобразования между этими типами, не используя вызовов лишних функций, компилятор это делает сам. Со строками в разных кодировках тоже самое.

[debi12345]

Со строками в разных кодировках тоже самое.

А файлы и устройства ? Как угадаешь какую кодировку они юзают ? Хотя есть конечно С-ые "guessing" библиотеки... Поэтому здесь другой подход - считаешь что кодировка может быть любой (не-автообрабатываемой компилятором) и используешь сторонние (или RTL/FCL-ские) специализиравонные библиотеки.

[alexey38]

А файлы и устройства ? Как угадаешь какую кодировку они юзают ?

1. При объявлении переменной достаточно указывать ее кодировку, в этом случае все необходимые переконверторы компилятор может подставить автоматически.
2. Строковые константы еще на этапе компиляции автоматически преобразовывать в ту кодировку, в которую присваивается строка.
3. Функции ручного преобразования удалять не нужно, их можно использовать при работе с байтовыми массивами.

При таком подходе для 99.99% случаев вообще не потребуется никогда вызывать ни каких лишних функций и все будет работать автоматически. В т.ч., например, если есть функция вывода на консоль в системной кодировке, а строка например в несисистемной, то автоматически вызывается конвертор и т.п.

[debi12345]

При объявлении переменной достаточно указывать ее кодировку, в этом случае все необходимые переконверторы компилятор может подставить автоматически.

А, на уровне отдельной переменной Тогда понятно
Только вот юнит, обпечивающий данный (редко требуемый) функционал в ран-тайме - будет тяжеловесныим и зазря раздует экзешник. Лично я хранил бы (и храню - в MSE-программах) все переменные в UCS2/4, и делал конверcию под них по факту под нужную кодировку - мелкими функциями. И унификация размера символов, и вытекающий из нее индексный доступ к символам ЛББЫХ строковых переменных, и НЕраздувание размера редко треубуеммым функционалом...

Добавлено спустя 7 минут 40 секунд:
И уровень задания кодировки лучше убрать с переменных (оставив их как моноширинные USC2/4), а задавал бы кодировку для файлов, устройств (принтеров,..) и соединений с БД (например как в MSE - где компонент CONNECTION имеет опцию "dbo_utf", предписывающую на лету конвертить текстовые данные для такого соединения).

[alexey38]

А, на уровне отдельной переменной Тогда понятно
Только вот юнит, обпечивающий данный (редко требуемый) функционал в ран-тайме - будет тяжеловесныим и зазря раздует экзешник. Лично я хранил бы (и храню - в MSE-программах) все переменные в UCS2/4, и делал конверcию под них по факту под нужную кодировку - мелкими функциями. И унификация размера символов, и вытекающий из нее индексный доступ к символам ЛББЫХ строковых переменных, и НЕраздувание размера редко треубуеммым функционалом...

Так я Вам и говорю, что весь этот анализ при более продуманной реализации строк выполнялся бы не в runtime, а на стадии компиляции. Тип кодировки можно было хранить не в поле типа, а в самом типе. Если все переменные одного типа, то в коде вообще не должно быть ни проверок, ни перекодировок.

[debi12345]

Так я Вам и говорю, что весь этот анализ при более продуманной реализации строк выполнялся бы не в runtime, а на стадии компиляции

Как на этапе компиляции можно заранее знать кодировку будущих файлов, устрфств, БД.. ? Нельзя - поэтому функционал перекодировки придется пихать в рантайм (размер экзешника), а значит нужно стараться сделать этто код максимально компактным - а значит универсальый (для всех кодировок) код малоподходящ.

[alexey38]

Как на этапе компиляции можно заранее знать кодировку будущих файлов, устрфств, БД.. ?

Вы сами это укажите, объявив переменную требуемого типа. Вы же сегодня вызываете вручную функции преобразования, значить знаете это заранее.

Конечно бывают (очень редко) адаптивные алгоритмы, но речь не о них, низкоуровневые инструменты не нужно запрещать. Нужно исключить возможность ошибок кодировок, и исключить лишнюю ручную работу по перекодировке. Сегодня тип кодировки хранится в структуре строковой переменной, но этого недостаточно. Нужно это задавать еще на уровне компиляции. Но главное нельзя тип строковой константы привязывать к кодировке файла с исходником, т.к. кодировка исходного файла и кодировка переменной - это не одно и тоже. Исходники могут быть в UTF8, а строковая константа может быть и в системной, ANSI-кодировке или иной, это должно определяться не кодировкой файла, а типом, куда присваивается константа.

[Mirage]

Сперва пара слов по топику.

Это касается Лексера и Парсера. Оптимизатор придется писать самому.

Есть же LLVM, который не только оптимизацию даст, но и генератор кода для многих платформ.
Надо стараться встать на плечи гигантов, особенно при недостатке собственных ресурсов.

Лень скроллиться в VAR-секцию и обратно Пустая трата времени.

Зачем скролиться? Включил разделение редактора на две части и все.

carrots, код в collections.pas просто чудовищен. Надеюсь, Вы его приложили в качестве иллюстрации того, как не надо делать.