Как Вы организуете свои заголовки STL?
Я думаю, что ваши фильтры не совсем верны.
Выражение фильтра должно быть:
"expression": "SourceContext = 'Microsoft' or StartsWith(SourceContext, 'Microsoft.')"
(я думаю, вы могли бы просто сделать StartsWith(SourceContext, 'Microsoft') без последней точки, но тогда это может не работать должным образом для пространств имен, подобных MicrosoftOrIsItReally.MyNamespace)
(внутренне Matching.ForSource выполняет фильтрацию SourceContext.StartsWith(..), как показано в источнике )
Чтобы подтвердить это, вы можете отредактировать outputTemplate ] вашего приемника файлов, чтобы отобразить свойство SourceContext и увидеть происхождение событий журнала. (по умолчанию установлено значение "{Timestamp:yyyy-MM-dd HH:mm:ss.fff zzz} [{Level:u3}] {Message:lj}{NewLine}{Exception}"). Вы можете изменить его на "{Timestamp:yyyy-MM-dd HH:mm:ss.fff zzz} [{Level:u3}]<{SourceContext}> {Message:lj}{NewLine}{Exception}", чтобы включить свойство SourceContext.
Кстати, у вас есть лишняя, ненужная директива "Using". "Serilog.Settings.Configuration" не является необходимым
4 ответа
Я только включаю заголовочные файлы, которые действительно необходимы в каждом источнике, и не 'ловят все' заголовки, для хранения зависимостей (и следовательно время компиляции) как низко как возможных.
Предварительно скомпилированные заголовки могут работать независимо от этого (т.е. Я полагаюсь на предварительно скомпилированные заголовки, чтобы ускорить процесс компиляции, не получить объявления). Таким образом, даже если что-то объявляется через включенные предварительно скомпилированные заголовки, я все еще включаю 'обычный' заголовок, который будет пропущен включать защитным механизмом и не добавит ничего значительного ко времени компиляции.
Поскольку предварительно скомпилированные заголовки являются компилятором определенная вещь. При оптимизации / изменение предварительно скомпилированных заголовков не должно иметь никакого эффекта на корректное функционирование кода, по-моему.
Основное преимущество наличия зависимостей максимально низко состоит в том, что рефакторинг становится легче (или скорее: выполнимый)
Замечательная книга по всему этому является Крупным масштабом Дизайн C++ от Lakos
То, что я делаю, включают все заголовки STL, в которых я испытываю необходимость во всем проекте в моем единственном предварительно скомпилированном заголовке, обычно StdAfx.h по умолчанию. Предварительно скомпилированный заголовок является фактической первой вещью настроить в проекте, включая все STL-/boost-/platform заголовки и сторонние библиотеки.
STL и повышение аккуратно расположены в пространствах имен, таким образом, они никогда не вызывают путаницы, или накладывается также.
В заголовках я обычно использую полные имена, но в исходных файлах делают пространство имен x использования в надлежащих случаях.
Можно объединить эти два метода:
Имейте и .cpp - файлы включают и также добавляют его к stdafx.h. Это все еще даст Вам оптимизацию PCH.
.cpp - файлу все еще нужно к #include "stdafx.h", таким образом, его независимость спорна. Однако зависимость является состоянием explicitely, и удаление stdafx.h включает, более просто, чем нахождение, что все отсутствие включает. Кроме того, стандартные заголовки - как все заголовки должны - удостоверяться, что они не включены дважды.
Обычно я соглашаюсь с Вашим подходом сделать каждый файл "независимым", т.е. когда .cpp добавляется к другому проекту, или.h включен, он заботится о своих зависимостях.
Помните, что PCH является компромиссом, они могут стать огромными. Необходимость к большому количеству главным образом неиспользованного кода в PCH может на самом деле замедлить Ваши сборки. Быстрые диски помогают много, хотя :)
Также знайте, то включение предварительно скомпилировало заголовки в MSVC, по крайней мере, в некоторых версиях, на самом деле изменяет обработку: объявления перед #include "stdafx.h" проигнорированы, таким образом, это должно быть Вашим первым положением некомментария. Ужасная ловушка.
Полностью согласуйте с предложением для книги John Lakos Крупный масштаб Дизайн C++.
Объявите все заголовки, необходимые для файла, или.h или .cpp, в самом файле. Не полагайтесь на побочные эффекты файлов, включенных другими заголовочными файлами.
Наличие большого заголовочного файла, перечисляющего все, включает зависимости от увеличений излишне и делает дизайн очень хрупким.
О, еще одна вещь никогда не имеют объявления использования в заголовочном файле. Только когда-либо используйте их в своих файлах реализации, .cpp файлы.
HTH.
удачи,
Ограбить