Since this now requires to import iter-adapter-stl.hpp and iter-source.hpp at the same time, I decided to drop the convenience imports of the STL adapters into namespace lib. There is no reason to prefer the IterSource-based adapters over the iter-adapter-stl.hpp variants of the same functionality. Thus better always import them explicitly at usage site. ...actual implementation of the planned IterSource packaging is only stubbed. But I needed to redeclare a lot of ctors, which doesn't seem logical And I get a bad function invocation from another test case which worked correct beforehand. |
||
|---|---|---|
| .. | ||
| asset | ||
| cmd | ||
| control | ||
| engine | ||
| external | ||
| mobject | ||
| play | ||
| asset.cpp | ||
| asset.hpp | ||
| assetmanager.cpp | ||
| assetmanager.hpp | ||
| cmd.hpp | ||
| common.hpp | ||
| config-resolver.cpp | ||
| config-resolver.hpp | ||
| controllerfacade.hpp | ||
| DIR_INFO | ||
| facade.cpp | ||
| facade.hpp | ||
| state.hpp | ||
| streamtype.cpp | ||
| streamtype.hpp | ||