Question

我本周末在MeetingCPP柏林参加了罗密欧维托里奥的演讲。在他的图书馆ECST中，他在Boost.Hana的顶部实施了option_map，以便建立＆＃34;将用于创建实际类型的设置：

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>);

......其余代码为here

我发现API非常好，因为我们创建了一个带有函数调用的类型：我们实际上将元编程作为＆＃34; normal＆＃34;编程，我喜欢。此外，对于复杂的模板化类型，使用这种方法（在库侧）更容易开发：再次，只有 constexpr 方法和函数，根本没有模板。

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

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

或

decltype(ecst::...) _context;

在我看来，

不是优雅的解决方案。强制使用 decltype 似乎对我不好。

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

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

在库API中使用constexpr生成的类型

0 个答案: