ANTLR 解析器生成器是否最适合内存受限的 C++ 应用程序? [英] Is the ANTLR parser generator best for a C++ app with constrained memory?

问题描述

我正在寻找一个好的解析器生成器，我可以用它在我们的大型商业应用程序中读取自定义文本文件格式.目前，这种特殊的文件格式是通过手工递归解析器读取的，但该格式已经增长和复杂到无法管理的程度.

I'm looking for a good parser generator that I can use to read a custom text-file format in our large commercial app. Currently this particular file format is read with a handmade recursive parser but the format has grown and complexified to the point where that approach has become unmanageable.

似乎最终的解决方案是为此格式构建适当的语法，然后使用真正的解析器生成器(如 yacc)来读取它，但是我无法决定使用哪个这样的生成器，或者即使它们是值得一试.我看过 ANTLR 和 Spirit，但我们的项目有超出早期答案 这让我怀疑它们是否适合我们.特别是，我需要:

It seems like the ultimate solution would be to build a proper grammar for this format and then use a real parser generator like yacc to read it, but I'm having trouble deciding which such generator to use or even if they're worth the trouble at all. I've looked at ANTLR and Spirit, but our project has specific constraints beyond earlier answers that make me wonder if they're as appropriate for us. In particular, I need:

• 使用 MSVC 生成 C 或 C++ 代码的解析器. ANTLR 3 不支持 C++；它声称可以生成直接的 C，但有关使其实际工作的文档有点令人困惑.
• 内存使用严重受限.内存在我们的应用中非常宝贵，即使是微小的泄漏也是致命的.我需要能够覆盖解析器的内存分配器以使用我们的自定义 malloc()，或者至少我需要给它一个连续的池，它从中提取所有内存(并且我可以在之后整体解除分配).我可以为解析器可执行文件本身腾出大约 200kb，但是它在解析中分配的任何动态堆都必须在之后释放.
• 良好的性能.这不是很重要，但我们应该能够在 3ghz 处理器上在不超过一秒的时间内解析 100kb 的文本.
• 必须不含 GPL.我们不能使用 GNU 代码.

• A parser that generates C or C++ code with MSVC. ANTLR 3 doesn't support C++; it claims to generate straight C but the docs on getting it to actually work are sort of confusing.
• Severely constrained memory usage. Memory is at a huge premium in our app and even tiny leaks are fatal. I need to be able to override the parser's memory allocator to use our custom malloc(), or at the very least I need to give it a contiguous pool from which it draws all its memory (and which I can deallocate en bloc afterwards). I can spare about 200kb for the parser executable itself, but whatever dynamic heap it allocates in parsing has to get freed afterwards.
• Good performance. This is less critical but we ought to be able to parse 100kb of text in no more than a second on a 3ghz processor.
• Must be GPL-free. We can't use GNU code.

我喜欢 ANTLRworks 的 IDE 和调试工具，但看起来让它的 C 目标与我们的应用程序实际一起工作将是一项艰巨的任务.在我开始那个 palaver 之前，ANTLR 是适合这项工作的工具吗?

I like ANTLRworks' IDE and debugging tools, but it looks like getting its C target to actually work with our app will be a huge undertaking. Before I embark on that palaver, is ANTLR the right tool for this job?

有问题的文本格式类似于:

The text format in question looks something like:

attribute "FluxCapacitance"  real constant

asset DeLorean
{
    //comment foo bar baz
    model "delorean.mdl"
    animation "gullwing.anm"
    references "Marty"
    loadonce
}

template TimeMachine
{
    attribute FluxCapacitance 10      
    asset DeLorean
}

推荐答案

ANTLR 3 不支持 C++；它声称生成直接的 C 但文档让它实际工作是排序令人困惑.

ANTLR 3 doesn't support C++; it claims to generate straight C but the docs on getting it to actually work are sort of confusing.

它确实生成 C，此外，它可以与 Visual Studio 和 C++ 一起使用.我知道这一点是因为我之前已经这样做过并提交了一个补丁来让它与 stdcall 一起工作.

It does generate C, and furthermore, it works with Visual Studio and C++. I know this because I've done it before and submitted a patch to get it to work with stdcall.

内存在我们的应用程序中非常重要即使是微小的泄漏也是致命的.我需要能够覆盖解析器的内存分配器使用我们的自定义malloc()，或者至少我需要给它一个连续的池它吸取了它所有的记忆(和我可以整体解除分配然后).我可以节省大约 200kb对于解析器可执行文件本身，但是它分配的任何动态堆之后必须释放解析.

Memory is at a huge premium in our app and even tiny leaks are fatal. I need to be able to override the parser's memory allocator to use our custom malloc(), or at the very least I need to give it a contiguous pool from which it draws all its memory (and which I can deallocate en bloc afterwards). I can spare about 200kb for the parser executable itself, but whatever dynamic heap it allocates in parsing has to get freed afterwards.

上次我检查的 antlr3c 运行时没有内存泄漏，并使用您描述的内存池范例.但是，它的API确实有一个作者拒绝改变的缺点，就是如果你请求一个节点的字符串，它每次都会创建一个新的副本，直到你释放整个解析器.

The antlr3c runtime, last time I checked does not have a memory leak, and uses the Memory pool paradigm which you describe. However, it does have one shortcoming in the API which the author refuses to change, which is that if you request the string of a node, it will create a new copy each time until you free the entire parser.

我对使用自定义 malloc 的易用性没有评论，但它确实有一个宏来定义在整个项目中使用什么 malloc 函数.

I have no comment on the ease of using a custom malloc, but it does have a macro to define what malloc function to use in the entire project.

至于可执行文件的大小，我的编译大小约为 100 kb，包括一个小型解释器.

As for the executable size, my compilation was about 100 kb in size including a small interpreter.

我给你的建议是继续学习 ANTLR，因为它仍然符合你的要求，你可能需要多牺牲一点时间才能开始为你工作.

My suggestion to you is to keep learning ANTLR, because it still fits your requirements and you probably need to sacrifice a little more time before it will start working for you.

这篇关于ANTLR 解析器生成器是否最适合内存受限的 C++ 应用程序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！