是boost ::变种火箭科学吗？(因此,我应该避免它出于简单的问题吗？)

Question

好了,我有我的代码这个小小的角落里,我想我的函数返回任(int,double,CString),以清理代码位.

所以我认为:struct用三个成员等编写一个类似联盟的包装器没问题.但是等等!我没看过boost::variant吗？这不是我需要的吗？这样可以避免我自己搞乱包装结构!(请注意,我的项目中已经有了boost库.)

所以我启动了我的浏览器,导航到第28章.Boost.Variant并且看到:

变体类模板是一个安全,通用,基于堆栈的区分联合容器,提供了一种简单的解决方案,用于从异构类型集中操作对象[...]

大!正是我需要的!

但接着它继续:

Boost.Variant vs. Boost.Any

• Boost.Any很少使用模板元编程技术(避免可能难以读取的错误消息和大量的编译时处理器和内存需求).

[...]

故障排除

"达到内部堆限制" - Microsoft Visual C++ - 编译器选项/ ZmNNN可以增加内存分配限制.NNN是缩放百分比(即,100表示​​默认限制).(试试/ Zm200.)

[...]

哦,哦.因此使用boost :: variant可能会显着增加编译时间并生成难以读取的错误消息.如果有人将我对boost :: variant的使用转移到一个公共头,那么我们的项目是否会突然花费更长时间来编译？我是否介绍了(不必要的)复杂类型？

我应该用boost::variant我的简单小问题吗？

Answer 1

一般情况下,使用boost::variant,如果你不想要一个可识别联合(any为未知类型-把它当作某种等同于如何void*用C时).

一些优点包括异常处理,可能使用的空间小于类型大小的总和,类型区别"访问".基本上,你想要在有区别的联盟上执行的东西.

但是,为了boost::variant提高效率,必须"轻松"构建所使用的类型中的至少一种(阅读文档以获取"容易"意味着什么的更多细节).

Answer 2

恕我直言,Boost.variant并不那么复杂.是的,它是基于模板的,但它不使用任何真正复杂的C++特性.我已经使用了很多,没有任何问题.我认为在您的情况下,它将有助于更好地描述您的代码正在做什么.

另一种思维方式是将函数返回的内容转换为更加语义丰富的结构/类,允许解释哪个内部元素很有趣,但这取决于您的设计.