Reimplementing constraint solver

[DeepSOIC]

A small update. The development slowed to a crawl. The main reason is I had trouble with establishing structures for placed geometry support.

I think I've come up with a reasonable solution, it's 2D version is being finished now.

I've opened issue tracker on the repo, to gather some things I postpone.

New year holidays are coming. I plan traveling. There will be little to no development in the coming three weeks.

[Kunda1]

Thanks for the update and heads-up. !

[triplus]

Trying to compile the branch i get the following error:

Code: Select all

src/Mod/ConstraintSolver/App/SubSystem.cpp:221:58: error: no matching function for call to ‘FCS::Subconstraint::Subconstraint(<brace-enclosed initializer list>)’
             _subconstraints.push_back(Subconstraint{c, ie});

In addition would it be possible to provide an example code snippet to test:

Base classes for geometry and constraints are up, with just one concrete geometric thing and one constraint implemented (point and distance). This should be enough for initial experiments on solver.

Thanks.

[wmayer]

Looks like you need to use C++14

Example 1:

Code: Select all

#include <vector>

struct test {
  int a;
  int b;
};

int main()
{
  std::vector<test> vec;
  vec.push_back(test{1,2});
}

gcc init.cpp -std=c++11 -lstdc++ => works


Example 2:

Code: Select all

#include <vector>

struct test {
  int a;
  int b = -1; // a member is already initialized in the class declaration
};

int main()
{
  std::vector<test> vec;
  vec.push_back(test{1,2});
}

gcc init.cpp -std=c++11 -lstdc++ =>

init.cpp: In function ‘int main()’:
init.cpp:11:25: error: no matching function for call to ‘test::test(<brace-enclosed initializer list>)’
vec.push_back(test{1,2});
^
init.cpp:3:8: note: candidate: test::test()
struct test {
^~~~
init.cpp:3:8: note: candidate expects 0 arguments, 2 provided
init.cpp:3:8: note: candidate: constexpr test::test(const test&)
init.cpp:3:8: note: candidate expects 1 argument, 2 provided
init.cpp:3:8: note: candidate: constexpr test::test(test&&)
init.cpp:3:8: note: candidate expects 1 argument, 2 provided

gcc init.cpp -std=c++14 -lstdc++ => works

[triplus]

Looks like you need to use C++14

Thanks for the info.

P.S. Will wait a bit to see if @DeepSOIC will still be prepared to support C++11 (Ubuntu 16.04). For me personally this is not a huge problem, could update the toolchain or migrate to Ubuntu 20.04. But generally speaking maybe supporting C++11 still makes some sense? That is talking from the next FreeCAD version (that will come after the FreeCAD 0.19 release) point of view.

[DeepSOIC]

In addition would it be possible to provide an example code snippet to test:

see src/Mod/ConstraintSolver/examples for a starting point. Though they might not work right now...

[DeepSOIC]

Looks like you need to use C++14

... But generally speaking maybe supporting C++11 still makes some sense?

I didn't know I am using c++14 features. I aimed for c++11. I guess my toolchain supports c++14, which made me use some c++14 features by accident.

[wmayer]

I didn't know I am using c++14 features. I aimed for c++11. I guess my toolchain supports c++14, which made me use some c++14 features by accident.

git commit 0b2b1e3a536 now prints which C++ standard is being used. When configuring with CMake you should see it in the output window.

With the CMake macro https://github.com/FreeCAD/FreeCAD/blob ... tups.cmake we can choose the C++ standard from a combo box but obviously the value is only set for the clang or gcc compiler and is ignored for MSVC.

But am not sure if by forcing it to C++11 the compiler will abort for C++14 (or later) code because often compiler extensions are used automatically.

[triplus]

Good to see all the progress and to hear supporting C++11 is still on the plan. No hurry, but will wait for the C++11 fix to land. After i will try to compile again and test the examples.

[DeepSOIC]

I am now seriously considering shifting the focus to 3d sketching.