Daniel Lemire
Daniel Lemire
It turns out we can already support such applications without changing the library. The real question is whether we want to document it. ```C++ #include "simdjson.h" #include #include using namespace...
@mbasmanova [Reproducing my answer](https://github.com/facebookincubator/velox/issues/8066#issuecomment-1857887251) here... In standard C++, we have 64-bit, 32-bit, 16-bit and 8-bit integers and well as 64-bit, 32-bit, and 16-bit floating-point integers. None of them can represent...
@richarddd I think that's what @Yuhta proposed in https://github.com/facebookincubator/velox/issues/8066#issuecomment-1858121217 PR invited.
I really like PR https://github.com/simdjson/simdjson/pull/2115 by @saleyn
> Why is this commented out? And wouldn't what is commented out essentially address this issue? Because it is incorrect. `!SIMDJSON_CAN_ALWAYS_RUN_ARM64` is true in two instances, when `SIMDJSON_CAN_ALWAYS_RUN_ARM64` is set...
I can try to do it.
We are openly calling for interested contributors. We don’t even have design documents at this point: what we want to do and how we are going to do it efficiently.
This PR is obsolete in its current state and is not being pursued. @zptan If you'd like to pick it up and complete it, that would be great.
> So it seems that we already can parse without copying + padding the original json You definitively can do as you describe but if the string is located near...
@mmomtchev What you write sounds reasonable. There are many ways to proceed, and it is likely that many different people will prefer different approaches.