On Mon, Dec 9, 2019 at 6:30 AM Bjorn Reese via Boost
then the following wrapper
Yeah, that's a different use-case. A legitimate one but not the one that my library solves, and not one that I have an interest in solving.
namespace trial { namespace protocol { namespace serialization {
I keep seeing this Trial.Protocol but the library being proposed (which has no review manager yet) is Boost.JSON. It has not yet been proven that a token-at-a-time parser can yield the same performance and incremental behavior features as the one provided in Boost.JSON. Of course, if you would like to incorporate support for Trial.Protocol in the benchmark for comparison I encourage it. Simply implement `any_impl` for your algorithms and add it to the vector in main: https://github.com/vinniefalco/json/blob/develop/bench/bench.cpp It also seems unfortunate that we have taken a hard turn into the discussion of Boost.Serialization which I have to stress is not a contemplated use-case for this library (although it would certainly be possible to implement an archive for it). I am very interested in hearing about things which do land within the use-case, especially things which can be an improvement, as suggestions for improvements of Boost.Serialization-related uses are not particularly helpful (again, because Boost.Serialization is not a contemplated use-case). To get such a conversation started, here are some possible topics: * The design of boost::json::storage and boost::json::storage_ptr * Usability of the customization points for going to/from user defined types * The individual boost::json::object, boost::json::array, and boost::json::string classes * DOM API An even better technique for discovering topics of conversation would be to actually use the library and give feedback... has anyone done that?
Do you have a reference to how these stackless-with-bounded-stack coroutines works?
Nothing handy but there are many videos, blog posts, and wg21 papers about coroutines (search for "Coroutines TS"). Thanks