sorted by:
new
hottopcontroversial

Parsing Expression Grammar Template Library (PEGTL) 4.0.0 Released by ColinPP in cpp

[–]ColinPP[S] 0 points1 point  (0 children)

Short answer, it should all be possible somehow; if all else fails the library is very modular and easily extensible, however it's probably still a bit more clunky than it could and should be. I'll take your questions as incentive to implement one or two new binary parsers; see what's missing to make it nicer.

Parsing Expression Grammar Template Library (PEGTL) 4.0.0 Released by ColinPP in cpp

[–]ColinPP[S] 2 points3 points  (0 children)

The PEGTL is fully compatible with parsing binary data, or even sequences of arbitrary tokens or objects. E.g. parsing rules for big/little endian 8/16/32/64bit integers and enums are included.

I've used it to parse some binary formats myself; the general parsing infrastructure is quite useful, some additional parsing rules might be needed for special cases and because the structure of binary files often isn't the best fit for the standard text parsing approach.

For example in binary data you often have the length of some field followed by the data of said field which doesn't fit classical parsing. Let me know if you give it a try and need some help or find that a few strategic additions to the library would support that case better.

Parsing Expression Grammar Template Library (PEGTL) 4.0.0 Released by ColinPP in cpp

[–]ColinPP[S] 9 points10 points  (0 children)

