相关疑难解决方法(0)

请考虑三个功能.

std::string get_a_string()
{
    return "hello";
}

std::string get_a_string1()
{
    return std::string("hello");
}

std::string get_a_string2()
{
    std::string str("hello");
    return str;
}

1. RVO是否适用于所有三种情况？
2. 可以在上面的代码中返回一个临时的吗？我相信它没关系,因为我按值返回它而不是返回任何引用它.

有什么想法吗？

这里有一个粗心写的模板,有些过分内联 - 在C++中编写膨胀代码太容易了.原则上,重构以减少膨胀不是太难.问题在于跟踪最严重的违规模板和内联 - 跟踪那些在真实程序中导致真正膨胀的项目.

考虑到这一点,并且因为我确信我的库比他们应该更容易臃肿,我想知道是否有任何工具可以自动追踪那些最严重的违规者 - 即识别那些贡献最多的项目(包括所有重复的实例化和调用)到特定目标的大小.

此时我对性能不太感兴趣 - 这完全取决于可执行文件的大小.

有没有这个工作的工具,可以在Windows上使用,并适合MinGW GCC或Visual Studio？

编辑 - 一些背景

我有一组多路树模板,可以替代红黑树标准容器.它们是围绕非类型安全的非模板代码编写的,但它们也是很久以前编写的,并且作为"将更好地缓存友好性提升实际性能"实验.关键是,它们并非真正用于长期使用.

因为它们支持一些方便的技巧(基于自定义比较/部分键搜索,有效的下载访问,搜索最小的未使用的键),它们最终在我的代码中的任何地方都被使用.这些天,我几乎没有使用std :: map.

除了那些之外,我还有一些更复杂的容器,比如双向地图.最重要的是,我有树和有向图类.除此之外......

使用地图文件,我可以追踪非内联模板方法是否导致膨胀.这只是找到特定方法的所有实例并添加大小的问题.但是不明智的内联方法呢？毕竟,模板是非模板代码的薄包装,但历史上我判断是否应该内联的能力并不是非常可靠.这些模板内联的膨胀影响并不容易衡量.

我知道哪些方法被大量使用,但这是众所周知的opimization-without-profiling错误.