У них выше покрытие фич стандарта.

vcpkg install boost-bind:x64-windows-static Error: database corrupted. Package boost-algorithm:x64-windows-static is installed but dependency boost-bind:x64-windows-static is not.

Хз что делать

снести boost-algorithm:x64-windows-static

битый пакет снеси, обнови потом, я так всегда делаю ? на любом пакетном менеджере

Снести как? Из файловой системы? Можно списком?

Они друг за другом цепляются, все по очереди что ли сносить вручную?

(n+1)*sizeof(WCHAR)?

Может небольшой оффтопик

Знаете чатики по java?

Конкретно, нужен профи по hibernate

Знаете чатики по java?

Тут, собственно я вас тут тоже нашол https://netology.ru/blog/prg-tg

Огромное спс

Думаю найду

@jvmchat

Они друг за другом цепляются, все по очереди что ли сносить вручную?

я уже не помню vcpkg, сначала я бы попробывал сделать vcpkg remove имя_сломаного_пакета если не помогло в директории vcpkg должны быть папки пакетов и конфиги пакетов, я бы их поправил/удалил лишнее, что конфликтует

Конкретно, нужен профи по hibernate

SQL.ru..

теперь тут есть hrы

SQL.ru..

Понял спс

Всем привет! кто может кинуть в меня ссылкой на хороший мануал как с помощью какого-либо debugging tool выяснить причины crash приложения (хотя бы post-mortem имея его dump)? приложение загружает .dll, в которой при определённых условиях валится AV. приложение - не моё (1С; отладочных символов нет), dll - тоже не моя (но отладочные символы есть - CEF). читал "серию" из https://www.codeproject.com/Articles/707488/Part-1-Windows-Debugging-Techniques-Debugging-Appl, но там нет хождения по стеку вызовов, передаваемым значениям, etc... пока только выяснил имя метода в котором падает.. но хочется отладку как в IDE )) ну или хотя бы значения, которые прилетают в методы и провоцируют AV

Всем привет! кто может кинуть в меня ссылкой на хороший мануал как с помощью какого-либо debugging tool выяснить причины crash приложения (хотя бы post-mortem имея его dump)? приложение загружает .dll, в которой при определённых условиях валится AV. приложение - не моё (1С; отладочных символов нет), dll - тоже не моя (но отладочные символы есть - CEF). читал "серию" из https://www.codeproject.com/Articles/707488/Part-1-Windows-Debugging-Techniques-Debugging-Appl, но там нет хождения по стеку вызовов, передаваемым значениям, etc... пока только выяснил имя метода в котором падает.. но хочется отладку как в IDE )) ну или хотя бы значения, которые прилетают в методы и провоцируют AV

Без отладочных символов бесполезно приложение отлаживать.

Всем привет! кто может кинуть в меня ссылкой на хороший мануал как с помощью какого-либо debugging tool выяснить причины crash приложения (хотя бы post-mortem имея его dump)? приложение загружает .dll, в которой при определённых условиях валится AV. приложение - не моё (1С; отладочных символов нет), dll - тоже не моя (но отладочные символы есть - CEF). читал "серию" из https://www.codeproject.com/Articles/707488/Part-1-Windows-Debugging-Techniques-Debugging-Appl, но там нет хождения по стеку вызовов, передаваемым значениям, etc... пока только выяснил имя метода в котором падает.. но хочется отладку как в IDE )) ну или хотя бы значения, которые прилетают в методы и провоцируют AV

Платформа какая ?

Без отладочных символов бесполезно приложение отлаживать.

ну вот как раз отладочные символы DLL-ки в которой происходит AV - есть платформа - Win32 (Windows 7)

Ну поставь WinDbg какойнибудь, и под ним запусти. Или cdb. "Запустить под ним" можно и так: запустить приложение с DLL но ничего не делать. Пойти в отладчик, и приконнектиться (attach) к уже запущенному процессу. Так обычно проще.

Потом надо инициировать эту ошибочную ситуацию. В отладчике ты получишь стек, в котором часть будет светиться в виде фукнций (от твоей .DLL). Ну и может можно будет посмотреть на какие-то переменные. В остальных случаях -- только на память и регистры

в Boost.Regex есть какое-нибудь изкоробочное решение для "натравить на текст N регулярок, в каждой по одной capture group; получить 0 или 1 совпадение; запомнить какая регулярка сработала" ?

в Boost.Regex есть какое-нибудь изкоробочное решение для "натравить на текст N регулярок, в каждой по одной capture group; получить 0 или 1 совпадение; запомнить какая регулярка сработала" ?

Я даже не понял, о чём это ты.

