История изменений

Цитирую:

Encoding: A string switch inherits the existing C translation from source to the execution character set unchanged. It introduces no new character set conversions, locale-dependent matching, or Unicode normalization passes. The following two constructs are semantically identical with respect to encoding:

Так вот, если все рассматривается как поток байт, то весь этот юникод идет лесом. В моем примере арабица и евреица с BIDI-байтом и без него визуально неотличимы. И да, в документе ничего не сказано о том, каким способом они предлагают реализовать эффективный парсер со сложностью O(k) вместо O(n*k), которую имеет цепочка условных операторов и strcmp. Опять же, рассуждения на тему constrain violation при различии типов переменной в операторе switch и строк в case-блоках лично меня вгоняет в когнитивный диссонанс, если не сказть в ужас. Какие в пень констрейнты в Си? У авторов какая-то каша в голове.

Так что иди сам внимательо предложенный текст почитай раза три. Может сам поймешь убожество предложенного. И да, почитай драгонбук, а именно ту главу, в которой идет речь о конструировании конечных автоматов для разбора регексов.

Эффективный парсер со сложностью O(k) - это та же задача. Строки в case-блоках преобразуются в регекс и количество конечных состояний автомата соответствует количеству строк. Если сматчена одна из альтернатив, то вызывается функция из case-блока. И да, исходник начинает зависеть от кодировки строковых литералов. Упаси ТНБ его из UTF в КОИ-8 конвертнуть :) В общем иди сам кури матчасть, может поймешь всю глубину проблем, которые возникнут при реализации этого предложения.

Цитирую:

Encoding: A string switch inherits the existing C translation from source to the execution character set unchanged. It introduces no new character set conversions, locale-dependent matching, or Unicode normalization passes. The following two constructs are semantically identical with respect to encoding:

Так вот, если все рассматривается как поток байт, то весь этот юникод идет лесом. В моем примере арабица и евреица с BIDI-байтом и без него визуально неотличимы. И да, в документе ничего не сказано о том, каким способом они предлагают реализовать эффективный парсер со сложностью O(k) вместо O(n*k), которую имеет цепочка условных оператлров и strcmp. Опять же, рассуждения на тему constrain violation при различии типрв переменной в операторе switch и строк в case-блоках лично меня вгоняет в когнитивный диссонанс, если не сказть в ужас. Какие в пень констрейнты в Си? У авторов какая-то каша в голове.

Так что иди сам внимательо предложенный текст почитай раза три. Может сам поймешь уюожество предложенного. И да, почитай драгонбук, а именно ту главу, в которой идет речь о конструировании конечнх автоматов для разбора регексов.

Эффективный парсер со сложностью O(k) - это та же задача. Строки в case-блоках преобразуются в регекс и количество конечных состояний атомата соответствует количеству строк/ Если сматчена одна из альтернатив, то вызывается функция из case-блока. И да, исходник начинает зависить от кодировки строковых литералов/ Упаси ТНБ его из UTF в КОИ-8 конвертнуть :) В общем иди сам кури матчасть, может поймешь всю глубину проблем, которые возникнут при реализации этого предложения.