- Boost - lists.boost.org

Headers only or .o
by Damian Vicino 15 Mar '21

15 Mar '21

Hi, I was reading the development section of the docs: https://www.boost.org/development/index.html And, I noticed there was nothing in the development guidelines about when to implement as headers-only vs built library. I got my own ideas of why most libraries are headers-only. But, I was wondering if someone with the historical context (someone who was here when those first libraries were developed) can share how boost got into the current shape and what new library developers should look into when deciding to go headers-only or not. I appreciate any anecdotes, guidelines, tradeoffs, thumb rules, comments on the topic. I would love to collect as much as possible here in this thread and write something to post in the development doc section in the website for future reference. Best, Damian

4 4

[Describe] Review - Part 2: Class types
by Andrzej Krzemienski 15 Mar '21

15 Mar '21

Hi Everyone, Some feedback from playing with Boost.Describe for class types. 1. As others pointed out, it is confusing that BOOST_DESCRIBE_STRUCT() and BOOST_DESCRIBE_CLASS() have such close names, but their interface and requirements are so different. Maybe rename the latter to BOOST_DESCRIBE_THIS_CLASS()? 2. Base class subobjects are in some applications treated equivalently to member subobject; this is why I found it surprising that I cannot get the names of base class subobjects. But I guess there are implementation difficulties. Bases can be qualified names. 3. As with enums, _public_member_descriptor_fn in global namespace is UB or invalid program as per http://eel.is/c++draft/lex.name#3.2. 4. As others pointed out, the part of the interface that uses enum modifiers is not intuitive. I think that after a while it starts to make sense: you decide on your use case (like doing RPC), form your enum bitmask, and then pass it everywhere. It became more-less clear to me only after I had a look at the implementation of member_filter: https://github.com/pdimov/describe/blob/develop/include/boost/describe/memb… Maybe it makes sense to expose this in the docs. 5. Modifier mod_inherited is great for flattening the inheritance structure: struct X { int a; }; struct Y : X { int b; }; struct Z : Y { int c; }; BOOST_DESCRIBE_STRUCT(X, (), (a)); BOOST_DESCRIBE_STRUCT(Y, (X), (b)); BOOST_DESCRIBE_STRUCT(Z, (Y), (c)); int main() { namespace desc = boost::describe; using namespace std::literals::string_literals; constexpr auto mod = static_cast<desc::modifiers>(desc::mod_public | desc::mod_inherited); using L = desc::describe_members<Z, mod>; assert((boost::mp11::mp_at_c<L, 0>::name == "a"s)); assert((boost::mp11::mp_at_c<L, 1>::name == "b"s)); assert((boost::mp11::mp_at_c<L, 2>::name == "c"s)); } But it is not obvious at first. I recommend that the docs provide an example like this. It even works when base classes have members with same names: struct X { int a; }; struct Y { int a; }; struct Z : X, Y { int b; }; BOOST_DESCRIBE_STRUCT(X, (), (a)); BOOST_DESCRIBE_STRUCT(Y, (), (a)); BOOST_DESCRIBE_STRUCT(Z, (X, Y), (b)); int main() { constexpr auto mod = static_cast<describe::modifiers>(describe::mod_public | describe::mod_inherited); using L = describe::describe_members<Z, mod>; Z z = {{{3}}, {{6}}, {9}}; assert((z.*mp_at_c<L, 0>::pointer == 3)); assert((z.*mp_at_c<L, 1>::pointer == 6)); assert((z.*mp_at_c<L, 2>::pointer == 9)); } 5. What is the use case for modifier mod_hidden? I cannot think of any situation where I would need it. 6. Regarding the overloaded functions, I am no expert in preprocessor metaprogramming, but maybe if there was a way to provide function signatures along the name, you would have enough information to form the pointers. Something like: struct X { void f(int){} void f(void*){} }; BOOST_DESCRIBE_STRUCT(X, (), ( SIGNATURE(void f(int)), SIGNATURE(void f(void*)) ); 7. Modifier mod_virtual works unintuitively. It does not affect the filtering in describe_bases<>. It is only used for decorating the list elements. Maybe the docs should be more explicit about what it is used for. Again, is there a use case for this? Regards, &rzej;

4 4

GSoC'21 boostorg timeline
by Krushnal Patel 15 Mar '21

15 Mar '21

Hi, I wanted to inquire about the GSoC'21 timeline specific to boostorg. I have gone over the GSoC'21 timeline but are there any specifics decided by boost regarding project selection, pre-proposal submission, proposal overview, programming competency test submission, etc? I am asking this question because as I was going over last years' mailing list I found a post where 'pre-proposal submission' was discussed so I started researching more about any timeline released specifically by boost but did not find any. Thanks in advance. Krushnal Patel, http://krushnal.me/

2 1

Requirement of mentorship for Generic Image Library project
by Aditya Tiwari 15 Mar '21

15 Mar '21

