Comments (12)
Do you want the user-provided string_view
to contain the literal or converted value?
from trial.protocol.
Do you want the user-provided
string_view
to contain the literal or converted value?
The converted/decoded value. My current literal-using code obviously does something bad and should not be encouraged. The built-in function should do the right thing and decode current value character by character while it compares with the user provided string.
from trial.protocol.
Using the converted value requires allocation.
from trial.protocol.
But it's a specialized use. It's not delivering the value for the user to do as he wishes. It's only checking if it's equal to a specific string.
Decoding can be done char-by-char. As it decodes, it checks against the user-provided string. Buffering a single char (or a few, it doesn't matter) doesn't require allocation. The past decoded chars are forgotten as the comparison goes on.
from trial.protocol.
Such a change would be quite intrusive.
from trial.protocol.
Such a change would be quite intrusive.
Do you mean implementation-wise or interface-wise? I'll take a look at the trial.protocol codebase later.
from trial.protocol.
Implementation-wise.
A better solution would be to convert the search string to JSON using json::writer
during initialization and then compare this with the literal value. Long term we could even have a constexpr string-to-JSON conversion functions for this purpose.
from trial.protocol.
A better solution would be to convert the search string to JSON using
json::writer
during initialization and then compare this with the literal value. Long term we could even have a constexpr string-to-JSON conversion functions for this purpose.
I'm not sure we're on the same page. I'll try to explain the problem again.
Suppose I have the following C++ type:
struct MyType
{
int x;
std::string y;
};
And the following JSON should be mapped to the C++ type:
{
"x": 33,
"y": "some string"
}
Now, when reader
points to the "x"
value, I only want to know if reader
is pointing to "x"
or pointing to "y"
. Currently, I compare the literals. This approach fails because there are multiple literals that can map to the same decoded value. For instance, the received JSON could be the following:
{
"\u0078": 33,
"\u0079": "some string"
}
When reader
is pointing to "some string"
I can use reader.value<std::string>()
and live with that. There isn't much I can do. But when I already know the decoded value, I could use some function that does the comparison directly.
bool is_equals(const json::reader& reader, std::string_view search)
{
auto value = reader.literal();
value.remove_prefix(1);
value.remove_suffix(1);
for (;;) {
if (value.size() == 0 && search.size() != 0)
return false;
auto c = decode_and_consume_char(value);
if (c != search[0])
return false;
}
}
The pseudo-code is incomplete and it isn't handling the error cases properly, but should already give an idea of what I'm talking about.
A better solution would be to convert the search string to JSON using
json::writer
during initialization and then compare this with the literal value. Long term we could even have a constexpr string-to-JSON conversion functions for this purpose.
I don't follow. The literal value is harder to compare because there are multiple literal values that can map to a single decoded value.
from trial.protocol.
Ah, I understand.
from trial.protocol.
We discussed off-line to add a "string collector" function to json::reader
which takes a template collector function. This can be used to either store the converted string in an std::string
, a fixed sized array, or to compare against another string.
This has been committed in 0f1d2d8. The decoder test suite shows a comparison example.
from trial.protocol.
I'm busy with some stuff. Will have time to take a deeper look later.
from trial.protocol.
I managed to use the string collector API successfully. Closing the issue.
Next, I'll take a look at #16. I already have a working prototype, but I have to fill a few holes before presenting it for discussion.
from trial.protocol.
Related Issues (20)
- Change Allocator template to Allocator type HOT 1
- AllocatorAwareContainer HOT 4
- Use to_address() HOT 2
- Do not inherit from allocator HOT 1
- Use error specializations thoroughly HOT 1
- reader.value<std::string>() should allow the allocator to be provided HOT 5
- String collector API should only be noexcept if `Collector()` is noexcept HOT 11
- Parser gets confused on non-NULL terminated string HOT 1
- Isn't boost::serialization::nvp missing in serialization support? HOT 1
- Literal whitespace vs literal node HOT 7
- Split symbol::string and symbol::object_key events HOT 3
- Tests fail to build on boost 1.76 HOT 6
- Reader algorithms on chunk_reader HOT 4
- Parsers combinators HOT 7
- Merged matching & decode on Boost.Hana serialization
- Use asciidoc to document new pages HOT 4
- fails to build with latest visual studio
- Issues with constness in std::make_pair HOT 4
- Generator for real numbers shouldn't print the fractional part if there is none HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from trial.protocol.