January 2015 - Boost - lists.boost.org

Re: [boost] GSoC Proposal[game dev and boost c++]
by Mudit Sharma 12 Jan '15

12 Jan '15

Respected all, As we all know in game development Rotation and Translation play the most important role..I propose to implement either[whichever is relevant to boost] using boost geomtry(of course) and uBLAS(will make calculations easier)... Can this be taken up as a project for summers?

3 2

[Mixin] Some comments
by Vicente J. Botet Escriba 12 Jan '15

12 Jan '15

Hi, First of all, I want to say that I like your library too much. It is quite close to a library I was working one EntityRoleSubject. You library could be extended to to take in account the subjective programming paradigm (see below). I have some comments/remarks/questions: * I have some doubts about the name mixin. What a mixin has more than a facet or an aspect? Mixins in C++ have a specific mean in the context of CRTP. Why have you chosen the mixin name? * The construction of the mixins in the tutorial is done always with the default constructor. Can we do emplace construction? How can you ensure the invariants of some mixing classes? * The priority of the messages doens't compose well. The user needs to have a global view of the application so that it can assign the correct priority. I have not a better suggestion, but I think that this issue would need more insight. * Respect to subjective programming: it would be great to be able to create subject from an entity so that only the mixins of the subject would play when a reference to this subject is addressed. subject<Mix_1, .... Mix_n> s (o); o.get<Mix_k>() works as expected. o.get<Other>() compile fails if not equal to any Mix_k * The macro bm_this :( * I would like to see what is behind the scenes the different macros in an implementation section. * The entity-mixin relation is not recursive, that is, a mixin can not have associated mixins, or can them? * Can a mixin D inherit from another mixin B? Could the mixing D be retrieved when getting the mixing B? mutate(o).add<D>; o.get<B>()->f() // f been a virtual function on B? * The example of the mixin headphones_player show that the play() implementation makes use of get_sound() provided by other mixins. This dependency is not explicit. I would expect to be able to say that headphones_player depends on another mixing providing the get_sound message. That's all for now.I will come back later when i will read more. A BTW, the reference documentation doesn't contain the add<M>/get<M> mutate functions? Best, Vicente

4 11

[chrono] Dependency on math?
by Beman Dawes 12 Jan '15

12 Jan '15

The latest dependency report shows chrono as having a dependency on math. See http://www.pdimov.com/tmp/report-develop-3b5a9f4/module-overview.html math is really big. In testing bpm, an install of timer (which depends on chrono) slowed noticeably when it got to math. Presumably the build is also much slower, although I haven't tested that yet. Is the math dependency really needed? Thanks, --Beman

7 18

[Mixin] Some comments
by Matus Chochlik 12 Jan '15

12 Jan '15

On Sun, Jan 11, 2015 at 4:02 PM, Klaim - Joël Lamotte <mjklaim(a)gmail.com> wrote: > On Sun, Jan 11, 2015 at 8:41 AM, Matus Chochlik <chochlik(a)gmail.com> > wrote: > [8<] > > > > I've been playing with some ECS designs lately and tried to implement two > > of my own [1],[2] (maybe those are among those you've already seen) (and > > sorry for the shameless plug). Based on what I've seen, if the ECS is to > be > > used according to the usage patterns you usually see in a game (or > > rendering) engine, I believe it is better for the component instances to > be > > stored together, outside of the entities (for locality of reference, > > efficient (re-)allocation, etc.). > > > > > I violently agree. > > > > The entity should IMO be just an unique identifier > > > My experiments so far reach to the same conclusion: it's the most flexible > and potentially efficient approach. > > > > and in both of my > > implementations there is a `manager` class that can be used to > > store/modify/query/remove/etc. the components of an entity. This way > > operations that are common, like execute this function (every iteration > of > > the update loop) on all entities with this set of components can be > > implemented more efficiently. > > > > In my current implementation I call the object > holding all components a "cluster". The Cluster hold one "pool" > of component by type of components. > Currently all the pools are the same type and basically are > augmented flat_maps but I recently realized that a more flexible system > could be implemented by letting the cluster user insert different kinds of > polls > depending on how he wants the component type to be memory managed ( > like a vector or like an actual pool or with allocated nodes?), how > "updates" are processed (in parallel, concurrent, jsut a loop?). > I plan to try this design in the coming months. > Ditto, In my second implementation I've defined an interface for the component storage objects (classes managing instances of components of one type in the manager). The interface is flexible enough to allow local or remote mutable/immutable storages, or storages using an RDBS, a web service, etc., to actually store the component instances. From the users' POV all this is transparent, they manipulate the components uniformly through the manager, they just need to specify what kind of storage should be used when registering the component type in a manager. > > I didn't solve the component-inter-requirements problem though, I'm not > sure > if I should implement this at all, and if yes should it be compile-time > checked > as Vincente suggests? In which case the cluster would have to know > the types it can manage at compile time too, because I see no way for > an entity to be able to be checked at compile time except for a construct > like > the suggested "subject". > I'm not sure what Vincente's use case is, but in game engines the ECS *deliberately* places very few constraints on the components and how they can be combined in an entity. The idea is that the programmer does not have enough knowledge of what the content creators or modders will want to do and statically constraining the components too much requires complete recompilation every time a change is made in the game logic accessing the ECS which is undesirable for the original content creators and usually impossible for modders. Furthermore game engines very often support modification of the ECS through scripting which again could be hindered if constraints were placed on how the components are combined. These concerns IMHO apply also on other applications, like CAD/CAM, etc. using an ECS. [8<] > > > > But having implemented several apps using this approach I find it quite > > limiting in some situations that the group of components is static. > > Sometimes it is useful (for example for debugging) to have the ability to > > add/remove component *types* on-the-fly. [2] allows this but its > > unfinished. > > > I can do that in my implementation indeed, it is helpful. > As said before I think it can be improved by allowing the user to provide > the > container of component for a type, making him chose how to manage them > as long as the container match a specific set of requirement (concept?). > > I use an abstract interface and so far the overhead from virtual function calls is not very dramatic. [8<]

3 2

[build] Test marked as compile-fail is now reported as a failure.
by Adam Wulkiewicz 12 Jan '15

12 Jan '15

Hi, Since yesterday one test marked as compile-fail is now reported as a failure on the regression tests page. It's the test: rtree_values_invalid on the page: http://www.boost.org/development/tests/develop/developer/geometry-index.html Surprisingly other tests aren't. see e.g.: geographic_custom_point_with_wrong_units on the page: http://www.boost.org/development/tests/develop/developer/geometry.html They seem to be defined the same way in the Jamfile: https://github.com/boostorg/geometry/blob/develop/index/test/rtree/Jamfile.… https://github.com/boostorg/geometry/blob/develop/test/point_concept/Jamfil… AFAIS the oldest run when it failed was of the runner: teeks99-03c-Ubuntu12.04-64 on Sat, 10 Jan 2015 02:05:44. On Fri, 09 Jan 2015 18:36:55 (teeks99-08b-win2012R2-64on64) everything was ok. Furthermore when run locally it's also reported as a failure. Some time ago of course "(failed-as-expected)" message was printed instead. Do you have any idea what may be wrong? Regards, Adam

2 1

[filesystem] Problems with UTF-8 paths in GIT.
by Rene Rivera 12 Jan '15

12 Jan '15

This commit < https://github.com/boostorg/filesystem/commit/785d521b54140763dd23ef091a18d…> is causing me some problems with some git clients. In particular the git client in Eclipse errors out with some unsupported / invalid messages. I know why those dir names are the way they are.. But we still are supposed to follow the naming rules we agreed to < http://www.boost.org/development/requirements.html#Directory_structure>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

About a Ratio/MPL submodule and removing dependencies from Ratio/Chrono on MPL.
by Vicente J. Botet Escriba 10 Jan '15

10 Jan '15

