好的,所以我的代码中有一个小角落,我希望我的函数返回(int
,double
,CString
)来清理代码位。
所以我认为:写一个类似联盟的包装器struct
和三个成员等没问题。但是等等!我还没读过boost::variant
吗?这不是我需要的吗?这样可以避免我自己搞乱包装结构! (请注意,我的项目中已经有了boost库。)
所以我启动了我的浏览器,导航到Chapter 28. Boost.Variant并且看到了:
变体类模板是一个安全,通用,基于堆栈的区分联合容器,提供了一种简单的解决方案,用于从异构类型集中操作对象[...]
大!正是我需要的!
然后它继续:
Boost.Variant vs. Boost.Any
- Boost.Any很少使用模板元编程技术(避免可能难以读取的错误消息以及大量的编译时处理器和内存需求)。
[...]
疑难解答
“达到内部堆限制” - Microsoft Visual C ++ - 编译器选项/ ZmNNN可以增加内存分配限制。 NNN是缩放百分比(即,100表示默认限制)。 (试试/ Zm200。)
[...]
呃哦。因此使用boost :: variant可能会显着增加编译时间并生成难以读取的错误消息。如果有人将我对boost :: variant的使用转移到一个公共头,那么我们的项目是否会突然花费更长时间来编译? 我是否引入了(不必要的)复杂类型?
我应该使用boost::variant
来解决简单的
答案 0 :(得分:7)
一般情况下,如果你做想要一个有区别的联合(boost::variant
是针对未知类型的联盟),请使用any
- 将其视为某种等同于{{1用于C)。
一些优点包括异常处理,可能使用的空间小于类型大小的总和,类型区分“访问”。基本上,你想要在有区别的联盟上执行的任务。
但是,要使void*
有效,必须“轻松”构建所使用的类型中的至少一种(阅读文档以获取有关“容易”含义的更多详细信息)。
答案 1 :(得分:5)
Boost.variant并不复杂,恕我直言。是的,它是基于模板的,但它不使用任何真正复杂的C ++特性。我已经使用了很多,没有任何问题。我认为在您的情况下,它将有助于更好地描述您的代码正在做什么。
另一种思维方式是将该函数返回的内容转换为更加语义丰富的结构/类,允许解释哪个内部元素很有趣,但这取决于您的设计。
答案 2 :(得分:1)
这种boost元素来自函数式编程,每个角落都有variants。
这应该是一种类型安全方法来返回一种可以是许多精确类型的值的方法。这意味着解决问题很有用但是你应该考虑它是否真的需要你做。
与尝试解决相同问题的其他方法相比,增加的价值应该是类型安全(您无法在不注意的情况下在变体中放置任何您想要的内容,而不是void*
)
答案 3 :(得分:0)
我不使用它,因为对我而言,这是设计糟糕的症状。
您的方法应返回实现确定接口的对象,或者应该在多个方法中拆分。无论如何,应该审查设计。