是否有任何 XSLT 到 C++编译器可用吗？
我发现只有一次创建此类编译器的尝试 - http://sourceforge.net/projects/xsltc/。 但这个项目已经死了十年了。还有其他例子吗？开源还是商业？
构建这样的软件有什么基本的技术困难吗？使用本机编译 XSLT 的整个方法？
我认为使用它有很好的用例 - 我们不需要更改 XSLT 但仍然希望获得更高的性能（并且可能需要更低的内存要求）。
该软件可能没有看起来那么高效还有其他原因吗？ - 解释 XSLT 处理器是否与编译一样高效？
I found only one attempt to create such compiler - http://sourceforge.net/projects/xsltc/.
But this project is dead for decade already. Are there any other examples? Opensource or commercial?
Are there any fundamental technical difficulties with building such software? With the whole approach of compiling XSLT natively?
I suppose there are good use cases for using it - places where we don't need to change XSLT but still would like to get higher performance (and probably, lower memory requirements).
Are there any other reasons this software may be not so efficient as it looks? - Are interpreting XSLT processors as efficient as compiled would probably be?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
据我了解，XSLT 不再流行了。一般来说，使用您最喜欢的 XML 库来实现您选择的语言、解析 XML 数据以及编写代码以按照您想要的方式格式化输出会更容易、更强大。
另一方面，你似乎已经取得了一些成功。在某些情况下它是有用的。 查看这个问题，了解有关 XSLT 优缺点的更多详细信息。
不管怎样，软件开发人员一般都不是 XSLT 的忠实拥护者，这可以解释为什么没有出现用 C++ 编写优化的 XSLT 解析器的大趋势。
From my understanding, XSLT isn't very popular anymore. Generally, it's easier and more powerful to use your favorite XML library for your language of choice, parse your XML data, and write code to format the output the way you want it.
On the other hand, it seems like you have had some success with it already. There are cases when it's useful. Check this SO question out for more details on the pros and cons of XSLT.
Anyway, software developers in general aren't big fans of XSLT, which would explain why there hasn't been a big movement to write an optimized XSLT parser in C++.
Michael Kay 博士刚刚宣布 Saxon/C http://www.saxonica.com /saxon-c/index.xml
从产品主页：
Dr. Michael Kay just announced Saxon/C http://www.saxonica.com/saxon-c/index.xml
From the home page of the product:
XSLT 是一种具有一定模式匹配的函数式语言。
您可以将其编译为一组模式导向的规则，并通过元匹配确保立即适用的所有模式都得到有效处理。
编译模式导向的规则语言是很好理解的；请参阅 Charles Forty 的 80 年代初的 Rete 网络及其过去 20 年衍生品的工作。
所以如果有人想这样做，他们就可以。经济动力在哪里？
如果您确实想要这样做，那么您需要一个可以将 XSLT 作为一组模式进行处理的工具
而不是使用 XML 处理器将其视为看似愚蠢的 XML 文档。您希望能够操纵/组合模式并生成目标机器代码。您需要一个旨在操纵符号结构的工具。
LISP 会很好，但在解析 XML 方面并不是特别好（可以通过汗水修复），并且不太擅长操作生成的 C++ 代码（只能通过大量汗水才能修复，所以不太可能）。
我们的 DMS 软件重组工具包是一个系统，旨在将正式文档视为本质上与编译器将源代码视为一组语言结构的方式相同。
它具有XML解析器，可以对C++代码片段进行部分、组合操作，并可以通过应用C++优化源到源程序转换规则来优化结果。 （在 C++ 操作上已经投入了大量的汗水）。
我们使用 DMS 完成了模式导向的规则编译器，不是针对 XSLT，而是通过对模式进行元匹配并跟踪引发的更改的状态来编译那些源到源程序转换规则。你会得到非常大的自动机（有点像 LR 解析表变得很大），可以实现翻译。
不过，还没有对 XSLT 这样做过。
XSLT is a functional langauge with some pattern matching.
You could arguably compile it as a set of pattern-directed rules, with metamatching make sure that all patterns applicable at an instant were handled efficiently.
Compiling pattern-directed rules langauges is pretty well understood; see work on Charles Forty's Rete networks in the early 80s and derivatives over the past twenty years.
So if somebody wanted to do this, they could. Where's the economic incentive?
If you did want to do this, you want a tool that can process XSLT as a set of patterns
rather than using an XML processor to treat it asdumb XML document at it otherwise appears to be. And you'd want to be able to manipulate/compose the patterns and generate target machine code. You'd need a tool that is designed to manipulate symbolic structures.
LISP would be good, but isn't particularly good are parsing XML (fixable with sweat), and isn't particularly good at manipulating generated C++ code (fixable only with a vast amount of sweat so unlikely).
Our DMS Software Reengineering Toolkit is a system designed to treat formal documents as parts in essentially the same way a compiler treats source code as a set of langauge structures.
It has XML parsers, and can manipulate C++ code fragments in parts, in composition, and can optimize the result by applying C++ optimization source-to-source program transformation rules. (Vast amount of sweat already invested in the C++ manipulation).
We've done pattern-directed rule compilers using DMS, not for XSLT, but rather to compile those source-to-source program transformation rules, by meta-matching the patterns and tracking the state of induced changes. You get really big automata (sort of the same way LR parsing tables get big) that can implement the translation.
Haven't done this for XSLT, though.