Обнаружилось то, о чём я совершенно забыл. В js реализации planegcs автор специально сериализовал все примитивы и ограничения. Таким образом в солвер подавался только этот набор.
Что у нас?
В текущей кодовой реализации солвер хранится как объект класса Canvas. Хорошо - скажете Вы. И это будет правдой. Но до тех пор пока мы не узнаём, что координаты привязаны к списку параметров. И вот например мы хотим сделать что-то такое:
Казалось бы - гуляй да радуйся - тем более radius теперь в списке параметров.
Но не тут то было...
Посмотрим на реализацию addConstraintCircleRadius в GCS.cpp:
Как Вы можете увидеть - внутри этого ограничения - другое ограничение. Это нормально. Интересно тут другое. Я не знаю с чем это связано, но по какой-то неведомой мне причине addConstraintEqual работает не как c.rad = radius, а как radius = c.rad. То есть при попытке сменить radius нас обратно тянет к c.rad.
Что делать?
Пока что не слишком много идей. Есть два основных варианта:
Пересадка на SolveSpace
Это наиболее древний экземпляр, но старичок всё ещё живой. Из его плюсов - для него есть нормальная документация и примеры (!!). Из минусов - код всё-таки там запутанный и непонятно как вообще собрать там либу без makefile.
Создать отдельный массив для хранения размерных ограничений
В нанокаде я подсмотрел, что размерные ограничения там хранятся в отдельном менеджере. Можно что-то проделать и у нас. Таким образом мы не потеряем данные, и радиус окружности будет изменяться под воздействием radius.
P.S. Возможно стоит ещё оптимизировать немного код, хотя скорее я выделю это в отдельную задачу.
# Плохие вести, коллеги
Обнаружилось то, о чём я совершенно забыл. В js реализации planegcs автор специально сериализовал все примитивы и ограничения. Таким образом в солвер подавался только этот набор.
# Что у нас?
В текущей кодовой реализации солвер хранится как объект класса Canvas. Хорошо - скажете Вы. И это будет правдой. Но до тех пор пока мы не узнаём, что координаты привязаны к списку параметров. И вот например мы хотим сделать что-то такое:
```cpp
sys.addConstraintCircleRadius(circle, radius);
p_parameters.push_back(radius);
```
Казалось бы - гуляй да радуйся - тем более radius теперь в списке параметров.
Но не тут то было...
Посмотрим на реализацию addConstraintCircleRadius в GCS.cpp:
```cpp
int System::addConstraintCircleRadius(Circle& c, double* radius, int tagId, bool driving)
{
return addConstraintEqual(c.rad, radius, tagId, driving);
}
```
Как Вы можете увидеть - внутри этого ограничения - другое ограничение. Это нормально. Интересно тут другое. Я не знаю с чем это связано, но по какой-то неведомой мне причине addConstraintEqual работает не как c.rad = radius, а как radius = c.rad. То есть при попытке сменить radius нас обратно тянет к c.rad.
# Что делать?
Пока что не слишком много идей. Есть два основных варианта:
1) Пересадка на SolveSpace
Это наиболее древний экземпляр, но старичок всё ещё живой. Из его плюсов - для него есть нормальная документация и примеры (!!). Из минусов - код всё-таки там запутанный и непонятно как вообще собрать там либу без makefile.
2) Создать отдельный массив для хранения размерных ограничений
В нанокаде я подсмотрел, что размерные ограничения там хранятся в отдельном менеджере. Можно что-то проделать и у нас. Таким образом мы не потеряем данные, и радиус окружности будет изменяться под воздействием radius.
P.S. Возможно стоит ещё оптимизировать немного код, хотя скорее я выделю это в отдельную задачу.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Плохие вести, коллеги
Обнаружилось то, о чём я совершенно забыл. В js реализации planegcs автор специально сериализовал все примитивы и ограничения. Таким образом в солвер подавался только этот набор.
Что у нас?
В текущей кодовой реализации солвер хранится как объект класса Canvas. Хорошо - скажете Вы. И это будет правдой. Но до тех пор пока мы не узнаём, что координаты привязаны к списку параметров. И вот например мы хотим сделать что-то такое:
Казалось бы - гуляй да радуйся - тем более radius теперь в списке параметров.
Но не тут то было...
Посмотрим на реализацию addConstraintCircleRadius в GCS.cpp:
Как Вы можете увидеть - внутри этого ограничения - другое ограничение. Это нормально. Интересно тут другое. Я не знаю с чем это связано, но по какой-то неведомой мне причине addConstraintEqual работает не как c.rad = radius, а как radius = c.rad. То есть при попытке сменить radius нас обратно тянет к c.rad.
Что делать?
Пока что не слишком много идей. Есть два основных варианта:
Это наиболее древний экземпляр, но старичок всё ещё живой. Из его плюсов - для него есть нормальная документация и примеры (!!). Из минусов - код всё-таки там запутанный и непонятно как вообще собрать там либу без makefile.
В нанокаде я подсмотрел, что размерные ограничения там хранятся в отдельном менеджере. Можно что-то проделать и у нас. Таким образом мы не потеряем данные, и радиус окружности будет изменяться под воздействием radius.
P.S. Возможно стоит ещё оптимизировать немного код, хотя скорее я выделю это в отдельную задачу.
Я тут так подумал - наверное стоит создать отдельный массив
Но в целом я готов переписать под SolveSpace