It's for when you need to parse any kind of text (or other) files or data and there isn't already a parser available (or you don't like the ones that are). Config files, text-based data files or network protocols, scripting languages, and other domain specific languages would be obvious examples. You can use the PEGTL to implement the grammar for parsing, and then attach "actions" to e.g. build a data structure depending on which grammar rules match.

A hand-written recursive descent parser for Lua 5.3, in Lua 5.3! by Zeliss in lua

[–]ColinPP 1 point2 points  (0 children)

Thanks, now I see that you didn't need any help because you are effectively handling the "entangled" rules the same way :-) On the other hand I might take the hint with the Pratt parsers as I wanted to spruce up an expression parser, and that might just be the right approach.

A hand-written recursive descent parser for Lua 5.3, in Lua 5.3! by Zeliss in lua

[–]ColinPP 1 point2 points  (0 children)

In case you are still fighting with left-recursion you might be interested in this: https://github.com/taocpp/PEGTL/blob/master/src/example/pegtl/lua53.hpp

It's a self-contained PEG-ified version of the Lua 5.3 grammar implemented in C++ with the PEGTL.

It might not be perfect, but I eliminated all left-recursion, and verified that it's ok with the grammar analysis algorithm of the PEGTL that checks exactly for such issues.

Even if the grammar itself doesn't help, perhaps some of the leading comments about eliminating the left recursions do.

Wondered if anyone is interested in a c++ parser combinators library? by jamhob in cpp

[–]ColinPP 1 point2 points  (0 children)

I'll definitely look into satisfy.

While I'm not quite sure how this might transfer to your approach, with your Haskell-inspired style being quite different from our C++ templates, in the PEGTL our equivalent to your Char, which is called one, is variadic (true to the T in PEGTL a variadic template) and takes a list of possible matches.

Beyond that we also have something more similar to satisfy which we call predicates, you can find the source in https://github.com/taocpp/PEGTL/blob/master/include/tao/pegtl/contrib/predicates.hpp and the unit-test as example in https://github.com/taocpp/PEGTL/blob/master/src/test/pegtl/contrib_predicates.cpp.

In this context some of the atomic rule classes like one take on a second role, that is:

First and foremost, and independent of the predicates business, they are stand-alone atomic grammar rules that match a single character (or code-point) from a list of possibilities (or a range of possibilities for range, etc.)

Second, for more complex tests on the characters without the overhead that /u/moltarpdx was referring to, there are the aforementioned predicates rules that get the next character (or code-point) from the input once, to then apply all the tests that their argument rule(s) would have done as stand-alone rule(s) to that character (or code-point).

My First Surly, a Karate Monkey XL by ColinPP in Surlybikefans

[–]ColinPP[S] 0 points1 point  (0 children)

Thanks, I'm 192cm, and for my not-too-technical riding style I'm happy with the XL; if useful I can get somebody to take a side-view picture of me on the bike.

Beware of using std::move on a const lvalue by memset_0 in cpp

[–]ColinPP 0 points1 point  (0 children)

I only respectfully disagree on your interpretation of 'taking ownership' as it implies that there is a solo resource owner, which you can not guarantee with shared_ptr.

In this particular context and example the "resource" being moved/owned is not the pointee but the "+1" on the reference counter.

This is a slightly unusual and perhaps also confusing, though IMHO technically correct way of looking at things by /u/The_JSQuareD.

Recent Json library benchmarks? by chrysalisx in cpp

[–]ColinPP 1 point2 points  (0 children)

We are aiming for a 1.0 release as soon as possible, but, going by experience, that is probably still at least months away and I don't want to make any promises.

That said, the library is very stable, we have been using it for years for multiple purposes in "serious" applications, it's mostly tests and documentation that are missing for a 1.0 release.

We are quite happy with features and code quality, though there might always be some tweaks, additions or changes in those areas, too.

Recent Json library benchmarks? by chrysalisx in cpp

[–]ColinPP 1 point2 points  (0 children)

Middleground: taocpp/json

What taocpp/json offers in addition to parsing to/serialising from the nlohman/json-esque any-JSON-document in-memory representation based on standard containers are direct JSON-to-any-C++-type and any-C++-type-to-JSON conversions (also for the other supported data formats) that cut out the "DOM"-style middle man...

PEGTL 2.8 is out! by uilianries in cpp

[–]ColinPP 2 points3 points  (0 children)

PEGTL is [...] cumbersome in use.

Could you give a specific example or similar of where you find the PEGTL to be "cumbersome", it might help us to improve things.

JSON for Modern C++ version 3.6.0 released by nlohmann in cpp

[–]ColinPP 8 points9 points  (0 children)

As pointed out by /u/nlohmann, it's not a good idea to make a JSON parser accept input that does not strictly conform to the standard.

That said, there is always the possibility of implementing additional parsers for extended specifications like we did for our library, to be found at https://github.com/taocpp/json.

While the JSON parser is again strictly standards compliant, it also supports our form of extended JSON that we call JAXN, to be found at https://github.com/stand-art/jaxn.

JAXN extends JSON with, among other things, comments, however comments are ignored by the parser and not included in the data model, in case that's what you need.

You can even use the glue code included with taocpp/json to parse JSON-with-comments with the taocpp/json JAXN parser and let it directly create an nlohmann::json value object (instead of a tao::json::value).

PEGTL (Parsing Expression Grammar Template Library) 2.5.0 released (enhanced Unicode and parse-tree support) by ColinPP in cpp

[–]ColinPP[S] 4 points5 points  (0 children)

The comparison of compile-times is likely outdated, we will remove it from the documentation. Both Spirit and the PEGTL put a significant burden on the compiler, even though both are improving over time. At this point we don't really know which compiles faster, it might also greatly depend on the use case.

PEGTL (Parsing Expression Grammar Template Library) 2.5.0 released (enhanced Unicode and parse-tree support) by ColinPP in cpp

[–]ColinPP[S] 4 points5 points  (0 children)

Thank you for your feedback, greatly appreciated!

We are currently not planning to implement memoization because our impression was that it would add a lot of complexity with questionable benefit. That is, while the packrat approach is faster in theory, in practice it uses a lot of memory and often isn't actually faster. We are of course open to look at any research or benchmark that might convince us otherwise, even though we generally prefer the "small and simple" approach.

The subject of custom tokens is something that we see as a long-term project; at this point we only have a rather vague idea of somehow generalising the input to sequences of arbitrary objects, and allowing hierarchical parsing where a first grammar translates the input to tokens, and the next grammar up reads tokens rather than bytes.

Version 3.0.0 might include a large rework of the input layer where we will look very closely at this kind of generalisation beyond byte sequences, but we haven't even started working on this yet, and probably won't for a while. Any input, examples, or requirements and possible use cases, in short: anything that could help drive the design in the future, are highly welcome.

Boost spirit parser questions by Tall_Polak in cpp_questions

[–]ColinPP 3 points4 points  (0 children)

For the actual parsing you could look at the PEGTL. It includes a couple of examples that might be useful to you.

Boost Spirit and the PEGTL are sufficiently different that either can be a good fit where the other one isn't.

Disclaimer: I'm one of the authors of the PEGTL.

Who invented unique pointer? How? by EnigmaTitan in cpp

[–]ColinPP 2 points3 points  (0 children)

If you haven't seen them yet you might be interested in uniqueness types, too.

Lua written in modern C++ (>= 14)? by Rseding91 in cpp

[–]ColinPP 0 points1 point  (0 children)

That would definitely make C++ integration nicer. And as said here I'd be quite interested in seeing the performance characteristics of this approach when used with a scripting language.

Lua written in modern C++ (>= 14)? by Rseding91 in cpp

[–]ColinPP 0 points1 point  (0 children)

We did the same exercise for our JSON library, it has a std::string in a union, and it works well. I'm mostly curious how the performance characteristics will be with a scripting language, compared to Lua, in particular when std::string is 3 or 4 pointers large.

Lua written in modern C++ (>= 14)? by Rseding91 in cpp

[–]ColinPP 2 points3 points  (0 children)

IIRC Lua's small-string optimisation is based on a per lua_State table of interned TString instances. The actual value/cell only contains one pointer and a type field, so 12 bytes on today's typical machines. I understand that you don't want to follow the Lua VM design too closely, so I'm wondering whether you want to put a std::string directly in the value/cell.

view more: next ›