Экспортированный класс C ++ означает, что клиенты DLL должны использовать тот же компилятор, что и DLL, из-за искажения имени и других проблем. На самом деле это довольно большая проблема, мне когда-то приходилось писать обертки C для нескольких классов C ++, потому что клиентские программы переключились на MSVC9, а сама DLL использовала MSVC71. [Были некоторые другие сложности с переключением DLL на MSVC90]. С тех пор я довольно скептически относился к этому бизнесу экспорта классов и предпочел написать обертку C для всего.
Теперь, если вы готовы заплатить цену за экспорт классов, я бы сказал, что экспорт статических данных не усугубляет проблему. Возможно, среди видов вещей, которые вы можете экспортировать, безопаснее всего экспортировать статические константы. Тем не менее, я бы предпочел не делать этого, потому что, как говорит Тимо, вы теперь заперты в этой реализации.
Одна из платформ, над которой я работал, требовала, чтобы ее клиенты предоставляли набор констант кода ошибки. Со временем мы обнаружили, что использование простой группы констант было слишком хрупким, и мы переключились на ОО-дизайн. У нас была реализация по умолчанию, которая возвращала бы общие коды ошибок, но к каждому из кодов ошибок обращались с помощью виртуальной функции, которая могла быть переопределена отдельными клиентами - и они использовали ее из некоторой расширенной обработки ошибок, специфичных для устройства. Это решение оказалось гораздо более масштабируемым, чем решение, основанное на экспорте констант.
Я бы посоветовал вам долго и усердно думать о том, как вы ожидаете развития компонента, прежде чем экспортировать статические переменные.