Hello there, I am Aditya Tiwari, a GSoC aspirant. I am interested in contributing to the Boost C++ library on the project "*Generic Image Library*". The knowledge requirement for this project is C++ and understanding of basic image processing algorithms, and I have a good knowledge of these two. I have been coding in C++ for over two years, with prior experience working with Boost libraries and working on projects related to image processing for over 1 year. I have read the problem statement and under GIL there's a project 2 about implementing image processing algorithms and in that list I know quite a bunch of algorithms. Also the project 1 under GIL, is quite a confusing task for me like do we have to add more and efficient algorithms here or something else? It would be very helpful if you can guide me through this project. I am open to any suggestions and I shall proceed with the task upon your acknowledgement. Regards, Aditya

2 1

Re: [boost] [release] Boost 1.76.0 Beta 1 Release Candidate 1: fixed std::allocator deprecation-warning
by Löw, Tobias (STEAG Energy Services GmbH) 15 Mar '21

15 Mar '21

Hi, I've made a fix for the deprecation-warning: boost\unordered\detail\implementation.hpp(1452,7): warning C4996: 'std::allocator<T>::is_always_equal': warning STL4010: Various members of std::allocator are deprecated in C++17. Use std::allocator_traits instead of accessing these members directly. You can define _SILENCE_CXX17_OLD_ALLOCATOR_MEMBERS_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning. The PR is here: https://github.com/boostorg/unordered/pull/21 Tobias

1 0

[release] Boost 1.76.0 Beta 1 Release Candidate 2
by Marshall Clow 13 Mar '21

13 Mar '21

The second release candidates for the 1.76.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.76.0.beta1/source/> The SHA256 checksums are as follows: c32edd34f767dd4bb67b86f76ebf58cf76822a5993a9b434c028b2dd08cfeefc boost_1_76_0_b1_rc2.zip eb098d6d5352e10b17a3c49d2927ed61f09b6544f7c534627de35dfa2560fe20 boost_1_76_0_b1_rc2.tar.bz2 39eecd9672e78b95c8e3fdec1430a63788d528a66d3c8799c4639238e5d785bd boost_1_76_0_b1_rc2.7z 3ec1f92fa0a159b7073e39dd88f527a55d1f35e8986a3c560f202a75bdb8d584 boost_1_76_0_b1_rc2.tar.gz The only changes from RC1 is an update to Boost.Interprocess, which was failing to compile on Mac OS X. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

2 2

Master branch now closed for 1.76.0 beta release
by Marshall Clow 13 Mar '21

13 Mar '21

Please do not make any commits to the master branch. — Marshall

2 2

Re: [boost] FFT proposal for gsoc 2021
by Janek Kozicki 13 Mar '21

13 Mar '21

