1

这个周末我在柏林会议 CPP 参加了 Romeo Vittorio 的演讲。在他的库ECST中，他在Boost.Hana的顶部实现了一个 option_map，以便“构建”将用于创建实际类型的设置：

constexpr auto s =                        // .
    ecst::settings::make()                // .
        .allow_inner_parallelism()        // .
        .fixed_entity_limit(entity_limit) // .
        .component_signatures(make_csl()) // .
        .system_signatures(make_ssl())    // .
        .scheduler(cs::scheduler<ss::s_atomic_counter>);

...其余的代码在这里

我发现 API 非常好，因为我们创建了一个带有函数调用的类型：我们实际上将元编程作为“普通”编程进行，我喜欢这一点。此外，对于复杂的模板类型，使用这种方法（在库端）进行开发要容易得多：同样，只有constexpr方法和函数，根本没有模板。

现在，我的问题是关于这个 API 的使用。这种方法的问题在于，隐藏在auto后面的类型实际上非常复杂，而且不是“API 用户友好”，因为它是由 constexpr 函数生成的，我认为这很好：用户不需要知道确切的类型，他只是想用它，对吧？但是他将如何使用这个类作为类的属性，因为auto不能用作非静态属性？

static constexpr auto ctx = ecst::...;
using context_t = decltype(ctx);
context_t _context;

或者

decltype(ecst::...) _context;

在我看来，这不是优雅的解决方案。强制使用decltype对我来说似乎并不好。

另一种解决方案是简单地将 this auto类型作为模板参数传递给一个类——这就是 ECST 在示例中所做的——但同样，它限制了很多用户，因为他必须模板化他的整个代码才能使用图书馆。

你怎么看？这里有优雅的解决方案吗？

4

0 回答 0