Является ли структура c ++ с std :: map хорошим дизайном, чтобы иметь динамический объект данных?

Вопрос сводится к следующему: это хороший дизайн - иметь структуру в c ++, которая содержит std::map типа std::map для динамического добавления информации / свойств к какому-либо объекту?

Объект (см. Фрагмент кода ниже) в моем случае - это FitResult возвращаемый различными оптимизаторами (оптимизирующими набор параметров модели, чтобы лучше всего описать данный набор данных).

FitResult содержит информацию, такую ​​как:

  • набор параметров, описывающих набор данных наилучшим образом
  • информация об ошибках по этим параметрам
  • информация о процессе оптимизации и конвергенции
  • так далее

На мой взгляд, этот объект FitResult является только данными и не нуждается в какой-либо функциональности. Следовательно, я бы сохранил структуру без функций. Поскольку информация, хранящаяся в объекте (как я перечислил выше), может варьироваться в зависимости от используемого оптимизатора, я хочу сохранить содержимое FitResult динамическим. И чтобы потом было проще получить доступ к информации, я решил использовать значение ключа, например, контейнер. Ключи карты не обязательно должны быть std::string , я думаю использовать вместо этого перечисления классов, чтобы избежать опечаток.

Считаете ли вы это хорошим выбором или вы пошли бы другим путем, например, базовым классом?

 struct FitResult { // these properties are separate members, since they are always given ParameterList InitialParameters; ParameterList FinalParameters; double InitialEstimatorValue = 0.0; double FinalEstimatorValue = 0.0; double ElapsedTimeInSeconds = 0.0; /// optional properties std::map<std::string, double> DoubleProperties; std::map<std::string, int> IntProperties; std::map<std::string, ParameterList> ParameterListProperties; std::map<std::string, std::vector<double>> DoubleListProperties; std::map<std::string, std::vector<std::vector<double>>> MatrixProperties; } 

Редактировать:

Мой вопрос был сформулирован не очень хорошо. Я должен был упомянуть, что в моем случае мне не нужна эта возможность динамического добавления свойств в FitResult . Просто разные классы Optimizer нуждаются в разных наборах свойств для добавления в FitResult . Свойства различаются для разных Optimizers , но остаются неизменными. Однако вместо использования наследования для добавления дополнительных полей- FitResult класс FitResult , я хотел использовать этот подход с динамической структурой. Какое из этих двух решений вы бы порекомендовали?

Всего 1 ответ


Я бы рассмотрел map string для variant<things you need> вместо контейнера для каждого поддерживаемого типа значения, но в основном да, это выглядит хорошо.


Есть идеи?

10000