в libc++ всякого говна бывает

в libc++ всякого говна бывает

имхо, утверждение применимо к любой стдлибе)

В нашем проекте boost::regex раза в три быстрее чем std

Ну да, я тоже думаю, что это -- очень смелое заявление.

В нашем проекте boost::regex раза в три быстрее чем std

но почему они тогда не в дев ветке(

1) Бенчи есть? 2) а есть инфа насчёт libstdc++?

Насколько я понимаю в маке используется libstdc++

но почему они тогда не в дев ветке(

Потому что ещё одна буст либа)

Насколько я понимаю в маке используется libstdc++

Но ты не уверен, да?

По поводу бенчмарков использовал Google benchmark, не сохранил код к сожалению

Потому что ещё одна буст либа)

-lboost_system достаточно же, не?

Насколько я понимаю в маке используется libstdc++

эммм, почему там libstdc++? то есть компилятор шланг, но билдят с libstdc++?

-lboost_system достаточно же, не?

Для чего?

Для чего?

для регулярок буста

для регулярок буста

На сколько я помню, должно быть что-то типа -lboost_regex

эммм, почему там libstdc++? то есть компилятор шланг, но билдят с libstdc++?

Вроде да, 100% сказать не берусь

-lboost_system достаточно же, не?

Просто ещё одна зависимость не оправдывала профитов

Вроде да, 100% сказать не берусь

мне тут подсказали, что по умолчанию вроде бы там libc++ берётся

Вроде да, 100% сказать не берусь

https://docs.brew.sh/C++-Standard-Libraries

Вроде да, 100% сказать не берусь

Ну вот я и говорю, что ты даже не знаешь , какая там либа RegEx одна, и какая другая (версия буст) тоже не говоришь, но уверен, что одна другой быстрее.

но я против Boost.Regex имею то, что она дырявая

Ну вот я и говорю, что ты даже не знаешь , какая там либа RegEx одна, и какая другая (версия буст) тоже не говоришь, но уверен, что одна другой быстрее.

Ну поэтому и сказал что в нашем проекте, а не в целом)

(хотя в последних версиях её уже значительно подправили)

На сколько я помню, должно быть что-то типа -lboost_regex

проверил, все так

В итоге ты получишь k*O(N) или O( K*N )

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

В итоге ты получишь k*O(N) или O( K*N )

если написать регулярку на отъебись, так что она работает как back-tracking, то да, будет работать как O(K * N) или хуже

жаль, что автомат строится в рантайме

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

Ну, там всё сложна... Разные реализациии уже есть, и Perl-mode везде...

Ну, там всё сложна... Разные реализациии уже есть, и Perl-mode везде...

не везде

тот же pire

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

если K это константа, то и сложность будет линейная.

жаль, что автомат строится в рантайме

можно написать имплементацию регулярок на шаблонах, магии или препроцессоре и построить в компайл-тайм или упаковка-билда-тайм или установка-сервиса-на-продакшен-тайм или когда угодно. Это вопрос имплементации

два раза выполнить одну и ту же регулярку - от этого сложность не изменится, и останется все той же линейной

можно написать имплементацию регулярок на шаблонах, магии или препроцессоре и построить в компайл-тайм или упаковка-билда-тайм или установка-сервиса-на-продакшен-тайм или когда угодно. Это вопрос имплементации

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

два раза выполнить одну и ту же регулярку - от этого сложность не изменится, и останется все той же линейной

для случая K регулярок длины L и длины текста N, препроцессинг будет K * L * L + время работы K * N для случая 1 регулярки длины L*K и длины текста N препроцессинг будет K*K*L*L и время работы N

Ладно, мы спорим ни о чём, и ходим по кругу. А вопрос уже решён

для случая K регулярок длины L и длины текста N, препроцессинг будет K * L * L + время работы K * N для случая 1 регулярки длины L*K и длины текста N препроцессинг будет K*K*L*L и время работы N

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

Библиотека с compile-time-regexp'ами. https://github.com/hanickadot/compile-time-regular-expressions #repo #github #cpp #regex #compiletime

можно написать имплементацию регулярок на шаблонах, магии или препроцессоре и построить в компайл-тайм или упаковка-билда-тайм или установка-сервиса-на-продакшен-тайм или когда угодно. Это вопрос имплементации

^

Библиотека с compile-time-regexp'ами. https://github.com/hanickadot/compile-time-regular-expressions #repo #github #cpp #regex #compiletime

какой же страх внутри

какой же страх внутри

auto regexp = "^([abc]+|xyz).+$"_pre;но снаружи красиво

auto regexp = "^([abc]+|xyz).+$"_pre;но снаружи красиво

да, снаружи красиво. не спорю ?

касательно regex - вот кстати хороший докладик на эту тему https://www.youtube.com/watch?v=N_rkHzhXueo&t=2s&index=62&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH

