Насчет уровня косвенности — спорно. В вашей реализации — вызов ф-ции по указателю (manage) + switch. Вызов виртуальной ф-ции = вызов ф-ции по указателю на указатель. Не думаю, что можно без замеров утверждать что будет быстрее в реальной жизни.
Не вижу, откуда взяться дополнительным аллокациям. Размер объекта без полей, реализующего виртуальный интерфейс, равен (surprise!) размеру manager_t. Размещающий new позволит отлично обойтись без доп. аллокаций.
1. Не увидел упоминания memory alignment. Если этот аспект пропущен, то можно неожиданно получить серьезный удар по производительности.
2. Какие преимущества использования набора указателей на ф-ции (manager_t) перед виртуальными классами? На мой взгляд, именно для этого классы идеально и подходят.
И прямо из сети попало в функцию, копирующую файл? Тоже до свидания. Это слишком тупой троллинг, как без необходимости спрашивать — а у вас double в стандарте IEEE 754?
Не все. Например, порядок байтов в строке в памяти колебать программиста не должен. Внимательный интервьюер на этом вопросе может сказать «Попался, тролль! Давай, до свидания».
Модули — это 10%. Без стандартизации ABI в этом направлении далеко не уйти. Под Linux безумная морока с разными версиями stdc++ в разных дистрибутивах. Это не говоря про все прочие бинарные зависимости.
Зато теперь мы знаем, что автор статьи консультант и знает много модных баззвордов — IoT, HFT, FPGA, VHDL…
Ну а то, что C++ настолько долго компилируется, что проще ПЛИС на коленке запрограммировать, мы и так догадывались.
Прогеров — да. Менеджеров и архитекторов, которые смогут выпустить коммерческий продукт, и не надо — демонстрировать Путину и показывать по ТВ можно и вечную бессмысленную бету.
В качестве черного ящика «на входе SVG, на выходе растр», имхо, вполне можно использовать Qt SVG.
SVG++ нацеливалась на тех, кого не устраивает черный ящик или есть особые требования по памяти/производительности.
Например, в программе уже используется Skia/Cairo/GDI+/AGG/etc в качестве движка и хочется рендерить SVG именно с помощью того же самого. В этом случае мало поможет то, что я допилил реализацию для одного движка.
Чтобы с помощью фильтров делать интересные эффекты (хотя бы как сэмплы в SVG Spec), нужно довольно большое их число реализовать. Одним blur не обойтись.
Демо-приложение умеет рисовать градиенты (по крайней мере, с AGG). Здесь можно скачать (регистрация открытая) SVG Test Suite рендеренный с помощью демо, чтобы примерно представлять реализованнные в демо фичи. Тени в демо не сделаны.
Но нужно понимать мотивацию при создании компонент — библиотека SVG++ умеет читать всё, а демо показывает как этим пользоваться, включая реализацию сложных функций. Но, например, полная реализации фильтров раздула бы демо-приложение кучей довольно тривиального кода.
Если качественно реализован разбор C++ кода со всеми Microsoft-specific вещами, пришедшими из глубины веков, плюс хорошая интеграция со студийными проектами и IDE, то вполне можно пока сосредоточиться на VS. На месте недорогих fixed price решений статического анализа пока зияющая пустота.
Насчет уровня косвенности — спорно. В вашей реализации — вызов ф-ции по указателю (manage) + switch. Вызов виртуальной ф-ции = вызов ф-ции по указателю на указатель. Не думаю, что можно без замеров утверждать что будет быстрее в реальной жизни.
Не вижу, откуда взяться дополнительным аллокациям. Размер объекта без полей, реализующего виртуальный интерфейс, равен (surprise!) размеру manager_t. Размещающий new позволит отлично обойтись без доп. аллокаций.
2. Какие преимущества использования набора указателей на ф-ции (manager_t) перед виртуальными классами? На мой взгляд, именно для этого классы идеально и подходят.
Не все. Например, порядок байтов в строке в памяти колебать программиста не должен. Внимательный интервьюер на этом вопросе может сказать «Попался, тролль! Давай, до свидания».
Ну а то, что C++ настолько долго компилируется, что проще ПЛИС на коленке запрограммировать, мы и так догадывались.
Дальше сами...
SVG++ нацеливалась на тех, кого не устраивает черный ящик или есть особые требования по памяти/производительности.
Например, в программе уже используется Skia/Cairo/GDI+/AGG/etc в качестве движка и хочется рендерить SVG именно с помощью того же самого. В этом случае мало поможет то, что я допилил реализацию для одного движка.
Чтобы с помощью фильтров делать интересные эффекты (хотя бы как сэмплы в SVG Spec), нужно довольно большое их число реализовать. Одним blur не обойтись.
Но нужно понимать мотивацию при создании компонент — библиотека SVG++ умеет читать всё, а демо показывает как этим пользоваться, включая реализацию сложных функций. Но, например, полная реализации фильтров раздула бы демо-приложение кучей довольно тривиального кода.