- Boost - lists.preview.boost.org

[gsoc16] [Boost.GIL] gsoc idea - further development on Boost.GIL
by Christopher Harpum 18 Feb '16

18 Feb '16

Dear Boost, Pre-warning, this is my first time actively engaging in the mailing list - I primarily stick to the archives - so excuse me for anything non-conformat. I'm a student looking to forward a proposal regarding further development of Boost.GIL. Namely: - Cleaning up some bugs / oversights within the current review branch (lack of colour-conversion profiles for certain formats, uninitialized values resulting in UB for BMP palette alpha channels, etc.) - Fulfilling additional features and clean-up, as requested during the formal review (2010) http://lists.boost.org/boost-announce/2011/01/0281.php - Looking into further development of the io_factory proposal for run-time file format detection (http://stlab.adobe.com/wiki/index.php/GIL_File_Format_Import/Export_Factory ,POC implementation https://github.com/stlab/adobe_platform_libraries/tree/master/adobe/gil/exte nsion/asl_io) I use Boost.GIL extensively within my projects, so I've had a reasonable amount of time to get accustomed to the code-base and believe this will help me achieve these goals. I understand that the project has been undergoing a period of inactivity, so I'm not sure whether this proposal would find a suitable mentor, or if it will be of interest for a GSOC project. I hope to further discussion of this proposal prior to submitting anything formal, though I'm not fully aware of the procedures for independent submissions. Regards, Chris

2 1

[MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?
by Krzysztof Jusiak 18 Feb '16

18 Feb '16

Dear Boosters, I have recently released 1.0.0 version of experimental C++14 Boost.MSM-lite. Your scalable C++14 header only eUML-like meta state machine library with no dependencies, which outperform Boost.MSM - eUML in: - faster compilation times - up to 60x times faster! - smaller executable size - up to 15x smaller - slightly better performance - smaller memory usage - short error messages Check it out yourself online! http://boost-experimental.github.io/msm-lite/examples/index.html#hello-world Performance Results: http://boost-experimental.github.io/msm-lite/overview/index.html#performance Source code: https://github.com/boost-experimental/msm-lite Documentation: http://boost-experimental.github.io/msm-lite Any feedback is more than welcome! Cheers, Kris

7 58

GSOC 2016
by Boldy Happy 18 Feb '16

18 Feb '16

Hello!I would like to know if Boost is participating in GSOC 2016.Please excuse if me if I made a mistake by sending this kind of email as I am just a beginner. Thanks in advance!

1 0

Interest in double ended containers
by Benedek Thaler 18 Feb '16

18 Feb '16

Dear Boost, I'd like to draw attention to my double_ended library, founded by GSoC 2015. It provides two containers, briefly described below. Given there's interest, I'd like to propose this library later. Documentation: http://erenon.hu/double_ended/ Source: https://github.com/erenon/double_ended Short overview: `devector` is a hybrid of the standard vector and deque containers, as well as the `small_vector` of Boost.Container. It offers cheap (amortized constant time) insertion at both the front and back ends, while also providing the regular features of `std::vector`, in particular the contiguous underlying memory. In contrast to the standard vector, however, `devector` offers greater control over its internals. Like `small_vector`, it can store elements internally without dynamically allocating memory. `batch_deque` is very similar to the standard `deque`, with a slight twist. It lets you specify its segment size: The size of the contiguous memory segments it uses to store its elements. This provides a consistent layout across platforms, and lets you iterate over the segments with batch operations. Thanks, Benedek

4 4

[block_ptr] Use case bug
by Phil Bouchard 18 Feb '16

18 Feb '16

In trying to anticipate all possible use cases, I think I have found a bug. Please let me try to fix it, but this is not so simple so it'll take some time.

1 1

[githelp]
by Rene Rivera 17 Feb '16

17 Feb '16

How can I find out what changes are not merged from develop to master, for all subrepos, but only changes I've made? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 3

Removal of boost::basic_string_ref (in favor of basic_string_view)
by Marshall Clow 17 Feb '16

17 Feb '16

I have just removed boost::basic_string_ref from the develop branch, and updated the specializations to use basic_string_view. Code that uses boost::string_ref (and wstring_ref) should continue to work as before. The basic_string_view class better matches what the standards committee is doing and has WAY more constexpr support. I'll be watching the testbots for results, but I believe that the only part of boost that was using basic_string_ref was Boost.Log, and that was switched over to basic_string_view in December. -- Marshall

2 1

Boost.Operators issue: polluting namespace of caller through argument-dependent lookup
by John M. Dlugosz 17 Feb '16

17 Feb '16

Here's the problem I ran into http://stackoverflow.com/questions/34449254/how-is-argument-dependent-looku… |usingstd::tr1::shared_ptr; ||usingstd::tr1::make_shared;| |shared_ptr<Dog>Gamma::knockout (constHotel&target){Eggsoftboiled (target.ID);softboiled.sequence ^=0x40000000;returnmake_shared<Dog>(softboiled,target.kin,Frank::myself());} | The arguments to the constructor passed through make_shared are of types |Able::Bravo::Charlie::Egg&,constuint32_t&,constFrank&| The use of make_shared is finding boost::make_shared as well as std::make_shared. The program doesn't use boost::shared_ptr and shouldn't need to know about it. It turns out that Frank is derived privately from boost::totally_ordered1 (and and Egg from boost::totally ordered). Some Boost header that's being used in this translation unit just happens to pull in Boost's shared_ptr stuff. It ends up effectively polluting the namespace of possible calls involving these types, thanks to argument-dependent lookup. Furthermore, which Boost headers include which will change from version to version. I have this problem show up much more in Boost 1.60 than I have in Boost 1.59. There is no easy way around it beyond qualifying the call make_shared, and I specifically want to avoid that so I don't litter the program with tr1's (this varies by compiler and version as to whether tr1 is required, prohibited, or optional, so I want it in one place.) I believe the proper thing to do, which is a very simple fix actually, is to define the mix-in classes like totally_ordered (and other things from Boost.Operators in particular) in a unique inner namespace, and then make aliases in the boost namespace where they are published as being found. namespace boost { *namespace inner_name_1 { * template<typename T, Typename U> partially_ordered { ⋯ }; // the entire guts of Boost.Operators can go here, I think. *} // end of inner isolating namespace** ** ** using inner_name_1::partially_ordered;* // etc. } This inner isolation technique should be SOP for any classes that are meant to be inherited from by user (non-Boost library) code. It would not hurt to also isolate classes that match the names of std library code, in general! This would, in general, prevent the libraries from interfering with each other and surprises popping up when using std components and pulling in Boost headers. —John ||

4 12

remove cached feature checks
by Oliver Kowalke 17 Feb '16

17 Feb '16

Hi, how is it possible to remove the cached feature checks? Boost.Config Feature Check: cxx11_constexpr : no (cached) b2 -a toolset=clang cxxflags="-std=c++11" does not re-check the features. Oliver

4 4

[block_ptr] 20% speed boost
by Phil Bouchard 17 Feb '16

17 Feb '16

> If I try out the latest modifications and I disable the threads then on > Linux I have: > > make: > auto_ptr: 2458626 ns > shared_ptr: 2685224 ns > block_ptr: 28300624 ns > > new: > auto_ptr: 2383605 ns > shared_ptr: 4992185 ns > block_ptr: 7979659 ns So I just added a specialization of the pool for GCC x86 and now block_ptr<> speeds up by 20%: make: auto_ptr: 2511658 ns shared_ptr: 2695469 ns block_ptr: 22547960 ns new: auto_ptr: 2369312 ns shared_ptr: 4991352 ns block_ptr: 6443925 ns Thanks, -Phil

1 2