> В argv[0] перед путём к экзешнику ставится символ сердечко.
Это символ кодировки. Pathoswithin добавил.
Остальное проверю.
C-- Sphinx Compiler
-
Из хаоса в космос
О как. Странное решение.
Так, довёл до ума. Убрал это сердечко(а я думал, что это я временный костыль добавил ). Точнее, если там середечко, то оно уберётся, если там что-то другое стоять будет, то не уберётся.
Исправил я вывод warning'ов. Теперь консоль информативна, но не замусорена) На а свои отладочные выводы пока оставил. Хотя, видимо, скоро уберу.
Из проблем пока: почему-то вылетает при обработке файла keyboard.h. Я испытывал на том textreader, что ты выкладывал.
Так, довёл до ума. Убрал это сердечко(а я думал, что это я временный костыль добавил ). Точнее, если там середечко, то оно уберётся, если там что-то другое стоять будет, то не уберётся.
Исправил я вывод warning'ов. Теперь консоль информативна, но не замусорена) На а свои отладочные выводы пока оставил. Хотя, видимо, скоро уберу.
Из проблем пока: почему-то вылетает при обработке файла keyboard.h. Я испытывал на том textreader, что ты выкладывал.
- Attachments
-
-
cmm (219.44 KiB)Downloaded 283 times
-
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
Кстати, это сердечко означает кодировку UTF-8.
Хм. То есть в русских каталогах ничего не скомпилиться... А как-то попросить старый ASCII можно? Или преобразовать? Или только вручную? И вообще, где что написано про нововведение?
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
GerdtR
Боюсь нигде и никак. Автор регулярно кладёт на обратную совместимость.
Боюсь нигде и никак. Автор регулярно кладёт на обратную совместимость.
А где вообще что-то написано про этот параметр? Авторы до меня клали на планирование дальнейшего развития. И никакой альтернативы мне так и не предложили. Из всех вариантов самый совместимый.
Pathoswithin
Самый совместимый в Win с двумя наборами функций *A и *W. А не так, когда ядерное API меняют на лету.
Самый совместимый в Win с двумя наборами функций *A и *W. А не так, когда ядерное API меняют на лету.
Так проблемы же не с API, а с argv[0].
Pathoswithin
Это не проблема argv[0]. Это проблема всех программ. О чем 0CodErr уже написал.
Это не проблема argv[0]. Это проблема всех программ. О чем 0CodErr уже написал.
Главное, если путь из ASCII превратился в UTF8, зачем там этот байт ? Или он внезапно может стать UTF16, UTF-32, DBCS,что-то ещё ?И это проблема, конечно. Раньше пути начинались со слэша. Вот представим, что есть путь "/sys/Path/MyFile.ext". Если приложение захочет проверить (Path == "/sys/Path/MyFile.ext"), то вместо простого StrCmp(Path, "/sys/Path/MyFile.ext") придётся немного мудрить ещё.
Чтобы этот путь не меняя можно было передать в 70-ю функцию. Она понимает первые байты как маркеры кодировок. С другой стороны, так ли уж нужна поддержка CP866 и UTF-16 в файловых функциях? Может оставить только UTF-8 без всякого маркера?Serge wrote:Главное, если путь из ASCII превратился в UTF8, зачем там этот байт ? Или он внезапно может стать UTF16, UTF-32, DBCS,что-то ещё ?
akron1
По нормальному, я этот байт должен скипнуть из argv[0].
По нормальному, я этот байт должен скипнуть из argv[0].
Хм... теоретически можно перевести весь c-- на utf8. Только тогда исходники тоже должны быть в utf8, но текстовые редакторы у нас с utf8 не работают(или уже что-то есть?).
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
Для оберон-07 вопрос решен с помощью BOM-сигнатуры в начале файла исходника. Да, редакторы (пока) не поддерживают UTF-8, но компилятору какая разница? Наличие BOM-сигнатуры указывает компилятору на использование кодировки UTF-8. Реально это влияет на подсчет символов в строках для выдачи сообщений об ошибках компиляции и длину строковых констант. Например, такой код правильный, если используется ANSI.
Если UTF-8, то константы "ф", "ы", "п" будут уже два байта и программа не скомпилируется.
Code: Select all
CASE c OF
|"ф":
|"ы":
|"п":
END;
Не нужно. Максимум что нужно - добавить строковые литералы, например как это сделано в С11. Но с-- такой компилятор, что разобраться в исходниках - огромный труд.GerdtR wrote:Хм... теоретически можно перевести весь c-- на utf8. Только тогда исходники тоже должны быть в utf8, но текстовые редакторы у нас с utf8 не работают(или уже что-то есть?).
Проще уж библиотечку конверсий UTF8<->UTF16<->CP866, etc
Я предлагаю считать, что для PE-приложений абсолютно всё в UTF-8 без всяких маркеров - вход/выход системных функций 2,4,70,что-у-нас-там-ещё-принимает-строки, argv[0], все библиотеки. Иначе откуда, скажем, box_lib может узнать, хочет приложение строку в cp866 или в utf-8? Делать флаги для всех-всех-всех библиотек - означает дикие метастазы legacy по всей системе.
Сделаем мир лучше!
Who is online
Users browsing this forum: No registered users and 21 guests