в Boost.Regex есть какое-нибудь изкоробочное решение для "натравить на текст N регулярок, в каждой по одной capture group; получить 0 или 1 совпадение; запомнить какая регулярка сработала" ?

Натрави сам последовательно, в чём проблема?

в Boost.Regex есть какое-нибудь изкоробочное решение для "натравить на текст N регулярок, в каждой по одной capture group; получить 0 или 1 совпадение; запомнить какая регулярка сработала" ?

И , напоминаю, что regex уже в стандарте

Натрави сам последовательно, в чём проблема?

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

Ну и можно устроить trade-off, если препроцессинг слишком уж долго будет

Я даже не понял, о чём это ты.

есть строка вида 123-xxx, или xxx/123, или 123, хочу вытащить из неё 123, но не очень хочу делать regex_match(text, result1, reg1) || regex_match(text, result2, reg2) || ..., вдруг что-то подобное уже есть и я его просто пока не нашёл, + какие-нибудь смерживания кучи регулярок в одну для убыстрения процесса

есть строка вида 123-xxx, или xxx/123, или 123, хочу вытащить из неё 123, но не очень хочу делать regex_match(text, result1, reg1) || regex_match(text, result2, reg2) || ..., вдруг что-то подобное уже есть и я его просто пока не нашёл, + какие-нибудь смерживания кучи регулярок в одну для убыстрения процесса

Кроме написания регулярок с альтернативами, нет, не думаю, что что -то есть.

Можно ли тут написать альтернативы, я не знаю.

И , напоминаю, что regex уже в стандарте

вроде бы же на него все обплевались какой он дико тормозной?

вроде бы же на него все обплевались какой он дико тормозной?

А Boost.Regex лучше по скорости?

вроде бы же на него все обплевались какой он дико тормозной?

Так он тот же самый.

что-то мне казалось, что они примерно идентичны

только вот Boost.Regex ещё и падуч до кучи

А Boost.Regex лучше по скорости?

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

Но я естественно не в курсе, что каждая из реализаций компилятора использует. Мне казалось, что самый простой вариант для реализации -- взять готовое из BOOST.

Алгоритма "объедене мне кучу регулярок, чтобы по строке они суммарно прошли конст раз" ещё нет

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

не, это галлюцинация. Если мы говорим про действительно быстрые регулярки, то тут в помощь вот это: https://github.com/yandex/pire https://github.com/google/re2

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

Видимо, галлюцинации. Я вот сталкивался с тем, что в GCC в одно время заголовки RegEx поставлялись и включались ОК, но после приложение не линковалось, посколько эта либа не header only, но в GCC ещё не поставлялась сама эта либа.

не, это галлюцинация. Если мы говорим про действительно быстрые регулярки, то тут в помощь вот это: https://github.com/yandex/pire https://github.com/google/re2

спасибо, учту на будущее

вроде бы же на него все обплевались какой он дико тормозной?

А сколько текста тебе надо разобрать? Мне кажется, для разбора строки 123-abc любого будет достаточно

А сколько текста тебе надо разобрать? Мне кажется, для разбора строки 123-abc любого будет достаточно

так-то да, просто проект едва-едва выполз в 11 стандарт на позапрошлой неделе, и насквозь пропитан бустом - в том числе и регулярками как-то пока не хочется массово менять boost:: на std:: и шило на мыло)

Алгоритма "объедене мне кучу регулярок, чтобы по строке они суммарно прошли конст раз" ещё нет

Есть. регулярка (a | b) будет работать быстрее чем (регулярка(а) или регулярка(b)) первая работает за линюю, вторая тоже работает за линию (но дважды). Первая препроцесится дольше второй

Если у тебя будет N раз |

То будет также за линию от длины строки?

ДА

Чего...

Есть. регулярка (a | b) будет работать быстрее чем (регулярка(а) или регулярка(b)) первая работает за линюю, вторая тоже работает за линию (но дважды). Первая препроцесится дольше второй

речь же про то, что если уже есть "скомпилированные" регулярка(а) и регулярка(b) то их нельзя смержить в регулярка(a|b), или я не понял?

просто регулярка будет чудовищного размера и очень долго строиться дерево разбора

Есть. регулярка (a | b) будет работать быстрее чем (регулярка(а) или регулярка(b)) первая работает за линюю, вторая тоже работает за линию (но дважды). Первая препроцесится дольше второй

Ну, совсем не факт, что производительность матча одной регулярки не будет хуже другой в те же 2-3 раза (кол-во подвыражений)

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

Стандартная либа из os x

Есть. регулярка (a | b) будет работать быстрее чем (регулярка(а) или регулярка(b)) первая работает за линюю, вторая тоже работает за линию (но дважды). Первая препроцесится дольше второй

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