Comments 16
Мне кажется, или этому топику дико не хватает реализации?
Поясните, пожалуйста.
Ваша идея возможно и хороша, но без прикреплённой реализации это на статью не тянет, такое лучше писать в комментариях к оригинальной статье и довести это до определённости.
Коль разумеется, почему бы и не написать?:)
На Вашем месте я б убрал статью в черновики, дописал её (с готовой реализацией того, что генерирует такие вот свитчи), а уже потом выкладывал бы. Иначе на фоне той статьи Ваша выглядит как необоснованная критика, ибо там есть не только теория, но и практическая реализация. Вот.
Разумеется, можно написать скрипт который автоматически сгенерирует такой switch не только для 4-х но и для любого количества условий.
Коль разумеется, почему бы и не написать?:)
На Вашем месте я б убрал статью в черновики, дописал её (с готовой реализацией того, что генерирует такие вот свитчи), а уже потом выкладывал бы. Иначе на фоне той статьи Ваша выглядит как необоснованная критика, ибо там есть не только теория, но и практическая реализация. Вот.
Спасибо за «возможно хорошую» оценку.
Мне жаль и непонятно почему вы восприняли мою заметку как критику на статью по ссылке — взгляните на мой третий абзац, я как раз пишу, что то решение хорошее, с моей точки зрения.
т.е. нет критики — где вы ее увидели?
Моя заметка не коментарий к оригинальной статье. Автор той статьи предложил свой вариант решения, я свой. Я не разбираю его решение и не обсуждаю его. Я привел его лишь как ссылку на проблему. Одним из вариантов решения для которой я предложил свой выход.
Далее — у меня есть и скрипт и програмулька в которой этот switch вызывается как инлаин функция и там все работает. Я же написал — все проверенно под дебианом.
Я не привел эти части, так как хотел, чтобы идея была видна в чистом виде. Если есть желание их можно привести — но, по сравнению с самой идеей эта рутина.
И, так как, вы уже один раз ощутили мои слова как критику, то прошу мой ответ не принимать как критику уже на ваш комент. Я просто хочу разобраться, понять что вы сочли бы за «готовую реализацию» и не лучше ли все-таки оставить идею в чистом виде. А кому она понадобится применит ее в своем случае.
Мне жаль и непонятно почему вы восприняли мою заметку как критику на статью по ссылке — взгляните на мой третий абзац, я как раз пишу, что то решение хорошее, с моей точки зрения.
т.е. нет критики — где вы ее увидели?
Моя заметка не коментарий к оригинальной статье. Автор той статьи предложил свой вариант решения, я свой. Я не разбираю его решение и не обсуждаю его. Я привел его лишь как ссылку на проблему. Одним из вариантов решения для которой я предложил свой выход.
Далее — у меня есть и скрипт и програмулька в которой этот switch вызывается как инлаин функция и там все работает. Я же написал — все проверенно под дебианом.
Я не привел эти части, так как хотел, чтобы идея была видна в чистом виде. Если есть желание их можно привести — но, по сравнению с самой идеей эта рутина.
И, так как, вы уже один раз ощутили мои слова как критику, то прошу мой ответ не принимать как критику уже на ваш комент. Я просто хочу разобраться, понять что вы сочли бы за «готовую реализацию» и не лучше ли все-таки оставить идею в чистом виде. А кому она понадобится применит ее в своем случае.
Предыдущий пост был о том, как ускорить процесс перебора строк. Здесь же сравнивать придётся со всеми строками, что долго (а потом и проводит разбор сравнения, хотя компилятор его сможет оптимизировать). Да и классический operator== подчиняется свойству следствия, т.е. 2 bool_i будут true только если var_i == var_j, i!=j.
Эта вещь может быть полезна при использовании не равенства, а подобия, но тема явно требует развития, пояснения, примеров.
P.S. Вы, случаем, не занимались раньше ПЛИСами?
Эта вещь может быть полезна при использовании не равенства, а подобия, но тема явно требует развития, пояснения, примеров.
P.S. Вы, случаем, не занимались раньше ПЛИСами?
*ой, конечно же имелась в виду транзитивность.
У меня тоже есть уверенное ощущение, что решение с constexpr быстрее. Просто для разбора оно, как мне кажется, сложнее чем мной предложенное. И расточительность сравнения всех строк в рантайме автором предыдущего поста, как и вами, справедливо отмечена.
не понял термина «свойство следствия для ==» — если вы имеете ввиду, что работа истиностных вариантов отличающих от класических возможна только тогда когда несколько различных var_i -ов имеют одинаковы значения, то разумеется я согласен.
позвольте вопросы: что имеется ввиду под «полезноостью при подобии»? Какие вы хотели бы видеть «развития, пояснения, примеры»? Заранее благодарю.
не понял термина «свойство следствия для ==» — если вы имеете ввиду, что работа истиностных вариантов отличающих от класических возможна только тогда когда несколько различных var_i -ов имеют одинаковы значения, то разумеется я согласен.
позвольте вопросы: что имеется ввиду под «полезноостью при подобии»? Какие вы хотели бы видеть «развития, пояснения, примеры»? Заранее благодарю.
Почему-то поздно появился ваш P.S. про ПЛИС — т.е.вы имеете ввиду программируемые электронные компоненты?
Если да, то нет, не занимался. Если нет, то что вы имеете ввиду?
Если да, то нет, не занимался. Если нет, то что вы имеете ввиду?
В дополнении уточнил: если operator== транзитивен (а равенство таким и должно быть, в отличие от подобия), то зачем перебирать варианты, в которых несколько равенств выполняются? Ведь о том, что выполнится >1 равенства станет известно на этапе компиляции. А в случае с неким operator^, который вернёт true в случае отличия не более чем на 1 символ, например, перебор всех вариантов будет иметь смысл (var_1 = «vasya»; var_2 = «pesya»; test = «vesya»).
Идея про operator^ кажется мне интересной, но дайте пока мне немного ее продумать, привыкнуть к ней в данном контексте — я медленно думаю.
А вот как избежать перебора для ==, хоть и транзитивного? Сначала же невозможно знать есть ли совпадающие занчения — конструкция должна быть общей.
А вот как избежать перебора для ==, хоть и транзитивного? Сначала же невозможно знать есть ли совпадающие занчения — конструкция должна быть общей.
Перебора можно избежать, использовав оператор "<" вместо "==" и построив сбалансированное дерево поиска в операторе switch.
Конечно, сохранять результаты в булевские переменные уже будет нельзя, чтобы не вызывались лишние сравнения.
Например, для псевдо-кода
будет что-то типа
Для поиска среди N строк — log2(N)
Конечно, сохранять результаты в булевские переменные уже будет нельзя, чтобы не вызывались лишние сравнения.
Например, для псевдо-кода
switch (str) {
case "abc": // 1
case "def": // 2
case "hjk": // 3
case "qwe": // 4
case "xzy": // 5
default: // 6
}будет что-то типа
switch (
str < "qwe"
? str < "def"
? (str == "hjk" ? 1 : 0)
: (str == "def" ? 2 : 0)
: str == "qwe"
? 4
: (str == "xyz" ? 5 : 0)
)
{
case 1: // 1
case 2: // 2
case 3: // 3
case 4: // 4
case 5: // 5
default: // 6
}Для поиска среди N строк — log2(N)
Спасибо за идею — да основываясь на существующей операции сравнения, как известно, можно строить двоичные деревья поиска, со всеми у них имеющими вкусными плюшками.
Позвольте сразу вопрос: одна и та же ли конструкция будет работать со всеми типами переменных?
предложенный мной "==" -путь работает.
И наконец до моего твердолобия дошло что-же оказывается вы хотите:
Если не ошибаюсь, то вы представили, что я намереваюсь вкладывать мой свич в какую-то обертку, правильно? И вот эту-то реализацию ждет нормально(т.е. объектно) думающее сообщество?
Если да, то дело в том что я не собираюсь этого делать. Я уже писал выше, что применяюю такой свич как инлаин функцию для всех типов переменных.
Третий абзац моей заметки как раз о том, что я не использую дополнительных возможностей. Этот кусок можно прямо вкладывать в код.
Еще раз благодарю за обсуждение, жду ваших соображений.
Позвольте сразу вопрос: одна и та же ли конструкция будет работать со всеми типами переменных?
предложенный мной "==" -путь работает.
И наконец до моего твердолобия дошло что-же оказывается вы хотите:
Если не ошибаюсь, то вы представили, что я намереваюсь вкладывать мой свич в какую-то обертку, правильно? И вот эту-то реализацию ждет нормально(т.е. объектно) думающее сообщество?
Если да, то дело в том что я не собираюсь этого делать. Я уже писал выше, что применяюю такой свич как инлаин функцию для всех типов переменных.
Третий абзац моей заметки как раз о том, что я не использую дополнительных возможностей. Этот кусок можно прямо вкладывать в код.
Еще раз благодарю за обсуждение, жду ваших соображений.
Позвольте сразу вопрос: одна и та же ли конструкция будет работать со всеми типами переменных?
Мой пример был сделан для std::string. Но будет работать с любыми объектами, у которых правильно реализованы operator< и operator==
И наконец до моего твердолобия дошло что-же оказывается вы хотите:
Если не ошибаюсь, то вы представили, что я намереваюсь вкладывать мой свич в какую-то обертку, правильно? И вот эту-то реализацию ждет нормально(т.е. объектно) думающее сообщество?
Да, например, в зубодробительный template :)
Sign up to leave a comment.
Еще один «switch для строк» — но не только для строк и не только «switch»