Re: [boost] proposed new library "histogram"
On 05/05/2016 12:21 AM, Hans Dembinski wrote:
I suggest that you use non-intrusive serialization and place that in separate headers, so there is no dependency on Boost.Serialization unless you need it.
I suggest that you use non-intrusive serialization and place that in separate headers, so there is no dependency on Boost.Serialization unless you need it.
Dear Bjorn, On 6/5/16 4:03 AM, Bjorn Reese wrote: thank you for your comment and your interest in this library! :) Could you tell me, what would be the advantage of non-intrusive serialization? Boost.serialization is an integral part of Boost, so I am not sure why it would be useful to not require Boost.Serialization as a dependency? Boost.Serialization is used to implement the pickle protocol in the python interface for this library. So if you want to build the Python interface, you need Boost.serialization anyway. The proposed library histogram is modeled after existing libs in Boost. If you look into include/boost/numeric/ublas/vector.hpp, you will see that the serialize function is also part of the public interface of class vector. In fact, I would like to see more more boost classes with serialize methods. Best regards, Hans -- Hans Dembinski https://github.com/HDembinski
Hi, I noticed that both vector and matrix in boost::numeric::ublas have a serialize methods, but triangular_matrix and symmetric_matrix do not. Is there a reason for that, or is it an oversight? I think it would be great if more boost classes came with serialize methods out of the box. Best regards, Hans -- Hans Dembinski https://github.com/HDembinski Proposed for Boost: histogram https://github.com/HDembinski/histogram Automatic one-dimensional unfolding of data distributions https://github.com/HDembinski/aru-unfolding
On 06/06/2016 11:12 PM, Hans Dembinski wrote:
Could you tell me, what would be the advantage of non-intrusive serialization? Boost.serialization is an integral part of Boost, so I am
Faster compilation times because the serialization headers are not included, and faster linker times because the serialization library does not have to be read by the linker.
not sure why it would be useful to not require Boost.Serialization as a dependency? Boost.Serialization is used to implement the pickle protocol in the python interface for this library. So if you want to build the Python interface, you need Boost.serialization anyway.
I am not suggesting that you remove support for serialization. Instead I am suggesting that you keep serialization in a separate header, so your library users only pays the price when they need it.
The proposed library histogram is modeled after existing libs in Boost. If you look into include/boost/numeric/ublas/vector.hpp, you will see that the serialize function is also part of the public interface of class vector.
And others like Multiprecision keeps non-intrusive serialization functions in separate headers.
Dear Bjorn, On 6/18/16 8:11 AM, Bjorn Reese wrote:
I am not suggesting that you remove support for serialization. Instead I am suggesting that you keep serialization in a separate header, so your library users only pays the price when they need it. Ok, that makes sense, thanks for explaining, I was not aware that serialization has such a big impact on compilation time. Klemens Morgenstern is currently giving histogram a good overhaul and he already implemented your suggestion as part of many other improvements. Thank you, Klemens!
Best regards, Hans -- Hans Dembinski https://github.com/HDembinski Proposed for Boost: histogram https://github.com/HDembinski/histogram Automatic one-dimensional unfolding of data distributions https://github.com/HDembinski/aru-unfolding
participants (2)
-
Bjorn Reese -
Hans Dembinski