- Boost - lists.preview.boost.org

[modularization] Are modular releases a goal or a non-goal?
by Stephen Kelly 25 Sep '14

25 Sep '14

Hello, I can download one monolithic tarball to get Boost 1.56: http://sourceforge.net/projects/boost/files/boost/1.56.0 And I get all of it. There are no separate 'modular Boost' tarballs so that I can download what I want and not what I don't. Compare to Qt which provides both monolithic source tarballs: http://download.qt-project.org/official_releases/qt/5.3/5.3.2/single/ and modular source tarballs: http://download.qt-project.org/official_releases/qt/5.3/5.3.2/submodules/ Is something similar to this a goal or a non-goal for 'Boost modularization'? Thanks, Steve.

10 32

[intrusive] Possible bug in bstree_algorithms.hpp
by Lars Hagström 25 Sep '14

25 Sep '14

Hi, I've just upgraded to boost 1.56 and I've run into a problem. I get an infinite loop inside insert_equal_lower_bound_check(...) in bstree_algorithms.hpp. I'm using that file indirectly through Boost.Interprocess. I've not been able to penetrate exactly what that function does or whether there is indeed a bug in it. But I did look at the version that was in 1.55 (called insert_equal_check_impl(...) there), and to me it looks like there is at least one unexpected change: A ! has been removed on the line where the branches are compared, which to me would mean that we put the wrong branch into x. Again, I don't really understand what is going on in that function, so I might well be completely wrong. Cheers Lars

2 22

[containers] Clarifications on incomplete type support?
by Mikael Persson 24 Sep '14

24 Sep '14

Hi all, I've been using Boost.Containers for some time now. As for many, the primary (and only) reason for using them (over STL ones) is that they support incomplete value types. Since the beginning, I have always assumed that support for incomplete value types meant that I could instantiate the container type and any indirect type, most notably, **iterators**. I cannot stress enough how important it is for data structure designs to be able to instantiate the iterators of containers of incomplete value types! And, in general, there is no inherent reason why, in general, incomplete type support could not extend to iterators as well. This is even more true in light of the SCARY iterator requirements (which boost containers purport to support, which cannot possibly be true given the compilation errors I have seen). So, my main question is this: Is the following code supposed to work when using Boost.Containers? boost::container::some_container<IncompleteType>::iterator it; The documentation only states that "all Boost.Containers containers [..] are designed to support incomplete types". This needs to be clarified when it comes to iterators, at least. If the above code is not guaranteed to work, then may I request that it be added to the requirements? Because in my view, not having iterator support for incomplete types sort of defeats the whole purpose of supporting incomplete types, except for the most trivial use-cases (like those "recursive containers" examples). And moreover, without this support, workarounds are so major that they won't benefit from the container's support for incomplete types any more (and therefore, might as well use the standard ones instead). >From experience, I know that most Boost.Container containers had working iterators for incomplete value types up to and including version 1.54 (and it's a kind of natural consequence of supporting incomplete types for the container itself). But recently, changes to the boost::container::list class have made it impossible to use of boost::container::list iterators for incomplete types (due to some convoluted new iterator scheme that I can barely understand myself). If iterators are supposed to be included in the incomplete type support, then this is a bug in the list container (and btw, boost::unordered_set also has the same problem), and I would also recommend adding this to the container unit-tests. Thanks, Mikael Persson

2 9

[modularization] What is a module? What is a sub-module?
by Vicente J. Botet Escriba 24 Sep '14

24 Sep '14

Hi all, After the long threads concerning the modularization it seems clear to me that we are in an impasse. While I guess breaking dependency cycles is a modularization goal for all of us, it seems that moving files from one module to a sub-module has not be well accepted, worst yet, could have some dramatic consequences (a lot of testers were broken with the MPL split) due to the way we build Boost. I'm wondering if we don't need an alternative definition of module/sub-module. This definition could be temporary, it would just be useful to identify the modules/sub-modules that would be the good ones. We could move the files when needed by some user oriented tools (install). Let me try it. A module or submodule is just a list of files. The first problem is how to identify this list. Currently, the boostdep tool request that a module is associated to the files in the directory include of a repository and a sub-module to the files in the directory include in a subdirectory of a repository. I don't remember which criteria Stephen Kelly is using in his tool. I propose to switch to a less restrictive and more explicit mapping that don't implies any change on how Boost is build/tested. The advantage is that we can change this mapping without any trouble on the regressions tests :) * If a repository don't have this explicit mapping, the module with the same name as the repository is composed of the files in the directory include, src and build of the repository. There could be other implicit modules for test, examples, benchmarks, ..., which are not user oriented. * If a repository has this explicit mapping, the module/sub-modules are the ones described in this mapping. Open points * Do we want/need to be able to define modules containing files in more than one repository? * Where the explicit mapping should be stored? * Should we track the build dependencies? How? * Should we rethink how Boost is build in a modularized world? * Do we want/need to take in account optional dependencies from the beginning? Note that this would not reduce the dependencies at the file level, but at least would help us to break the cycles. Peter, if we agree this is the way to exit from the impasse, would you like to adapt your tool to use an explicit mapping ? Any concrete proposal about how Boost could be installed in a modularized world would be welcome. Open point: Is anyone interested in working on this modular installation? Best, Vicente

