Replies: 2 comments 4 replies
-
Interesting idea. The issue appears to be that class C;
using t1 = std::vector<C>::iterator; // OK
using t2 = boost::container::small_vector<C,5>::iterator; // Incomplete type is not allowed |
Beta Was this translation helpful? Give feedback.
0 replies
-
Currently, using object_iterator = jsoncons::detail::random_access_iterator_wrapper<typename object::iterator>; where the iterator wrapper holds an |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Much like the boost::interprocess::vector example, I am trying to have an implementation policy that uses boost::container::small_vector and having trouble using it. Small vector is a vector where, up to a given size, the elements are statically allocated, and passed that size, they are dynamically allocated. The main problem seems to be that, unlike std::vector and boost::interprocess::vector, boost::container::small_vector needs to know the size of the template type at template instantiation time. That seems to cause a problem because basic_json needs the array declaration to get at the array::iterator declaration, and the array needs basic_json to figure out the size of the elements for static allocation.
Context is that I am trying to avoid heap allocations for coordinates for large GeoJSON objects that have several coordinates. I have considered using a custom allocator instead to avoid the repeated heap allocations, but I don't really have a good spot to manage the allocation pool and would have preferred simply avoiding the heap altogether for small objects. Worst case, I will likely fallback to the custom pool, but the small vector feels cleaner to me, so I figured I'd ask if anyone has something I hadn't considered to offer.
Any advise as to how I might be able proceed?
Beta Was this translation helpful? Give feedback.
All reactions