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
-
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