bmforce: если стоит задача как можно быстрее обработать большое кол-во таких строк, то как раз лучше регулярками не пользоваться и вариант Алексей Немиро будет самым быстрым из пока что предложенных
Damon_Shine: сделайте в своём проекте обертку, которая будет предоставлять вашей инфраструктуре удобный интерфейс для работы, сама обертка будет инкапсулировать вызовы к C++ сборке через механизм DLLImport, по моему, это вполне нормальный паттерн :)
Damon_Shine: подозреваю потому, что вы его создаете из vs и сам тип компонента подразумевает работу в среде выполнения .net. Так же, на сколько я знаю, C++ WinRT Component - это не классическая C++ сборка, она поддерживает XAML, поэтому вы не найдете в этом проекте объектов которые отвечают, например, за ресурсы - resource.h фалы и т.д. Кстати, даже с такими проектами не все гладко, например есть такая особенность - если вы в начале скомпилировали проект C++ WinRT Component, а потом пытаетесь его зарефать, то ничего не получится, нужно этот проект в начале заклинить, а только потом рефать, как-то так, если я ничего не напутал :)
Я не знаю, как ваше приложение устроено, но чтобы оптимизировать его и снизить нагрузку на GC, возможно, поможет в качестве элементов коллекции использовать value типы вместо reference, но важно чтобы у value типов не было "внутри" reference типов, иначе ваша коллекция все равно попадет в кучу.
Sergey Mozhaykin: действительно, просто финализатор не будет вызываться у объекта перед сборкой. И на сколько я знаю, мы не можем сами указать поколение у объекта, GC сам определяет поколения и алокацию в куче. Возможно изменение GCLatencyMode в Low поможет избежать сборки коллекции, но только, когда она уже будет во втором поколении и только если не будет недостатка памяти ... если я не прав, то буду рад, если меня поправят.
Алексей: dotMemoty очень хорош в этом плане. Что касается вашего вопроса - можно подавить финализацию у объекта (SuppressFinalize), тогда clr перестанет его коллектить.
