处理通用代码中不一致的 typedef
我经常在大型代码库中遇到不遵循 typedef 标准约定的代码,例如 ThisType
而不是 this_type
。
编写不再依赖 this_type
的通用代码意味着我必须为没有 this_type
的每种类型提供一些脚手架代码。
我想 this_type
和 ThisType
都可以定义。然而,在大型代码库中,这会增加额外的噪音,并且是审查需要定期检查的内容。
有没有办法将其包装在 type_trait
中,以便我可以按照以下方式编写一些内容: this_type
OR其他一些通用解决方案?
I routinely come across code in large codebases that do not follow the standard convention for typedefs e.g. ThisType
instead of this_type
.
Writing generic code where I can no longer rely on this_type
means I have to provide some scaffolding code for each type that does not have this_type
.
I suppose both this_type
and ThisType
can be defined. However, in a large codebase that adds extra noise and is something that reviews will need to routinely check.
Is there a way to wrap it in a type_trait
such that I can write something along the lines of: this_type<SomeType>::value_type
OR some other generic solution?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
也许可以用更简单的方式来完成......无论如何,我提出了标签调度/SFINAE 解决方案。
首先,一个简单的递归
tag
结构,以避免在定义了多个可能的类型名称的情况下出现歧义。
然后为您想要从可能的类型中提取的每种类型提供一个模板函数(仅声明);一个用于
type
一个用于
this_type
一个用于
ThisType
一个(有点傻)用于
MySillyTypeName
请注意
标签
的数量不同:这避免了可能的歧义并给出了名称的优先顺序。现在是一个简单的结构,它使用
getType()
来提取所需的类型以下是完整的编译 C++17 示例
Maybe can be done in a simpler way... anyway, I propose a tag dispatching / SFINAE solution.
First of all, a simple recursive
tag
structto avoid ambiguities in cases more that one of the possible type names are defined.
Then a template function (only declared) for every type you want extract from the possible types; one for
type
one for
this_type
one for
ThisType
and one (to be a little silly) for
MySillyTypeName
Observe that the number of the
tag
are differents: this avoid the possible ambiguity and give a priority order for the names.Now a trivial struct that uses
getType()
to extract the required typeThe following is a full compiling C++17 example