#3522 closed enhancement (fixed)
Replace boost with C++11 in generated code
Reported by: | rfranke | Owned by: | rfranke |
---|---|---|---|
Priority: | high | Milestone: | 1.9.4 |
Component: | Cpp Run-time | Version: | |
Keywords: | Cc: | niklwors, mwalther |
Description
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.
Change History (22)
comment:1 Changed 9 years ago by rfranke
comment:2 Changed 9 years ago by 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
....
comment:3 Changed 9 years ago by 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?
comment:4 Changed 9 years ago by 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.
comment:5 Changed 9 years ago by 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.
comment:6 Changed 9 years ago by 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.
comment:7 Changed 9 years ago by rfranke
This sounds good. Having specific static policy classes, the dummy LoadLibrary should disappear as well from static code.
comment:8 Changed 9 years ago by 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.
comment:9 Changed 9 years ago by rfranke
- Owner changed from mwalther to rfranke
- Status changed from new to accepted
comment:10 Changed 9 years ago by 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?
comment:11 Changed 9 years ago by 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.
comment:12 Changed 9 years ago by 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.
comment:13 Changed 9 years ago by 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.
comment:14 Changed 9 years ago by 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.
comment:15 Changed 9 years ago by 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.
comment:16 Changed 9 years ago by 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.
comment:17 Changed 9 years ago by 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.
comment:18 Changed 9 years ago by 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).
comment:19 Changed 9 years ago by 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.
comment:20 Changed 9 years ago by rfranke
- Resolution set to fixed
- Status changed from accepted to closed
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).
comment:21 Changed 8 years ago by sjoelund.se
- Milestone changed from 1.9.4 to 1.9.4-1.9.x
Milestone renamed
comment:22 Changed 8 years ago by sjoelund.se
- Milestone changed from 1.9.4-1.9.x to 1.9.4
Milestone renamed
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?