boost::serialization optional does not use boost::serialization::access
Hi, this simple program will not compile. The only way to make it
work is to make a public default constructor. This defeats the purpose
of boost::serialization::access.
I tried to fix
On 7/21/19 1:24 PM, Janek Kozicki via Boost wrote:
Hi, this simple program will not compile. The only way to make it work is to make a public default constructor. This defeats the purpose of boost::serialization::access.
please open up an issue in the serialization libary at github so we don't lose track of it. Robert Ramey
On 7/23/19 2:19 PM, Robert Ramey via Boost wrote:
On 7/21/19 1:24 PM, Janek Kozicki via Boost wrote:
Hi, this simple program will not compile. The only way to make it work is to make a public default constructor. This defeats the purpose of boost::serialization::access.
please open up an issue in the serialization libary at github so we don't lose track of it.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Speaking from memory, I think the purpose of serialization::access is to provide accesses to the serialization functions rather then all the functions. Also if memory serves me, this issue has come up before and we went through some efforts to address it but in the end couldn't make it work. You might want to check the history of the serialization of optional in git hub Robert Ramey
Hi, thank you for your reply. I created an issue: https://github.com/boostorg/serialization/issues/165 And a pull request: https://github.com/boostorg/serialization/pull/166 best regards Janek Kozicki Robert Ramey via Boost said: (by the date of Tue, 23 Jul 2019 15:20:16 -0700)
On 7/23/19 2:19 PM, Robert Ramey via Boost wrote:
On 7/21/19 1:24 PM, Janek Kozicki via Boost wrote:
Hi, this simple program will not compile. The only way to make it work is to make a public default constructor. This defeats the purpose of boost::serialization::access.
please open up an issue in the serialization libary at github so we don't lose track of it.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Speaking from memory, I think the purpose of serialization::access is to provide accesses to the serialization functions rather then all the functions. Also if memory serves me, this issue has come up before and we went through some efforts to address it but in the end couldn't make it work. You might want to check the history of the serialization of optional in git hub
Robert Ramey
I managed to detect if there is a not public default constructor. So now we have old (fast) behavior if there is a public constructor and the workaround behavior if the constructor is private. So no loss in performance. Now the only problem is that it works only in C++17. We need to find a way to make it work on older compilers. https://github.com/boostorg/serialization/pull/166 I know it's still a long way to go. But we are closer to removing this regression and restoring old behavior. best regards Janek Janek Kozicki said: (by the date of Wed, 24 Jul 2019 19:01:42 +0200)
Hi, thank you for your reply.
I created an issue: https://github.com/boostorg/serialization/issues/165 And a pull request: https://github.com/boostorg/serialization/pull/166
best regards Janek Kozicki
Robert Ramey via Boost said: (by the date of Tue, 23 Jul 2019 15:20:16 -0700)
On 7/23/19 2:19 PM, Robert Ramey via Boost wrote:
On 7/21/19 1:24 PM, Janek Kozicki via Boost wrote:
Hi, this simple program will not compile. The only way to make it work is to make a public default constructor. This defeats the purpose of boost::serialization::access.
please open up an issue in the serialization libary at github so we don't lose track of it.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Speaking from memory, I think the purpose of serialization::access is to provide accesses to the serialization functions rather then all the functions. Also if memory serves me, this issue has come up before and we went through some efforts to address it but in the end couldn't make it work. You might want to check the history of the serialization of optional in git hub
Robert Ramey
-- # Janek Kozicki http://janek.kozicki.pl/
participants (2)
-
Janek Kozicki -
Robert Ramey