简体   繁体   English

有没有统一函数类型限定符,简化可恶的函数类型的建议?

[英]Is there any proposal to uniformize function type qualifiers and simplify abominable function types?

The abominable function types combinatory can be a real pain when dealing with template based on function type matching (see std::is_function ).在处理基于函数类型匹配的模板时, 可恶的函数类型组合可能是一个真正的痛苦(参见std::is_function )。

Miscellaneous qualifers including const, volatile, &, &&, noexcept (plus the variadic arguments support) may lead to a large number of template specializations.各种限定符,包括 const、volatile、&、&&、noexcept(加上可变参数支持)可能会导致大量的模板特化。

However, the noexcept specifier allows to use a boolean expression noexcept(expr) :但是, noexcept说明符允许使用布尔表达式noexcept(expr)

  • noexcept being equivalent to noexcept(true) as default noexcept等价于noexcept(true)作为默认值

So, in a future, can we imagine to uniformize all qualifers with this model:所以,在未来,我们能不能想象用这个模型统一所有的限定词:

  • const qualifier will be equivavent to const(true) const限定符将等同于const(true)
  • volatile qualifier will be equivavent to volatile(true) volatile限定符将等同于volatile(true)
  • & qualifier will be equivavent to &(true) &限定符将等同于&(true)
  • && qualifier will be equivavent to &&(true) &&限定符将等同于&&(true)

And, the icing on the cake, make qualifiers deductible to be able to write something like:而且,锦上添花,使预选赛免赔额能够写出如下内容:

template <typename Fn>
struct function_traits;

template <typename R, bool CQ, bool VQ, bool LVRQ, bool RVRQ, bool NEQ, ARGS... Args>
struct function_traits<R(Args...) const(CQ) volatile(VQ) &(LVRQ) &&(RVRQ) noexcept(NEQ)>
{
    static constexpr bool is_const_qualified = CQ;
    static constexpr bool is_volatile_qualified = VQ;
    static constexpr bool is_lvalue_ref_qualified = LVRQ;
    ...
};

I would like to hear any thoughts about such issues.我想听听有关此类问题的任何想法。

I made a similar suggestion on the std-proposals mailing list previously.我之前在 std-proposals 邮件列表上提出了类似的建议。 See threads here and here .请参阅此处此处的线程。

The conclusion from this discussion was that adding such a feature to the language would be a lot of work.从这次讨论中得出的结论是,在语言中添加这样的特性需要大量的工作。 Not only would it be necessary to add rules to the language for deducing the boolean arguments to the qualifiers, but there would also be many other issues such as the point at which the qualifiers are instantiated and evaluated.不仅需要在语言中添加规则来推导限定符的布尔参数,而且还有许多其他问题,例如限定符的实例化和评估点。 A proposal of this size would also be likely to introduce many other issues that would have to be hammered out.这种规模的提案也可能会引入许多其他必须解决的问题。

Gašper Ažman appeared to believe that some form of "computed deduction" would be an alternative solution to the problem that would be more feasible. Gašper Ažman 似乎相信某种形式的“计算推论”将是更可行的问题的替代解决方案。 If you're interested in helping with this effort then I would suggest contacting him.如果您有兴趣帮助完成这项工作,那么我建议您与他联系。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 摆脱 C++ 中可恶的 function 类型的可能方法? - Possible way to get rid of abominable function types in C++? 警告:在函数返回类型 [-Wignored-qualifiers] 上忽略类型限定符 - warning: type qualifiers ignored on function return type [-Wignored-qualifiers] 从函数类型中剥离所有限定符 - Stripping all qualifiers from a function type 该对象具有与成员函数不兼容的类型限定符 - the object has type qualifiers that are not compatible with the member function Object具有与成员函数不兼容的类型限定符 - Object has type qualifiers that are not compatible with the member function 带有限定符的 function 类型类型定义的用例 - Use cases for function type typedefs with qualifiers Pedantic gcc warning:在函数返回类型上输入限定符 - Pedantic gcc warning: type qualifiers on function return type 为什么仅在原语的情况下才在函数返回类型中忽略类型限定符? - Why type qualifiers ignored on function return type only in case of primitives? 该对象具有与成员函数sfml覆盖draw不兼容的类型限定符 - the object has type qualifiers that are not compatible with the member function sfml overriding draw IntelliSense:对象具有与成员函数不兼容的类型限定符 - IntelliSense: the object has type qualifiers that are not compatible with the member function
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM