- Boost - lists.preview.boost.org

[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

[Boost.Filesystem] unique_path uses a random number generator from the OS, correct?
by Ben Fritz 09 Jan '15

09 Jan '15

The reference docs for unique_path state: Remarks: Implementations are encouraged to obtain the required randomness via a cryptographically secure pseudo-random number generator, such as one provided by the operating system. I'm confused by the "implementations are encouraged to" text. Isn't Boost.Filesystem the implementation of unique_path? Specifically, it *looks like* this is provided in unique_path.cpp which will use either CryptGenRandom from the Windows API; or /dev/urandom or /dev/random on POSIX systems. This means the random number comes from system/OS utilities, and not Boost itself, correct? -- Ben Fritz

2 1

A proposal for the creation of a new module, Core Type Traits
by Peter Dimov 09 Jan '15

09 Jan '15

This is a more formal statement of the same suggestion I've already given in other threads. Currently, library developers who need type traits functionality face a choice: either to use the TypeTraits library, and make their libraries dependent on MPL, Preprocessor, TypeOf and Utility, or to duplicate its functionality locally. Similarly, developers who want to specialize a type trait on a type of theirs, even a trivial empty struct, need to include the TypeTraits headers for the traits to be specialized, which brings in MPL and Preprocessor on a header-level, and makes their module dependent on TypeTraits and its dependencies listed above. Local replication, as in Boost.Move, rightly attracts charges of code duplication, with the associated potential maintenance problems when the implementations diverge. These two problems could be avoided if we were to have core type traits whose interface consisted solely of a member integral constant called "value", without any other required members or base classes, and which were only allowed to depend on Config or StaticAssert. This solves the second problem because it will then be possible for a developer to specialize a trait, such as is_pod, by using a forward declaration of the form template< class T > struct is_pod; in the appropriate namespace, like boost::core_type_traits, and then adding his specializations: template<> struct is_pod< blank > { BOOST_STATIC_CONSTANT( bool, value = true ); }; without including ANY additional headers. If we look at the current implementation of Boost.TypeTraits, for example is_pointer, we see this: template< typename T > struct is_pointer_impl { BOOST_STATIC_CONSTANT(bool, value = (::boost::type_traits::ice_and< ::boost::detail::is_pointer_helper<typename remove_cv<T>::type>::value , ::boost::type_traits::ice_not< ::boost::is_member_pointer<T>::value >::value >::value) ); }; in namespace detail, and then this: BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_pointer,T,::boost::detail::is_pointer_impl<T>::value) which takes care of everything else. Note that is_pointer_impl is EXACTLY what we need! It is the core implementation of the trait and exposes only ::value and nothing else. The full-featured boost::is_pointer is built on top of that. If detail::is_pointer_impl was called core_type_traits::is_pointer, this would immediately take care of the two problems at the top of this post, while not affecting the users of Boost.TypeTraits in any way. In particular, note that if a developer specializes detail::is_pointer_impl, is_pointer automatically picks up this specialization. Therefore, I propose that a new module, libs/core_type_traits, is created, which: - provides core type traits that only expose a member integral constant called "value" as part of its documented interface and nothing else; - allows these traits to be forward declared, without requiring header inclusion; - is not allowed to depend on anything except Config or StaticAssert; - is the place to which TypeTraits's is_pointer_impls gradually migrate, along with their tests. This - solves the dependency problems some of us are facing, - avoids unnecessary code duplication, - still allows type trait specialization, with clients of both libraries automatically picking up the specialization, - is backward compatible with respect to existing uses of Boost.TypeTraits because the new library will contain the same code and the same tests. Thank you for your attention. :-)

4 8