> Strongly and beneficially Influence that. But we still need > To adhere to all formal application Steps A note regarding these formal steps: https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-2021 https://lists.boost.org/Archives/boost/2021/02/250876.php https://www.boost.org/users/faq.html > On the board. I can do 1 mentor of Either quad double or FFT. Yeah, both of them are very useful for me. If we make FFT this year, we can hope for quad-double next year :-) best regards Janek Christopher Kormanyos said: (by the date of Fri, 12 Mar 2021 16:00:38 +0100) > We still need to adhere to the > Formal application process > And we should have our dialog > On the board. I can do 1 mentor of > Either quad double or FFT. > > Having your own idea and a > Working model is a tremendous > Advantage in the application > Process and is likely to very > Strongly and beneficially > Influence that. But we still need > To adhere to all formal application > Steps > > Kindest regards, Chris > > Sent from my iPhone > > > On 12. Mar 2021, at 07:26, Eduardo Quintana <eduardo.quintana(a)pm.me> wrote: > > > > Dear Christopher, > > > > I am thrilled to hear from you! Thank you for offering mentorship for this > > project. I look forward to start working on it. > > > > Best regards, > > Eduardo > > > >> On Thu, Mar 11, 2021 at 06:55:37PM +0000, Christopher Kormanyos wrote: > >> > >> <html><head></head><body><div class="ydpad5c413ayahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div> > >> <div dir="ltr" data-setdir="false"><div>> Hi Boost community,<br><div>> I've been working on a C++ templated library</div><div>> for Fast Fourier Transforms</div><div><br></div><div>> ...<br></div></div><div dir="ltr" data-setdir="false"><span>> Is there anyone interested in supervising this</span></div><div dir="ltr" data-setdir="false"><span>> project? Any opinions?</span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>Thank you for your interest and query.<br></span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>Yes. I think I am interested and potentially qualified</span></div><div dir="ltr" data-setdir="false"><span>as 5 time GSoC mentor in Multiprecision and Math.</span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>The plan seems good, start with header only</span></div><div dir="ltr" data-setdir="false"><span>simple implementation and increase complexity</span></div><div dir="ltr" data-setdir="false"><span>and efficiency as time allows.</span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>This project would fill a present gap and wish list</span></div><div dir="ltr" data-setdir="false"><span>entry in Math/Multirpecision for those unable/unwilling</span></div><div dir="ltr" data-setdir="false"><span>to include FFTW.</span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>I will write a little project description at rthe relevant</span></div><div dir="ltr" data-setdir="false"><span>page, link will follow...<br></span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>Feel free to continue this thread, at the moment, i'm</span></div><div dir="ltr" data-setdir="false"><span>too busy to put down all my thoughts...<br></span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false"><span>Kind regards, Christopher</span><br></div></div><div><br></div> > >> > >> </div><div id="yahoo_quoted_5520563993" class="yahoo_quoted"> > >> <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;"> > >> > >> <div> > >> On Thursday, March 11, 2021, 10:55:29 AM GMT+1, Eduardo Quintana via Boost <boost(a)lists.boost.org> wrote: > >> </div> > >> <div><br></div> > >> <div><br></div> > >> <div>Hi Boost community,<br><br>I've been working on a C++ templated library for Fast Fourier Transforms,<br>https://github.com/Lagrang3/fftx.<br>Templated because some FFT algorithms are algebraic-field independent, eg. you<br>could FFT an array of N matrices provided a Nth matrix-root-of-unity is given.<br>As a result you could have a single algorithm for a variety of underlying, eg.<br>`std::complex<float>`, `std::complex<double>`, `std::complex<long double>`,<br>`boost::math::quaternion`, finite field types (this would yield the "Number<br>theoretic transform" <a href="https://cp-algorithms.com/algebra/fft.html#toc-tgt-6" target="_blank">https://cp-algorithms.com/algebra/fft.html#toc-tgt-6</a>).<br><br>I would like to improve this library during the GSOC 2021, as a proposal for<br>inclusion inside Boost.Math or Boost.Algorithms.<br><br>Is there anyone interested in supervising this project? Any opinions?<br><br>Best regards,<br>Eduardo Quintana<br><br>_______________________________________________<br>Unsubscribe & other changes: <a href="http://lists.boost.org/mailman/listinfo.cgi/boost" target="_blank">http://lists.boost.org/mailman/listinfo.cgi/boost</a><br></div> > >> </div> > >> </div></body></html> > > <publickey - eduardo.quintana(a)pm.me - 341e5416.asc> > -- -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdańsk University of Technology Faculty of Applied Physics and Mathematics Department of Theoretical Physics and Quantum Information -- http://yade-dem.org/ http://pg.edu.pl/jkozicki (click English flag on top right)

1 0

[GIL] 2D Convolution/Correlation Proposal for gsoc 2021
by Gaurav kumar 12 Mar '21

12 Mar '21

Hi, I am Gaurav Kumar; I have been working on the Boost.GIL library for the past month. I would like to work on the 2D convolution/Correlation project. The ideas for the project are as follows: 1. Separable Kernels <http://www.dspguide.com/ch24/3.htm>: Most of the standard kernels (e.g. Gaussian, Sobel) can be separated into 2 or more 1D filters. For a N x N kernel, separating it into two 1D filters, the number of computations required would now be proportional to 2*N instead of N*N for the naive implementation. This implementation would also favor code reusability as this would only require a kernel separating function and driver code for a group of 1D filters. 2. Generic Implementation for 2D convolution: There are more generic kernels that are non-separable (e.g. Laplacian operator). In this case, the naive approach has already been implemented. The main task would be to provide the same set of functions as in the 1D convolution/correlation implementation. One potential idea for optimization of 2D convolution is to use the Im2col <https://www.programmersought.com/article/6306124604/> operation, in which the input image is converted into a row of column vectors, where each column vector represents an image block for which convolution/correlation operation is to be performed. The kernel can also be flattened out in a similar manner, resulting in a 1D array. This results in the convolution operation being reduced to matrix multiplication, which can be handled efficiently by BLAS libraries <https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms> ( Boost.uBLAS ). Please share any suggestions you would have, related to the ideas presented above, or regarding 2D convolutions in general. I am looking for a mentor to guide me through this project. Best Regards, Gaurav Kumar Github handle: https://github.com/gkumar28

2 1

[release] Boost 1.76.0 Beta 1 Release Candidate 1
by Marshall Clow 12 Mar '21

12 Mar '21

The first release candidates for the 1.76.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.76.0.beta1/source/> The SHA256 checksums are as follows: a222d325cd3c9f66951ec9026eca6ff6f48dd563c9a025911d598d2aca8770ce boost_1_76_0_b1_rc1.tar.bz2 6b90b510a3de38fc30a071ac798da37545fb60a1d6b21aed1130b47c9c598977 boost_1_76_0_b1_rc1.zip b01627bd9ce934b092037da81696bb4482a44e6a31c8791dbed82eafe04b69fa boost_1_76_0_b1_rc1.tar.gz dbef57adbab1d4395d14000f0a2420fc82f87476e10d48359ceff7125a74b77a boost_1_76_0_b1_rc1.7z As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

7 10