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

Вопрос сводится к следующему: хорошо ли иметь структуру в c ++, которая содержит несколько 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;
}

Edit:

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

1 Ответ

3 голосов
/ 16 мая 2019

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

...