- Boost - lists.preview.boost.org

Re: [boost] [compute]/ Futures Some remarks
by Antonio Colino 15 Jan '15

15 Jan '15

On 01/14/2015 10:46 PM, Antonio Colino wrote: > I have a flawless implementation of this concept I am very proud of. Is any one willing to critique it? On 01/14/2015 10:46 PM, Thomas Heller wrote: > Wanna share it? Which concept are you refering to? I was referring to both type traits on lambdas and an implementation of a tasking library that is allocator free, that you can reset function arguments reuse the task, reuse threads, reset arguments on lambdas, copy tasks while running and still always get accurate information. Thread safe and lock free. Basically a scheduler, task implementation that dare i say rivals boost bind and std::packaged_task. As it can bind any set of arguments to a function , reuse the same function to create new states . It is the core of a bigger lib I have been working on that sends these tasks across machine bounds ( hpc ) and onto the gpu.

1 0

Tests that enable <warnings-as-errors>on
by Peter Dimov 15 Jan '15

15 Jan '15

Some test suites, for example Pool and Units, use '<warnings-as-errors>on' in their project requirements, to test for a warning-free compilation. Pool, f.ex. has project : requrements <toolset>gcc:<warnings-as-errors>on <toolset>msvc:<warnings-as-errors>on ; (among others.) This, however, is propagated to dependencies, so that in [ run test_threading.cpp : : : <threading>multi <library>/boost/thread//boost_thread ] Boost.Thread is also built with '<warnings-as-errors>on', which fails. (In addition, some other tests also fail because of warnings.) So I tried to use '<warnings-as-errors>off' only for some tests, but I was unable to come up with a syntax that worked. Putting -<toolset>msvc:<warnings-as-errors>on in the test requirements didn't (no effect). <toolset>msvc:<warnings-as-errors>off didn't (conflict). -<warnings-as-errors>on didn't (no effect). -<warnings-as-errors>on <warnings-as-errors>off didn't (no effect). Is there a way to override the project requirements from the run rule?

2 1

[thread] fails to build on Cygwin with weird errors
by Peter Dimov 15 Jan '15

15 Jan '15

Vicente, I'm trying to get the pool tests up and running (they fail across the board, at least on develop), and one of them requires Thread, which fails to build under g++/Cygwin. The errors are of the kind ..\..\..\libs\thread\src\win32\thread.cpp: In member function 'bool boost::thread::start_thread_noexcept()': ..\..\..\libs\thread\src\win32\thread.cpp:337:127: error: 'struct boost::detail::thread_data_base' has no member named 'id' uintptr_t const new_thread=_beginthreadex(0,0,&thread_start_function,thread_info.get(),CREATE_SUSPENDED,&thread_info->id); which leads me to think that, on Cygwin, you're using the POSIX header with the Win32 source file.

2 2

Re: [boost] [compute]/ Futures Some remarks
by Antonio Colino 15 Jan '15

15 Jan '15

I have a flawless implementation of this concept I am very proud of. Is any one willing to critique it?

2 1

Re: [boost] boost interval arithmetic
by Marc Glisse 14 Jan '15

14 Jan '15

(please keep the conversation on the list) On Wed, 14 Jan 2015, Павел Кудан wrote: > Dear Marc, > > Thank you for your answer, I also tried to contact Mr.Gubenko, have no information about other maintainers. Please, excuse my bad English, I will try to explain in more detail, please, ask if something will be uncertain. I thought the maintainers would be the 3 authors. > Boost interval library was planned as extension of mathematical functions on float/double/double long or other singe numeric values to operations on intervals. The problem is that intervals have some specific. For example, if float value can be either > either < or = some other float value (statement ! (a>b) == (a <= b) is always true), for intervals it is not correct. Intervals can also overlap. That means that it is not possible for pair of overlapping intervals to say certainly which of them are greater than other. It is the intermediate situation, which is impossible with original single float values. > > And boost interval class has comparison operators and user can expect that they will behave in similar way with usual float comparison operators. > > For that reason, the behaviour of that comparison operators was made changeable and depends on some kind of policy, defined by user. Default behaviour is to throw exception when such intermediate situation (not possible for single float values) takes place. > > That was very wise solution, especially useful in very probable case, when some programmer will try to adapt some existing code with float calculation just changing type of value to boost interval. He will get exception in than exceptional situation - when usual float comparison operator is not applicable any more. > > That is OK. > > > > But as well boost interval class defines mathematical functions and operators. And user can expect that they also will behave similarly to usual float comparison operators. But great disappointment and multiple possible errors which is hard to locate is waiting for him here. Because it is not so. Arithmetic operators behave in completely different manner. > > Let's look on of most basic operator =/ and see what it is doing. > > But before let's see what is division of intervals and what is it's result. > > Boost interval class has two function - division_part1() and division_part2(). It is correct as when you divide one interval with another, the result will be single interval or a pair of intervals. The last situation takes place when in statement A / B, interval B cross a zero. That is not normal for intervals to have a pair of intervals as a result of division, but it is exceptional for single float numeric division. > > Now let's get back to /= operator and watch what he will do in such case. > > Let A = [1,2] and B = [-1, 1] > > and let's see what we will get after A /= B and what we should get. > > The true result of division in that case will be a union of pair of intervals [-infinity, -1] and [2, -infinity] Actually, [-inf,-1][1,+inf] > Interval /= operator, naturally, must return one interval. It is, obviously, impossible in this case - to return one of two. Again intermediate situation, not applicable to single float calculations. Again, throwing exception must be a result to let user know that he does not know what he are really doing. The same behaviour, as comparison operators. But it is not so. > > Instead of such natural behaviour, /= operator of boost interval class are doing impossible thing. It silently decides for itself which one of two parts of whole result to return and kill another part of whole solution somewhere under the scene. > > The result of A /= B will be [-infinity, -1]. Not correct result - as it is not complete. One of to parts is missing. Did you really observe that? If so, it is a bug. [1,2]/[-1,1] is supposed to give [-inf,inf] (and it does indeed, in my tests), which certainly contains the right value ;-) If you have a testcase that shows differently, it would be good to open a bug report on trac. > Very very bad operator behaviour. User get not correct result and even does not know that it is so. It will be hard to find when this error is located, and when it will be done, library user will not think that he should know better what he are doing and learn some basics of interval arithmetic - no, he will accuse boost interval as part and boost as whole for bugs in libraries implementation. U nfairly , of course, but who cares. > > > > To correct it, at least, arithmetic operators and functions of interval class must behave similarly to comparison operators - throw exception in situations, not applicable for single float calculations. > > That is what I meant when said: "The difference in behaviour of comparison operators and basic arithmetic operators looks as probable misconception." > > > > I know, it is hard to understand, especially because bad English, but I hope it is important and hope it will help. -- Marc Glisse

2 2

Re: [boost] Futures (was: Re: [compute] Some remarks)
by Antonio Colino 14 Jan '15

14 Jan '15

Concerning std::futures and promises, my thought is wrapping an immutable state in a task, nither future or promise, but with elements of both. Creating a mutex from an asm lock cmpxchg wrapped in c ( available most platforms ) to a shared_ptr gives you a copyable mutex. Not that it matters, but if the state manager ensures a swap every time the arguments are updated, and the state has a ref count destructor, a value storage, function/lambda/member func/functor storage, the effect is an immutable state. once the args are set nothing can change but the execute function or function brackets, a flag in the state ensures that the func will only execute once ( all flags set by single asm instruction xchg, wrapped in c ). this task , or promise if you like, is now copyable, and doesn't require an allocator as the internal state is set by setting the arguments and the state ptr and can be created then. Every time the task/ promise gets copied the shell only exists to point to the state. Having a generic function that wraps any func call in a std::function<void()> using a lambda , works nicely for a basic way to fill a queue generically. In the end you only have two exposed objects. A task and a scheduler. No mutexes, futures, promises, or any locking mechanisms of any kind. The task implementation I'm speaking of also accepts lambdas, and can reset there arguments. The thought is creating the shell (task , promise, whatever) once. Then setting the arguments many times. Each time it would internally create a new state, the user still has to take care of the memory, less the ref count get to zero, but a simple vector does nicely. Since it is all wrapped in the copyable task/promise, it is transparent to the user. So... task(any function in with or without args), task.set_args, scheduler.queTask, and go. The scheduler is just a thread grouping dictated by the user or by the hardware concurrency as a default. The result can be retrieved directly through the task or it can create a future as well or fill an existing one with the original future ref in the state. Don't really need it but... if it must be future/promise. Biggest problem i had was dealing with the lambda and functor case intuitively and cross platform. Functions and member functions were a snap.

1 0

PDF versions of Quickbook generated documentation - Do you like the serif font?
by Paul A. Bristow 14 Jan '15

14 Jan '15

I've noted that for documentation using the Quickbook toolchain, we use a serif font (Times Roman?) for the PDF, but a sans serif for the equivalent HTML version. Is there a reason for this? Should they not be the same font? (So that they look the same?) Which do we prefer? Should we change either or both? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

2 2

BOOST_ASIO_SEPARATE_COMPILATION linker error
by Arun.Ramasamy＠high5games.com 14 Jan '15

14 Jan '15

HI, I'm trying to build boost 1.47's asio library with the BOOST_ASIO_SEPARATE_COMPILATION macro in windows 7, 32-bit, VS 2010. With this macro, the asio library can be included and built easily without building all of boost or using bjam. However, I get the following linker error: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) referenced in function "public: __thiscall boost::system::error_code::error_code(void)" (??0error_code@system@boost@@QAE@XZ) unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'posix_category''(void)" (??__Eposix_category@system@boost@@YAXXZ) 1> Basically the functions boost::system::system_category and boost::system::generic_category aren't defined anywhere. I can't find the implementation of these functions in boost source when I tried grepping it. Should I just use bjam to build the asio library. Thanks arun

