Отчего же, проходит.
Это gcc поддерживает юникод в неудобном виде. Во-первых, нуждается в параметре -fextended-identifiers, во-вторых, требует записи в виде \uXXXX, что не очень удобоваримо, но для кодогенераторов подходит.
Что именно Вы имели ввиду? Я говорил приблизительно о следующем:
Пишите L, жмёте на <Чего-то> и буква раскрывается в полновесную конструкцию с понятными ключевыми словами. То есть на уровне транслятора нет поддержки сокращений. В этой же заметке это представлено именно как возможность языка.
А зачем, Вы можете объяснить? Назовите ту самую главную причину, по которой НЕОБХОДИМО поддерживать кириллицу в идентификаторах? Незнание английского у программистов, работающих на МО?
Здесь поддержка кириллицы была преподнесена как что-то позорное для идиотов, которых нужно гнать в шею.
Если транслятор корректно генерирует код на С++, то и исполняемый двоичный файл получить не проблема. В конечном итоге транслятор должен брать на себя возню со сторонним компилятором, но если это сейчас не так, то можно так и написать, что нужно выполнить примерно следующее:
Я так и не смог написать хороший вводный текст к данной статье, поэтому начну просто с примеров
Это, скорее всего, означает, что Вам нечем обосновать создание этого языка, кроме как потому что хочется. Обоснование — это и был бы хороший вводный текст.
Какой конкретно язык вы предлагаете взять за пример образцового синтаксиса?
Синтаксис второстепенен. В идеале язык может предлагать синтаксис на выбор.
Но если хочется сосредоточиться на одном базовом, то лучше спросить у потенциальных пользователей.
По поводу символов русского/любого другого языка (кроме общепринятого латинского алфавита)
В современных воплощениях языков общепринятым является поддержка юникодных идентификаторов. Это есть даже в Си, не говоря уже про более современные языки.
Мотивация автора странная, но поддержка кириллицы и не только давно есть даже в Си, не говоря про более новые языки. Делается это очень просто и нет причин в языке ограничивать идентификаторы латиницей.
При чём тут UTF-8? В стандарте ISO C на mblen, который используется в определении php_mblen, сказано, что он определяет количество байт символа кодировки, определяемой по LC_CTYPE. На каком основании в алгоритме делаются вещи, будто бы LC_CTYPE задаёт именно UTF-8? Повторю ещё раз, покажите, пожалуйста, место, где Вы увидели в стандарте на mblen, что
В мультибайтовых кодировках существует обратная совместимость с ASCII
Можно ли в таком случае обойтись без mblen?
Если же задачей всё ограничивается именно UTF-8, то, конечно, mblen — это избыточный тормоз.
Палка на двух концах.
Это объяснение? Потому что совместимо, поэтому не совместимо?
Как в таком случае можно рассуждать об оптимальности кода?
Потому что для оценки не всегда нужен весь контекст, а вот для создания корректного алгоритма — нужен. Особенно, если окажется, что изначальный алгоритм некорректен и сравнение бессмысленно.
В этом-то и проблема плохого кода, что его потом и не перепишешь, не нарвавшись на остальные пахучие особенности общего кода.
В мультибайтовых кодировках существует обратная совместимость с ASCII
Из чего это следует? Я в стандарте этого не видел. Можете указать, где это сказано точно? Если это так, то алгоритм можно написать намного эффективней, так как mblen тяжеловесна.
И всё становится предельно ясно.
Тогда объясните мне, пожалуйста, как это понимать: *ptr == '\0' ? 1 для таких настроек: #ifndef HAVE_MBLEN
# define php_mblen(ptr, len) 1
И почему при обратной совместимости в качестве конца строки используется не '\0', а null wide character.
Мы всё еще рассматриваем пользу ссылок в некоторых случаях.
Можно конкретней? Ссылок на то, что last_chars[0] = last_chars[1];
last_chars[1] = *ptr;
Приводит к двойному копированию последовательностей 1-байтовых символов, или что-то ещё?
Увы, коллега, не похоже на то. Я начал смотреть, что такое php_mblen и уже это заняло много времени с учётом контекста функции. Дело в том, что php_mblen в зависимости от значений макросов при сборке и переменных окружения может быть гарантировано однобайтным. Тогда неясно, на каком основании выполняется эта часть
*ptr == '\0' ? 1
потому что в таком случае цикл может остановиться только по достижении конца массива и вообще нет смысла его перебирать, так как сразу можно перейти к концу(экономия процессорного времени, да).
Указанная Вами функция не является самосотоятельной частью, воплощающей стандарт, а зависит от объемлющего кода. Откуда мне знать обо всех задумках или ошибках, которые были здесь допущены. Например, почему в многобайтной кодировке, точный тип который задаётся окружением, символ перевода строки задаётся одним char? Здаётся мне, что в этой функции проблемы не исчерпываются использованием неструктурных переходов.
Ну и, наконец, неужели для того, чтобы понять, что двойное копирование строки для 1-байтных последовательностей — это нечто неоптимальное, Вам нужен другой алгоритм?
Где же ответ? В функции есть лишние присваивания, не оптимальное использование switch, но Вы делаете акцент на экономии процессорного времени. Где же оно в этом плохо написанном коде?
Это gcc поддерживает юникод в неудобном виде. Во-первых, нуждается в параметре -fextended-identifiers, во-вторых, требует записи в виде \uXXXX, что не очень удобоваримо, но для кодогенераторов подходит.
В этом есть маркетинговый смысл, но, похоже, Вы перестарались, судя по реакции.
Но надеяться под это собрать комитет, на мой взгляд, наивно.
Пишите L, жмёте на <Чего-то> и буква раскрывается в полновесную конструкцию с понятными ключевыми словами. То есть на уровне транслятора нет поддержки сокращений. В этой же заметке это представлено именно как возможность языка.
А мой ответ был на следующее:
Здесь поддержка кириллицы была преподнесена как что-то позорное для идиотов, которых нужно гнать в шею.
Но если хочется сосредоточиться на одном базовом, то лучше спросить у потенциальных пользователей.
Если же задачей всё ограничивается именно UTF-8, то, конечно, mblen — это избыточный тормоз.
Это объяснение? Потому что совместимо, поэтому не совместимо?
Удивляюсь, что это нужно объяснять. :)
В этом-то и проблема плохого кода, что его потом и не перепишешь, не нарвавшись на остальные пахучие особенности общего кода.
Тогда объясните мне, пожалуйста, как это понимать:
*ptr == '\0' ? 1для таких настроек:#ifndef HAVE_MBLEN# define php_mblen(ptr, len) 1
И почему при обратной совместимости в качестве конца строки используется не '\0', а null wide character.
Можно конкретней? Ссылок на то, что
last_chars[0] = last_chars[1];last_chars[1] = *ptr;
Приводит к двойному копированию последовательностей 1-байтовых символов, или что-то ещё?
потому что в таком случае цикл может остановиться только по достижении конца массива и вообще нет смысла его перебирать, так как сразу можно перейти к концу(экономия процессорного времени, да).
Указанная Вами функция не является самосотоятельной частью, воплощающей стандарт, а зависит от объемлющего кода. Откуда мне знать обо всех задумках или ошибках, которые были здесь допущены. Например, почему в многобайтной кодировке, точный тип который задаётся окружением, символ перевода строки задаётся одним char? Здаётся мне, что в этой функции проблемы не исчерпываются использованием неструктурных переходов.
Ну и, наконец, неужели для того, чтобы понять, что двойное копирование строки для 1-байтных последовательностей — это нечто неоптимальное, Вам нужен другой алгоритм?