именно развитием идей и основной разработкой на данный момент занимаюсь только я. Marshall Clow - мэйнтейнер и у него всегда мало времени на это

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

Спс

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

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

У Маршалла и так работы в Open Source выше крыши

но он мне помогает, если получается у него

всё таки у него опыта в раза полтора-два больше, чем мне лет

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

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

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

дай сначала STL сделать нормальным)))) а ты уже с ИИ лезешь

дай сначала STL сделать нормальным)))) а ты уже с ИИ лезешь

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

@antoshkka твой PR с constexpr упорно игнорится

они же вроде уже развернулись лицом к С++, так чего же всё так грустно? у них там армия программистов же есть, могут делать это

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

@antoshkka твой PR с constexpr упорно игнорится

жаль :(

Если у кого-то есть дельные предложения, как можно расширить Boost.Algorithm - пишите сюда и в ЛС дублируйте. Обсудим, и если идея годная, то я постараюсь добавить

жаль :(

я стараюсь достучаться до Маршалла, но об этом он упорно не хочет говорить?

Если у кого-то есть дельные предложения, как можно расширить Boost.Algorithm - пишите сюда и в ЛС дублируйте. Обсудим, и если идея годная, то я постараюсь добавить

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

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

Если у кого-то есть дельные предложения, как можно расширить Boost.Algorithm - пишите сюда и в ЛС дублируйте. Обсудим, и если идея годная, то я постараюсь добавить

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

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

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

Суффиксные деревья\автомат

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

что это такое?

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

Суффиксные деревья\автомат

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

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

ты и так можешь с помощью Boost.Algorithm заниматься поиском с помощью regex

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

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

ты и так можешь с помощью Boost.Algorithm заниматься поиском с помощью regex

Ненене

или я неправильно понял?

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

кинь-ка мне в ЛС

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

или я неправильно понял?

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

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

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

это разновидность бора какая-то?

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

автомат для поиска масок... а зачем? ?

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

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

лол, прикольная идея

автомат для поиска масок... а зачем? ?

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

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

но этого не будет пока что)))

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

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

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

по перфомансу лучше сжатого бора?

Суффиксные деревья\автомат

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

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

там ничего сложного. ПРосто нужно один раз сломать мозг и всё становится на свои места

по перфомансу лучше сжатого бора?

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

там ничего сложного. ПРосто нужно один раз сломать мозг и всё становится на свои места

Кроме мозга

там ничего сложного. ПРосто нужно один раз сломать мозг и всё становится на свои места

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

кстати, мб тут кто инфой обладает - почему Microsoft настолько медленно имплементят поддержку стандартов?

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

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

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

оно то можно. Понимаешь ли, на колене такую вещь напистаь несложно

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

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

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

такого добра много (если что, спрошу у тебя реализацию). Для интереса посмотрите на Boost.Trie

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

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

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

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

Если ты напишешь STL-совместимую мапу на основе соответствующего STL-стайл Patricia tree, докажешь, что оно реально намного эффективнее и не только в случае стрингов, то это одно (вариант, после которого начинается серьёзная работа по продвижению). До этого момента это мысли :) Я верю тебе и понимаю, что на стрингах оно будет рвать. Но этого мало

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

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

@Mrsameman Если ты готов взяться за это, это будет круто

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

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

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

Я говорю открыто - ни у меня, ни у Маршалла нет на это времени

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

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

уже чуешь, что оно не совсем обощённое ??

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

Просто посмотри на Boost.Trie

исходники в Интернете найдёшь

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

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

примерно.... да)

ERROR: S client not available

Вон тебе @antoshkka даже может поможет.

Он там вроде как ментором был

Просто посмотри на Boost.Trie

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

Хочу сразу предупредить, что это весело - Копаться в Boost.Trie (нет)

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

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

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

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

Да

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

*патрицию

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

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

в общем, дерзай.

Ой

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

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

в строке

index - это ... ?

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

index - индекса бита который хотим взять

а, ну там тогда byteNum и bitNum как будто перепутаны

Кстати, а никто не исследовал, почему std::mutex и std::timed_mutex не реализованы вот так: https://patchwork.freedesktop.org/patch/41241/ Вроде бы ничего не мешает, а автор обещает 10% прирост производительности?

а, ну там тогда byteNum и bitNum как будто перепутаны

лоло, похоже на магию которую я не помню, надо будет пересмотреть кодес и литературу перечитать

Кстати, а никто не исследовал, почему std::mutex и std::timed_mutex не реализованы вот так: https://patchwork.freedesktop.org/patch/41241/ Вроде бы ничего не мешает, а автор обещает 10% прирост производительности?

Так pthread мьютексы, да и вообще все так реализованы (cmpxchg в fast path или futex syscall). Вроде вся идея только в том, чтобы убрать вызов функции через указатель, и выкинуть все сложные кейсы (типа таймаута, рекурсии)

Всё верно, идея в том, чтобы оставить самый минимум и позволить инлайниться. Меня 10% прироста производительности завораживают, ничего не могу с собой поделать...

есть чат по си?

есть чат по си?

православного нет

здесь все вместе

но большинство сиплюсплюсники

но большинство сиплюсплюсники

еще и js-ники )

Странно ведь это про.схх