3 2

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

13 Jan '15

Hi Vladimir 2015-01-12 7:26 GMT+01:00 Vladimir Prus <vladimir(a)codesourcery.com>: > > Hi Adam, > > On 01/11/2015 10:38 PM, Adam Wulkiewicz wrote: > >> 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 >> > > Why is it surprising that test A fails while test B does not? Are these > exactly identical > tests? > They're both expected to fail to compile. > > They seem to be defined the same way in the Jamfile: >> https://github.com/boostorg/geometry/blob/develop/index/ >> test/rtree/Jamfile.v2 >> https://github.com/boostorg/geometry/blob/develop/test/ >> point_concept/Jamfile.v2 >> > > Could it be that the problem with the actual tested functionality. > AFAIU no because the test is reported as a fail only if it's expected to compile/link/run but it fails to compile/link/run. If the situation is the opposite (expected to fail but doesn't fail) the test is reported as a pass (with dark green background). Otherwise the test should be reported as a "regular" pass. > > 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? >> > > Looking at > > http://www.boost.org/development/tests/develop/ > developer/output/BP%20x86_64%20C++11-boost-bin-v2-libs- > geometry-index-test-rtree- rtree_values_invalid-test- > clang-linux-3-5~c14_libc++-debug-debug-symbols-off.html > > It does look indeed that complication is successfull, while it should fail > for the test to pass. If by successful you mean "the compiler output is present" then indeed it isn't. However it's not always the case, see: http://www.boost.org/development/tests/develop/developer/output/BP%20x86_64… http://www.boost.org/development/tests/develop/developer/output/trippels_gc… Though I can't see any error message there, only warnings. But this is not the first time I see something like this on the regression tests page. However the message about trimming of the output is displayed only for the first of the tests mentioned above. > Locally for me, with gcc, the > compilation fails, and the test is deemed passing, so I can't see any > Boost.Build malfunction here. > Yes, the cause may be located elsewhere, in Geometry, Regression, Test, etc. For a clean run I'm now unable to build the tests due to some undefined references but the problem is most likely located elsewhere. > Am I missing something? Or am I? Regards, Adam

3 6

Re: [boost] [Boost-testing] Linux regression test runners - What do devs want?
by Blower, Melanie 13 Jan '15

13 Jan '15

Niklas, How do you compare the results of running the same compiler on Linux and QNX? Do you just eyeball the report on the website, or do you use a script to compare the test results on the filesystem? Thanks and regards, Melanie -----Original Message----- From: Boost-Testing [mailto:boost-testing-bounces@lists.boost.org] On Behalf Of Niklas Angare Sent: Tuesday, January 13, 2015 7:09 AM To: boost-testing(a)lists.boost.org Cc: boost(a)lists.boost.org Subject: Re: [Boost-testing] Linux regression test runners - What do devs want? "Tom Kent" <lists(a)teeks99.com> wrote: > Instead of running lots of different versions, I was thinking about > running various compatibility options of the two main compilers...I've > seen some other test runners with things like libc++, c++11, c++14, > etc. My real question, would developers be better served by these > options than different versions? Would they prefer both with longer > revisit times between each test type? Other thoughts? My runners use gcc 4.4(.2) (in gnu++0x mode) on QNX, and it's useful to be able to compare to the same compiler running on Linux. I'm sure it's the same for other non-Linux environments such as MinGW. Currently there are other runners that match my compiler configuration better than yours do, but you get the idea. Regards, Niklas Angare _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing

1 0

TravisCI and Coveralls integration instructions
by Antony Polukhin 12 Jan '15

12 Jan '15

Hi all, The following step by step instruction https://svn.boost.org/trac/boost/wiki/TravisCoverals may be useful for those of you who want to: * make sure that tests cover all the code lines * make the README.md more colorful and useful * use additional testing infrastructure Here are some examples of how the results looks like: * https://github.com/boostorg/variant#test-results * https://github.com/boostorg/type_index#test-results P.S.: Shall I add this tutorial to "Guidelines" or to the "Infrastructure" section of the Wiki? -- Best regards, Antony Polukhin

2 1

[boost.fiber] regarding to migration of fibers between threads?!
by Oliver Kowalke 12 Jan '15

12 Jan '15

Hello, boost.fiber was reviewed in January 2014 and now I've finished the requested changes. Unfortunately the migration of fibers between threads is not stable yet, but synchronizing fibers running in different threads works. I'd like to know if fiber migration is absolute necessary to pass the next review or might it be acceptable to finish this feature later. so long, Oliver

2 1

[mixin] Library name
by Matus Chochlik 12 Jan '15

12 Jan '15

On Mon, Jan 12, 2015 at 1:32 PM, Klaim - Joël Lamotte <mjklaim(a)gmail.com> wrote: > On Mon, Jan 12, 2015 at 1:21 PM, Borislav Stanimirov <b.stanimirov(a)abv.bg> > wrote: > > > > > * EntityComponent - not great since it doesn't exactly follow the > > entity-component-system pattern, although it can be said that it allows > the > > construction of entities from components. > > > > > As long as you consider that it is not implementing the ECS pattern, it > shouldn't use this name indeed. > > +1 If the `Mixin` name is 'bad' because it is used to describe something different in C++ then `EntityComponent` is 'bad' for the same reason

1 0

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

[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