Прямо очень

Но когда программа много работает, вполне возможно

Привет, я не знаю, в тот ли я чат пишу, но есть вопрос по поводу того, как сделать задачу.
Задача состоит в том, чтобы определить, как лучше реализовать изменение настроек объекта,
что должен быть на сервере.

   Пока не было сетевой версии, происходило так, что создавалась копия (заметил, что довольно большая по размеру), проводились модификации копии,
После этого происходила перезапись настроек. В случае передачи по сети нет смысла
передавать все настройки.

Каким образом можно сделать изменение настроек?

Можно сделать битфилд, где каждой настройке будет соответствовать свой бит. Сначала писать в стрим этот битфилд где только измененным полям бит будет поднят, потом писать все настройки которые изменились в определенном порядке.
При получении считывать битфилд и потом те поля которые изменились считывать в этом же порядке как вы их паковали.

Ну это так, то что в голову пришло, возможно что-то лучше есть

настройка - например, число или строка
каким образом я узнаю, что изменилась какая-то определённая настройка?
(хотелось бы избежать копирования настроек в самом начале)

А у вас настройки как json задаются, то есть все что угодно в любом порядке может быть? или плюсовым кодом srtuct/class где настройки имеют конкретный тип?

Или что-то между?

что-то между

Хм, ну тогда сложнее да. Просто если бы плюсовым кодом, как я сначала подумал, то тип был бы и так ясен, нужно было бы только вызывать правильную десериализацию для типа.
А так надо смотреть как у вас они хранятся (и какие состояния могут принимать)

А на счёт копирования, если это какое-нибудь exception safety, то копирования наверно особенно не избежать.

Но по сети все равно стоит передавать только то что изменено.

PrjSets sets = prjSettings();
if (fmSettings->exec(&sets) {
   auto cmd = std::make_unique<CmdSetSettings>(sets, mod);
   cmd->exec();
}

FmSettings:exec(PrjtSets *aSets)
{
  copyFrom(aSets);
  ...
  QDialog::exec();
  ...
  copyTo(aSets);
}


void CmdSetSettings::exec() {
   ...
   aHolder.project().sets = std::move(sets);
   ...
}
struct PrjSets {
  ...
  std::array<bool, N> a;
  std::vector<bool> b;
  std::vector<bool> c;
  std::wstring d;
  ...
}

Спасибо за ответ

То есть вот эти массивы/вектора + строка в PrjSets это как раз те настройки изменения которых надо передать по сети?

ну, грубо говоря да
но там намного больше полей, это часть

Сейчас будет что-то из головы, не воспринимайте как окончательное решение, но может чем-то поможет.

Если брать общий случай, что все что угодно может поменяться, то можно сделать так же битсет по биту на каждый массив. И сначала писать его.

Потом в сериализации каждого изменённого массива разбивать его на чанки одинакового размера (например по 256 элементов), писать в стрим размер массива, потом писать битсет по чанкам, которые изменились, потом писать сами изменённые чанки. То есть размер массива как раз будет о сути задавать размер того что надо будет вычитать из стрима на той стороне.

Если размер не меняется никогда, то можно и его не отправлять.


Если меняется от силы 2-3 значения за раз, то можно организовать что-то типа паттерна "команда". Иметь объекты из разряда "изменить значение в таком-то массиве в такой-то позиции на такое-то", "удалить значение в позиции такой-то", добавить такое-то значение в такую-то позицию", сериализовявать и отправлять только эти команды. Но я бы тогда на всякий случай подумал бы про какие-нибудь контрольные суммы чтобы если будет косяк в этой логике то можно было бы об этом узнать (и может даже как-то отреагировать, например запросить переслать целиком все настройки).

кластеризация

Понятно что кластеризация :)

на самом деле, я использовал в итоге DBSCAN. Если вкратце, другим алгоритмом по заданным параметрам, создается куча точек на 2d поверхности - конечная цель - выделить места, где условно на участке в 50 пикселей, сконцентировано более 100 точек. DBSCAN очень хорошо показал себя, и результат в общем достигнут :)