Hi, Boost.Ratio has a logical submodule providing an extension to the standard see boost::ratio as an MPL type adding struct rational_c_tag : int_<10> {}; This submodule could be moved to the subdirectory of libs/ratio/mpl so that the users of boost::ratio, shouldn't depend on MPL. Boost.Chrono depends already on MPL, but the dependencies are really minor - see below (and can be replaced by StaticAssert and TypeTraits, so that this dependency could be removed also. Do you think removing the dependencies of Boost.Ratio and Boost.Chrono on Boost MPL has value? Best, Vicente P.S. I know that currently TypeTraits depends on MPL, but we expect to resolve this dependency already. |<boost/mpl/assert.hpp>| * from |<boost/chrono/detail/static_assert.hpp>| |<boost/mpl/bool.hpp>| * from |<boost/chrono/detail/static_assert.hpp>| |<boost/mpl/if.hpp>| * from |<boost/chrono/io/duration_get.hpp>| * from |<boost/chrono/io_v1/chrono_io.hpp>| |<boost/mpl/logical.hpp>| * from |<boost/chrono/detail/is_evenly_divisible_by.hpp>| * from |<boost/chrono/duration.hpp>|

3 2

[variant] match()
by Eelis 10 Jan '15

10 Jan '15

Boost.Variant provides access through get() and visitors, but in C++11 we can do so much better! :) For a boost::variant<A,B,C>, the attached small utility function match() lets you write: match(v, [](A & a){ cout << "it's a A!"; } [](B & b){ cout << "oh, a B!"; } [](C & c){ cout << "ah yes, a C!"; }); Return values are supported. I think this really belongs in Boost. It makes variants much more usable. Regards, Eelis P.S. I have not attempted a C++98 implementation. P.S.2. Right after finishing my implementation, I discovered another, /vastly/ more complex implementation of the same thing: https://github.com/exclipy/inline_variant_visitor I'm not sure its complexity gives that implementation any advantages.

9 26

Moving files around
by John Maddock 10 Jan '15

10 Jan '15

Can I just fire a shot across the bows before we all get too carried away moving files around here there and everywhere? *The move has to make logical sense* - reducing dependencies is a worthy goal, but not if it makes stuff harder to maintain and/or harder for the user to find what they're looking for. Let me give you a trivial example: boost/utility/declval.hpp was moved into the type_traits repository to reduce dependencies on utility. OK fair enough. But I see no tests or docs, and the docs at the very least are still in "utility". So now we have a situation where maintenance of that functionality is split over two repositories each with different maintenance teams. That's not good. Perhaps more to the point, if I'm a user and I'm looking for boost/something/whatever.hpp, it had better darn well be in package "something" or I'm going to be pretty annoyed. This applies equally to folks wanting to use "whatever.hpp" as to folks wanting to submit pull requests. In fact if the above doesn't hold I suspect that a) Folks will give up and reinvent smaller utilities for themselves. b) Use an older version of Boost ("I new where everything was there"). c) Not submit bug reports or pull requests cause they can't figure out where they should go. I guess what I'm saying is that while re-factoring is a good idea, it needs a vision to improve "discover-ability" and make Boost's structure more logical, not merely easier for a package manager. Now please do carry on as you were ;) John.

3 2

[functional] How to avoid a dependency on functional?
by Beman Dawes 10 Jan '15

10 Jan '15

Filesystem has a dependency on <boost/functional/hash_fwd.hpp> in order to supply this: inline std::size_t hash_value(const path& x) { # ifdef BOOST_WINDOWS_API std::size_t seed = 0; for(const path::value_type* it = x.c_str(); *it; ++it) hash_combine(seed, *it == '/' ? L'\\' : *it); return seed; # else // BOOST_POSIX_API return hash_range(x.native().begin(), x.native().end()); # endif } The problem with this is that functional is a heavy-weight dependency for such relatively minor feature. See http://www.pdimov.com/tmp/report-develop-3b5a9f4/module-weights.html Is there any recommended way to avoid the functional dependency? Thanks, --Beman

5 14