Z3的最新版本已将Z3_context和Z3_solver的概念分离。 API主要反映了这些变化;例如，push在上下文中被弃用，并被重新指定为将求解器作为额外参数。
然而，理论界面尚未更新。理论仍然是从上下文创建的，据我所知，从未明确地附加到求解器上。
有人可能会认为从上下文创建的理论将始终附加到从上下文创建的所有求解器中，但根据我们的经验，似乎并非如此。相反，用户定义的理论似乎完全被忽略了。
Z3_solver与Z3_theory s组合的确切状态是什么？
答案 0 :(得分：3)
理论插件很久以前就引入了（版本2.8），从那以后Z3发生了很大的变化。
它们在Z3 4.x中被视为已弃用。它们仍然可以与旧API一起使用，但不能与新功能一起使用，尤其是Z3求解器对象（Z3_solver）。
在目前的Z3中，我们有许多不同的求解器。最早的一个（在文件夹src/smt中实现）称为smt::context。理论插件实际上是这个旧解算器的扩展。
我们说smt::context是一个通用解算器，因为它支持许多理论和量词。
实际上，在Z3 4.3.1中，它是唯一可用的通用解算器。
但是，我认为它基于一个过时的架构，不适合我们为Z3规划的新功能。我的计划是将来用基于here描述的架构的求解器替换它。
而且，我们不再真正处理smt::context了。我们基本上只是维护它并修复错误。
在我们发布Z3源代码之后，我想象理论插件支持不再是必需的，因为用户可以在Z3代码库中添加他们的扩展。但是，这种观点过于简单，因为它阻止用户使用不同的编程语言编写扩展。 因此，目前的计划是最终为新解算器提供理论插件，最终将在Z3中提供。目标是拥有一个API，如：
Z3_solver Z3_mk_mcsat_solver(Z3_context ctx, Z3_mcsat_ext ext);
此API将使用给定的扩展名ext创建新的求解器对象。
与此同时，我们还可以使用以下函数扩展API：
Z3_solver Z3_mk_smt_solver(Z3_context ctx, Z3_theory t);
这将使用给定的理论插件基于smt::context创建一个新的求解器对象。
这个解决方案在概念上很简单，但是需要很多“管道”来实现它。
我们必须调整Z3_theory对象，修复一些限制，以防止理论插件与创建smt::context副本的功能（例如MBQI）等一起使用。如果有人对此非常感兴趣在这个界面中，我会在它上面投入周期（注释：我们只有少数用户使用理论插件）。我对此并不十分兴奋，因为计划最终取代smt::context。