8 16

Re: [boost] [Boost.Config] variadic templates availiable with GCC 5 in C++03 mode
by Lars Gullik Bjønnes 24 Sep '14

24 Sep '14

(resent due to missing membership on boost list) On 23 September 2014 22:43, Lars Gullik Bjønnes <larsbj(a)gullik.org> wrote: > Hi, > > It seems that the checking to define BOOST_NO_CXX11_VARIADIC_TEMPLATES or not > is slightly wrong when __GNUC__ > 4 (in this case __GNUC__ == 5) > > This was tried fixed in [SVN r70019], but it looks like the fix was > wrong for __GNUC__ > 4. > > (git 050da29d47ce43b1dca6bed03d54c40d5e3d315e) > > > This is the current code: > > // Variadic templates compiler: > // http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html > # if defined(__VARIADIC_TEMPLATES) || (__GNUC__ > 4) || ((__GNUC__ == > 4) && \ (__GNUC_MINOR__ >= 4) && defined(__GXX_EXPERIMENTAL_CXX0X__)) > # define BOOST_HAS_VARIADIC_TMPL > # else > # define BOOST_NO_CXX11_VARIADIC_TEMPLATES > # endif > #endif > > > This is my proposed fix: > > diff --git a/functional/boost/boost/config/compiler/gcc.hpp > b/functional/boost/boost/config/compiler/gcc.hpp > index ef6b07e..736e8ba 100644 > --- a/functional/boost/boost/config/compiler/gcc.hpp > +++ b/functional/boost/boost/config/compiler/gcc.hpp > @@ -157,7 +157,7 @@ > > // Variadic templates compiler: > // http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html > -# if defined(__VARIADIC_TEMPLATES) || (__GNUC__ > 4) || ((__GNUC__ > == 4) && (__GNUC_MINOR__ >= 4) && defined(__GXX_EXPERIMENTAL_CXX0X__)) > +# if defined(__VARIADIC_TEMPLATES) || ((__GNUC__ > 4 || (__GNUC__ == > 4 && __GNUC_MINOR__ >= 4)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) > # define BOOST_HAS_VARIADIC_TMPL > # else > # define BOOST_NO_CXX11_VARIADIC_TEMPLATES > > > (I'll post a none-damaged diff if wanted.) > > -- > Lgb -- Lgb

3 2

[iterator] Support other tuple implementations with zip_iterator
by Kohei Takahashi 24 Sep '14

24 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Here is my proposal [1] for supporting other tuple implementations (e.g. std::tuple) with zip_iterator, which discussed at the issue [2]. This PR will reimplement zip_iterator as a fusion based one, because current implementation is tightly coupled with Boost.Tuple. Of course, Boost.Tuple should be accepted via Boost.Fusion. [1] https://github.com/boostorg/iterator/pull/2 [2] https://svn.boost.org/trac/boost/ticket/7526 Thanks, Kohei Takahashi -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUIi7FAAoJEGGyPxPRp/zof5IQAMFjfB1q3yhXXEvoXOZGedhn 8S6hCWsar0MA42Wn/PIG1cMxgb4oc9cZFv6KBieDAn38QJu44NYDFhxhRlMPDMrs cgNQDbvYROWzakzUX93DstzSwvUwqIjWg4bFFYbE5cmK1MbmCWZODs5TQFKQDxxO KfrUEsttoMlbklFa5Rw9JdM3bP2NMUlmJZ9M/8/rBhAf/AvgLiSK9f7qXjoWoMaZ DwZKEztQB2ZRL+iwtCeNJU0OSJ3/KCsS45xYKY9tsE25RGWU8vdryKEqt/eeHe/d dfVpMWMLKZ3g7PoLc73ntxX+C0B/Zj96rhqurt3Z6gtWmSiYFxct/0oDqfu9JKCn hG4p+g70m1nW47Kfvc8p3ZiWABvOOghPT9CEyyATh4nMzJTYLwawD00uRUtdATT9 siTIH2AeEHUnUuNHMMdbr7kJMq/6aubt0RFz04TgIZJ0EmrkjbuxfeiemoiZhyeN JNE9ubujqMiAcyeLpCWAbnogLWMgn8duvIKYc0pvFlYIkGWKrAMSd46RaCd47g4x alYh7vlLE8nqdmAwe2is5PfFIw8qzJj1zn+Kj+CFkXouJ9eObiOXTbTdQNPhFplT gAxYLdcmz23goQzAQ9xTMySmuGFzHKZn+uTQ3gpzDABC6zGCXhGA/Hu+JER/KmTY 3Ty2EoDqWdsu/bp9mY+/ =wJsr -----END PGP SIGNATURE-----

1 0

