Если вот так распаковывать несколькими потоками в один пайп, то можно некоторые вхождения паттерна не найти. Дело в том, что распаковка происходит не построчно, а поблочно (как удобно декомпрессору). Поэтому декомпрессор может выдать начало паттерна в конце блока, затем другой процесс выдаст свой блок и первый процесс запишет хвост паттерна из второго блока. Таким образом паттерн будет разорван.
К сожалению, нет. В инкрементальной компиляции узкое место как раз диск. А если в проекте много шаблонов и компилируется в debug, то десяток гигабайт отладочной информации — обычное дело, а это огромное I/O.
Используйте самый последний clang из SVN. Clang очень быстро развивается, и кроме того, с момента релиза 3.1 многое изменилось.
По вопросу скорости — кажется у vim есть проблемы с обработкой длинного списка комплишенов… Сделал тест с 50000 результатами и задержка намного больше 2 секунд, хотя парсинг в холодном режиме (без PCH) занимает всего 0.4 секунды.
PVS-Studio нужен, но не для таких вещей, для которых просто реализовать диагностику в крмпиляторе (не всё, для чего можно в принципе реализовать проверку, может быть диагностикой в компиляторе — проверка обязательно должна быть быстрой). С другой стороны, в Clang есть статический анализатор и там можно реализовать всё остальное :)
Я считаю что пока это не обусловлено решением проблемы производительности, фабрика против non-type template parameter выглядит понятнее большинству программистов.
Прочитал дискуссию выше и предлагаю ещё одно решение: почему бы не передавать «код запроса» в конструктор, который сам найдёт строку регулярного выражения?
Компилятор мог ваших канареек вообще выкинуть если вы не обеспечили их «использование» и взятие адреса (без взятия адреса компилятор мог разместить её в регистре и только на время жизни «использования»). И мог переупорядочить порядок переменных в стеке.
По-моему лучше пользователю показать где именно точные результаты, а где неопределённость, чем выдать результат, а корректности которого судить никак нельзя.
Я не реализовывал, только статью читал. Вот результат GraphEq от авторов: www.habrastorage.com/images/aaa.png Много красного (точек, где нет уверенности).
И где вы будете брать «точки»? В середине, в левом нижнем/левом верхнем/… углу? И тогда пропустите все части графика, которые меньше ячейки сетки? Прочитайте статью из моего ответа, всё совсем не просто, но вполне реализуемо и пугать необходимостью решать такие системы как вы говорите не нужно.
К сожалению, используя Visual Studio можно изучить только Visual C++, а не C++ ISO/IEC 14882. VS ругается на все стандартные функции (printf, strcpy и так далее) независимо от контекста и корректности, предлагая заменить их на проприетарные расширения от Microsoft чтобы обеспечить vendor lock-in вашего кода.
