Replace boost with C++11 in generated code

[rfranke]

Recently the Cpp runtime compiles with -std=c++11. Gcc5 will make this the default. This makes it possible to replace many boost features with their new std equivalents. In fact the related work has already started (see #3322).

The question is if not boost can be completely removed from generated code. It should be restricted to cases where it is really beneficial (gcc 4.4, advanced solvers, ...).

A simple FMU for model exchange exported with an up-to-date compiler and basically using external solvers should not rely on boost.

[rfranke]

As a starting point, a6932e46ddd6e075aa15ac49186aa3518801ea68/OMCompiler removes the remaining use of boost::multi_array.

Moreover e7c2e15d60350471e7de62af904090117d21a310/OMCompiler (and the subsequent small fix) separate static solver factories from the creation of a simulator. This drastically reduces the size of exported FMUs and dependencies like boost::program_options disappear.

@mwalther: I also removed the two now obsolete libs OMCppOMCFactory_FMU_static and OMCppSimController_FMU_static from the respective CMakeLists.txt and the gcc build. Can you please check if the msvc build still works?

[niklwors]

The fmu test for CoupledClutches is broken
It starts with this errors:

OMCppCoupledClutchesAlgLoopMain.cpp
OMCppCoupledClutches.cpp(6) : error C2653: 'CoupledClutches' : is not a class or namespace name
OMCppCoupledClutches.cpp(6) : error C2065: 'IGlobalSettings' : undeclared identifier
OMCppCoupledClutches.cpp(6) : error C2065: 'globalSettings' : undeclared identifier
OMCppCoupledClutches.cpp(6) : error C2065: 'shared_ptr' : undeclared identifier
OMCppCoupledClutches.cpp(6) : error C2065: 'IAlgLoopSolverFactory' : undeclared identifier
OMCppCoupledClutches.cpp(6) : error C2065: 'nonlinsolverfactory' : undeclared identifier
OMCppCoupledClutches.cpp(6) : error C2065: 'shared_ptr' : undeclared identifier
OMCppCoupledClutches.cpp(6) : error C2065: 'ISimData' : undeclared identifier
OMCppCoupledClutches.cpp(6) : error C2065: 'sim_data' : undeclared identifier
OMCppCoupledClutches.cpp(6) : error C2065: 'shared_ptr' : undeclared identifier

....

[rfranke]

This looks strange -- the first message basically says that OMCppCoupledClutches.cpp is included before OMCppCoupledClutches.h, where the class CoupledClutches is defined!?

The FMU compiled under Linux. It is currently excluded from the regression tests -- I think because the simulation produces wrong results. Other FMUs compile and simulate as before. Can this be an msvc issue?

[niklwors]

yes, the problem is with the msvc compiler. Maybe the problem was before your changes.
I noticed you changed the StaticOMCFactory, but i already removed this class because it is not needed anymore.

[rfranke]

Well, StaticOMCFactory is used for statically linked simulators (see CodegenCpp.tpl, lines 2563ff.):

#ifdef RUNTIME_STATIC_LINKING
  shared_ptr<StaticOMCFactory>  _factory =  shared_ptr<StaticOMCFactory>(new StaticOMCFactory());
#else
  shared_ptr<OMCFactory>  _factory =  shared_ptr<OMCFactory>(new OMCFactory());
#endif //RUNTIME_STATIC_LINKING

It modifies loadSimControllerLib to skip the use of boost::factory and assume static linking instead. The problem was that StaticOMCFactory, as well as OMCFactory serve for two purposes: the creation of a simulator through createSimulation and the loading of a solver through LoadLibrary. FMUs only need an alg loop solver and a dummy LoadLibrary -- The latter was provided by StaticOMCFactory that at the same time provided the whole functionality of the simulation runtime.

I shifted the LoadLibrary into a separate BasicOMCFactory to get rid of the whole simulation runtime in FMUs.

[niklwors]

I also removed the ifdef part in the cpp template, because the static object creation is handeld in the policy classes. I can checked that when i have time for it.

[rfranke]

This sounds good. Having specific static policy classes, the dummy LoadLibrary should disappear as well from static code.

[rfranke]

Since yesterday the size of a simple FMU binary has reduced from 12 to 4 MB!!!

The dependencies have been reduced. b2c8ddd11fb28937db0c813073673e643165aa39/OMCompiler removes the libs boost_filesystem and boost_program_options from the FMU build -- only boost_system is left.

[rfranke]

It turns out that any compilation unit that includes boost/filesystem gets a link dependency on boost_system. This makes it not really suited for a commonly used interface. This is why 8beab334fc6de8f41eb47470f0c09ca9526874c5/OMCompiler replaces boost::filesystem::path in the OMC factory interfaces with std::string.

This makes it possible to export FMUs without any boost dependency. The remaining uses of boost appear to be inlined.

Btw. only SIMSTER_BUILD still defines PATH as fs::path.
If this was changed to std::string, like in any other factory, then the conditional PATH definition could be completely replaced with string everywhere.

Who could do that in SIMSTER_BUILD?

[niklwors]

I want that we use boost filesystem path, because it takes care handling file paths for different oprating systems. We should find a other work arround that the fmu export is not using the boost filesystem lib.

[niklwors]

We can add a build type for the fmu export. In the FactoryConfig file there is already a define for the used Path type. For the fmu export you can use string for PATH and we only include boost filesystem for the other build types.

[rfranke]

Boost filesystem path is still used. But only in the implementations that actually process paths for different operating systems. Only the interface that is included into about any compilation unit has changed to string.

[niklwors]

You changed for all build types the PATH define to string, but that is not the sense of the PATH define. It is much better if you just change for the static linking case the PATH define to string and remove the boost filesystem includes. Then you dont should have the boost filesystem dependency.

[rfranke]

In fact it would have been easier to just change the PATH define to string for the static omc build. But this would have required two #ifdef RUNTIME_STATIC_LINKING in OMCFactory.cpp, in order to exclude boost filesystem path operations from this build.

I found it a cleaner solution to distinguish between interface and implementation: the interface uses string. The implementation in OMCFactory.cpp that accesses features of fs::path also uses fs::path.

[niklwors]

Normaly the OMCFactory.cpp should not use the PATH type. Only the Policy Factories should use it. Then you don't need a special define in the OMCFactory.
I have to check why the OMCFactory needs this.

[rfranke]

The current version using string in the interface has another advantage: boost::filesystem is not included anymore into the compilation of each simulation model. Only the precompiled OMCppFactory library depends on boost::filesystem and boost::program_options.

[rfranke]

5bcd7ee53d1898e002da0fe33173fa0b89edcba1/OMCompiler moves the creation of the alg loop solver factory into the generated FMU code. This way it can be omitted if the FMU has no algebraic loops -- the size of a simple FMU binary reduces by almost 1MB (to <3MB from originally 12MB + external dependencies).

[rfranke]

0b4c12507072aa29f31f1f65c84441b88897679d/OMCompiler gets rid of the global using namespace std under Linux and OSX. It is replaced with using std::abs, in order to avoid implicit truncation to int.

[rfranke]

7c86a6a8e710aa4795eb8d033be1c2739cccdf0b/OMCompiler changes the type of delay buffers from fixed sized boost::circular_buffer to std::deque (double ended queue). New values are pushed to the back; old values are erased from the front if the delay time permits. A limitation of the buffer size can be achieved implicitly with a fixed step size solver.

This also replaces the last use of boost in simulation code generated with the C++11 option.
(The use of uBLAS remains because the linear algebra stuff goes beyond the C++ standard).

[sjoelund.se]

Milestone renamed

[sjoelund.se]

Milestone renamed