Boost.Hana - Type Classes, data types and categories (tags).
by Vicente J. Botet Escriba 23 Sep '14

23 Sep '14

Hi Louis, There is a lot of very good work on your library. I have some comments in relation on how I have implemented Type Classes in my prototype. About datatype<T>. The library proposes type classes and data types. The name datatype_t<> is confusing as the datatype<T> meta-functions must not return one of the defined data types. I see it much more as a category, which is used to map the data type to a category used as parameter of the instantiation TC::Instance<datatype_t<T>>. In addition, I wonder if the category associated shouldn't depend on the type class we want to map. TC::Instance<category_t<T, TC>> About naming: Haskell doesn't have namespaces and all the functions are at the same scope. Your library makes use of a lot of non-member functions, and so name clashing must be avoided. What about moving all the non-member functions of the Type Class to a specific namespace? E.g. struct Monad { ... }; namespace monad { using namespace applicatives; ... bind() }; The use would need to use the type class namespace explicitly auto x = monad::bind(m, f) or introduce the namespace of the type class using namespace monad; auto x = bind(m, f); Best, Vicente

4 10

CMake module for compile-time benchmarks
by Louis Dionne 22 Sep '14

22 Sep '14

Hi, While working on Hana, I have developped a couple of tools to generate compile-time benchmarks. I have now made this easier to use for anyone who wishes to do the same by writing a CMake module which does the dirty work for you. The module is available at [1]. Basically, you drop this in your CMake tree, install a couple of dependencies and then you can create targets to run the compile-time benchmarks. The gist of it is explained in the module, and you can find a lot of examples in [2]. This is still a work in progress. For example, the module still does not support runtime benchmarking even though the documentation says it does. Also, it only works with Clang and GCC for now. There are probably a ton of glitches and ways to improve it; feel free to send pull requests! Regards, Louis [1]: https://github.com/ldionne/hana/blob/master/cmake/Benchmarks.cmake [2]: https://github.com/ldionne/hana/tree/master/benchmark

1 0

Boost.Hana - Maybe and Either data types design
by Vicente J. Botet Escriba 21 Sep '14

21 Sep '14

Hi Louis, I have some concerns with the design of the Maybe and Either data types (maybe the other data types have the same design, I have not taken a look at). There are somethings that I don't understand, sorry I have not changed yet my mind to then new C++ way. If I want to define a function that takes an Either string int, how can I define it? void f(??? p) {} I see that there is a maybe_detail::maybe<bool,class>, however I don't think this is the data type of Maybe, is it? Anyway, I don't see a either_detail::either<bool, class, class>. I have the impression that I must use always auto with lambdas auto f = [](auto p) {...}; But I don't know what I can put in the body. It is to clear neither how can I declare a variable of type Either string int. I see that I can declare a Left string and a Right int BOOST_HANA_CONSTEXPR_LAMBDA auto left_value = left("x"); BOOST_HANA_CONSTEXPR_LAMBDA auto right_value = right(1); I have the impression that the variables are initialized only once and can not be reassigned,or at least we can not assing a Left value to a variable initialized with a Right value. Is this by design? A last concern related to the applicative lift function. I suspect that it corresponds to the Haskell return function and the more general unit Monad function. As there is a lift function in Haskell, this is a little bit confusing. I have named this function make :) In Haskell, the template parameter is a type constructor. This Monad(Applicative) type constructor should be Either E, not Either. Is the type-constructor feature missing from your design? How wan I create an Either string int with a call to auto x =lift<Either>(123); I would expect something like auto x = lift<Either<string>>(123); In my prototype I have auto x = make<expected<holder, string>>(123); where expected<holder, string> is the Monad type constructor for expected<T, string>. Sorry the argument of expected and Either are in interchanged. The string type is the Error. Best, Vicente

2 1

[GSoC] [Boost.Hana] Formal review request
by Louis Dionne 21 Sep '14

21 Sep '14

Dear Boost, It has been a while since I've given news about my GSoC project, Boost.Hana[1]. Things are going very well and I uploaded the library to the Boost Incubator. I think it is time to push the library forward for review. As the author, I know everything that's left to be done and polished before I can be fully satisfied. Still, I believe the library is worthwhile in its current state as it implements a superset of the functionality found in the Boost.MPL and Boost.Fusion. I also think the library will benefit greatly from a larger user base and more feedback. Here are some caveats: - The library requires a full C++14 compiler, so only Clang 3.5 can compile the unit tests right now. However, compilers will eventually catch up. Also, pushing cutting edge libraries forward might motivate compilers to support C++14 ASAP, which is probably a good thing. - The library is not fully stable yet, so interface changes are to be expected. I don't see this as a problem as long as this is documented, especially since I expect Hana to be used mostly for toying around for at least a while. I could be mistaken. So unless someone thinks the library isn't ready or would get rejected right away in its current state for reason X, I am requesting a formal review for Boost.Hana. Regards, Louis [1]: http://github.com/ldionne/hana

22 110