можно написать имплементацию регулярок на шаблонах, магии или препроцессоре и построить в компайл-тайм или упаковка-билда-тайм или установка-сервиса-на-продакшен-тайм или когда угодно. Это вопрос имплементации

https://apolukhin.github.io/papers/constexpr_regex.html

https://apolukhin.github.io/papers/constexpr_regex.html

да, знаем про этот пропозал ?

из того, что я нарыл - Boost.Regex версии 1.5X примерно соизмерим по перфомансу на каком-то кейсе с реализацией в libstdc++, но в 4 раза быстрее того, что тогда было написано в libc++. Почему так - надо разбираться

если регулярок, например, 1000, то время работы будет N * 1000, где N - длина текста. Если использовать хитрожопые алгоритмы, то время препроцессинга будет 1000 * 1000 (квадрат в алгоритме), а время работы в рунтайме N * 1, где N - длина текста

Hyperscan. Для 1000 регулярок ответ всегда один

Кто знает, почему std::from_chars для wchar_t не существует? ?

@antoshkka, или вообще хоть кто-нибудь, это я наркоман или буст? https://wandbox.org/permlink/zsIjeuy7ld80k4KA

@antoshkka, или вообще хоть кто-нибудь, это я наркоман или буст? https://wandbox.org/permlink/zsIjeuy7ld80k4KA

Так там не должно вроде матчиться?

ну как бы да, в std оно не матчится, std::smatch.empty() == true; std::smatch.size() == 0 в бусте boost::smatch.size() == 2; smatch[0] == smatch[1] == "" буст успешно взрывает мне мозг последние полчаса

Адругие версии boost?

потому что я на свою голову понадеялся на if (!match.empty()) и погряз в отладке

Адругие версии boost?

в проекте 1.55, эффект тот же самый

> Postconditions: If the function returns false, then the effect on parameter match is undefined лол, чо

в проекте 1.55, эффект тот же самый

Так это олдовый бустец, в boost asio, например, многое из boost 1.55 в boost 1.68 - deprecated.

> Postconditions: If the function returns false, then the effect on parameter match is undefined лол, чо

Норм вещь, чтобы не платить за то что не используешь - всё по правилам c++

Норм вещь, чтобы не платить за то что не используешь - всё по правилам c++

?

> Postconditions: If the function returns false, then the effect on parameter match is undefined лол, чо

+1

ну и для полноты коллекции, cppreference про ту же функцию > Returns true if a match exists, false otherwise. In either case, the object match is updated, as follows: > If the match does not exist: match.ready() == true; match.empty() == true; match.size() == 0

ну и для полноты коллекции, cppreference про ту же функцию > Returns true if a match exists, false otherwise. In either case, the object match is updated, as follows: > If the match does not exist: match.ready() == true; match.empty() == true; match.size() == 0

Ну видимо в комитете подумали и решили, что лучше очистить переменную все-таки

Чтобы не было вот такого вот как у тебя

Попробуйте закинуть это тикетом в Boost.Regex именно написав, что расходится поведение в std и boost тикет закидывать вот сюда: https://github.com/boostorg/regex

Попробуйте закинуть это тикетом в Boost.Regex именно написав, что расходится поведение в std и boost тикет закидывать вот сюда: https://github.com/boostorg/regex

уже сьехали с SVN Trac?

Закрыли его на добавление новых багов. Теперь только через github

Закрыли его на добавление новых багов. Теперь только через github

отличные новости. следующий на очереди - CMake'фикация

отличные новости. следующий на очереди - CMake'фикация

А сразу после этого - переписывание Boost на Rust

А сразу после этого - переписывание Boost на Rust

а зачем? и так всё работает как-то

у раста вон там своя экосистема растёт. им ни к чему)

а зачем? и так всё работает как-то

Для большей злобности

А сразу после этого - переписывание Boost на Rust

Мы не на столько хипстеры...

Попробуйте закинуть это тикетом в Boost.Regex именно написав, что расходится поведение в std и boost тикет закидывать вот сюда: https://github.com/boostorg/regex

https://github.com/boostorg/regex/issues/68 тыц

Есть кто работал с BLAS на С ?

На работе эрегировался такой вопрос: Дана структура. В структуре, посредством конструктора, инициализируются её поля. При первом прочтении эта конструкция выглядит как класс. Так, может лучше объявлять все структуры классами? Но тогда придётся заводить геттеры и сеттеры, и код разрастётся, казалось бы. Что делать? Как поступаете вы?

после эрегирования остается только фалломорфировать

На работе эрегировался такой вопрос: Дана структура. В структуре, посредством конструктора, инициализируются её поля. При первом прочтении эта конструкция выглядит как класс. Так, может лучше объявлять все структуры классами? Но тогда придётся заводить геттеры и сеттеры, и код разрастётся, казалось бы. Что делать? Как поступаете вы?

Юзаем структуру, если она символизирует хранение каких то данных и не имеет особого поведения В противном случае - класс

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

после эрегирования остается только фалломорфировать

Остаётся только кончать с данным вопросом.