Так они еще с реализацией определиться не могут. Ладно хоть согласились совсем дряной код переписать и запихать его в std2

Я, правда, вижу уже какой-нибудь говнокод, типа: std::vector<bool> vbool2Tovbool(const std2::vector<bool> &v) {...}

все ради олимпиадных погрмоистов!

зачем им ваш этот с++

просто часто ли нужен поиск единичного экземпляра с препроцессингом?

кмп ван лав

он в любом случае быстрее серча, да

но часто ли это нужно? Лучше бы ахо-корасика запилили

Меряетесь кто знает больше алгоритмов?)

Хоть что то завезли - уже норм

вроде можно свою функцию поиска запихнуть, если моя памят ьменя не подводит

ах ты!

в серчер 17 плюсов

лет ми гугл зет щит

http://en.cppreference.com/w/cpp/experimental/search

ну вот, зря гуглил(

но часто ли это нужно? Лучше бы ахо-корасика запилили

Надо вставлять то, что используется повсеместно. А рад "чтобы было" - нафиг

Надо вставлять то, что используется повсеместно. А рад "чтобы было" - нафиг

мне кажется иметь изкоробки линейный поиск нескольких образцов весьма хорошая вещь

наверное сначала добавляют аст в компилятор, потом тестят, потом ищут причины почему не clang

Суть в том, что что мешает взять реализацию для проекта и использовать ее. Не вижу проблемы в этом

или подрубать хедеры-сорцы ради одной функции

Потому что это в бизнес сегментах все идет медленно. Вон, запилил они студию под мак, один фиг как не могешь на ней в с++ так и не будешь. Все пихают свой С#

Они еще не обвели их рамочкой и не щелкнули правой кнопкой мышки

модные штуки из 80-90ых....

Почему?

А чем он лучше тупого бинпоиска?

Тимсорт!

А чем он лучше тупого бинпоиска?

то что тебе не нужна отсортированная последовательность

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

А ты один его пилишь?

Вот поэтому она и не закончится - чувство прекрасного у каждого извращено по своему)

то что тебе не нужна отсортированная последовательность

Спс

вот я так подумал, что единственное что остается - пилить ИИ, который будет модифицировать интерфейсы под конечного пользователя, но это ахинея получается

ну а что?))) Мои внуки будут жить а STL не будет нормальным))) Я уже смирился с этим

У них были проблемы в архитектуре компилятора. Изначально было сделано не совсем по правилам (см двухфазный поиск в msvc), а чтобы это починить и сделать совершенно верно требуется очень много времени. Без этого - нет возможности делать некоторые новые С++ вещи. Сейчас вроде почти дочинили, НО constexpr - самая сложная часть C++11 для имплементации. так что будут еще мучаться какое-то время с ним

жаль :(

Деревья поиска

Или суффиксные, как они там правильно:)

shuffle_weighted_n shuffle_weighted Могу даже скинуть приблезительную имплементацию, но она O(N*N) в худшем случае

Короче для паттерн матчинга

рандомно перемешать с учётом веса

И чтоб в качетстве паттерна - маску можно было или регекс простенький :)

И чтоб в качетстве паттерна - маску можно было или регекс простенький :)

Тогда вообще пушка буит.

Ненене

о, было бы топ PATRICIA запилить

Автомат для поиска паттернов-масок/регексов. Который всмысле не зависит от количества шаблонов

правда это специфично для типов у которых можно взять разряд

это trie + radix tree грубо говоря

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

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

в итоге оче круто для длинных строк

её в ллвм юзают для ип-масок

куда я попал... Мне и стандартных хватает)

поиск за O(klog(N)), k - количество разрядов

Кроме мозга

Я один раз сломал мозг, когда осознал как скриптовые языки работают) Я не хочу)

Потому что могут. То есть не могут. Сорцы vc то еще удовольствие

и при этом можно легко реализовать поиск по префиксу совпадающему из-за сравнения(возращать ключ с наиболее совпадающим префиксом)

ну да, у меня есть нешаблонная гвонокодистая реализация

и оан быстрее мэпы со стрингами все равно

Потому что могут. То есть не могут. Сорцы vc то еще удовольствие

Раз ты копался - компилятор студийный сильно отличается от того, что идет в составе win developer sdk?

Раз ты копался - компилятор студийный сильно отличается от того, что идет в составе win developer sdk?

Чот не приходило в голову сравнивать такие вещи

Чот не приходило в голову сравнивать такие вещи

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

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

я попробую просто сделать темплейт версию для начала...

и сделать такой же интерфейс и впихуть туда несчастную структуру?

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

копаться в сорсах темплейт библиотек веселое дело само по себе

там надо сдлеать очень хитрое низкоуровневое адище - добавить новый тип нодов - листья. Эти ноды должны хранить необщую часть дерева одним куском а не в виде односвязного списка. За счёт этого увеличится локальность данных и уменьшится количество аллокаций

а, типа сжать листья?

этим поцаны придумавшие трай задумались и сжали просто значения

*патрицию

узлы то есть....

Ой

вот такие магии с числами не есть хорошо

но это очень оптимизированное взятие бита

в строке

index - это ... ?

ой, хедере забыл не вырезать