Hi.
I've been trying to follow the conversation on adding a length limit to input streams to support parsing non null-terminated strings.
I see there are a few issues and even pull requests (most of them several years old) discussing the concept, and I see some support for it was finally added to master for the Parse() interface.
However.. nothing of the sort was ever done for ParseInSitu(), so the obvious question is why?
At my studio, we're mainly interested in doing insitu parsing for efficiency, so we really need support for this for cases where we cannot control the format of the input string. I could ofc modify the source code and put something together (the most straightforward solution would seem to be to do something like https://github.com/Tencent/rapidjson/pull/417/commits/58d72c7511026497f270c7d29c59dbfa5c31794d).
But the question remains.. why support this for read-only parsing but not in situ parsing? Is there anything I'm missing here?
Hi. I've been trying to follow the conversation on adding a length limit to input streams to support parsing non null-terminated strings. I see there are a few issues and even pull requests (most of them several years old) discussing the concept, and I see some support for it was finally added to master for the
Parse()
interface. However.. nothing of the sort was ever done forParseInSitu()
, so the obvious question is why?At my studio, we're mainly interested in doing insitu parsing for efficiency, so we really need support for this for cases where we cannot control the format of the input string. I could ofc modify the source code and put something together (the most straightforward solution would seem to be to do something like https://github.com/Tencent/rapidjson/pull/417/commits/58d72c7511026497f270c7d29c59dbfa5c31794d).
But the question remains.. why support this for read-only parsing but not in situ parsing? Is there anything I'm missing here?