小编Nor*_*löw的帖子

我们正在考虑将一个非常大的项目从使用GNU Make转换为更现代的构建工具.我目前的建议是使用SCons或Waf.

目前:

• 建造时间约为15分钟.
• 大约100名开发人员
• 大约10%的代码是C/C++/Fortran休息是Ada(使用gnatmake).

改进的潜在希望/收益是

• 共享编译器缓存可缩短构建时间并需要磁盘空间
• 维护更方便

SCons能否很好地完成这项任务？我已经看到它的评论没有缩放,也不像Waf.然而,这些已经有几年了.过去几年中,scons的表现有所增加吗？如果没有,与Waf相比,其表现不佳的原因是什么？

我刚刚看到这个非常好的演讲 Rock Hard:C++由Boris Jabes 演变.在关于高阶通用编程的讨论部分中,他说以下是一个函数的例子,它的返回类型更通用,并导致更少的模板函数重载

template <typename Func>
auto deduce(const Func & f) -> decltype(f())
{..}

然而,这可以使用如下的普通模板语法来实现

template <typename Func>
Func deduce(const Func & f)
{..}

所以我猜选择的例子并没有真正显示出独特的力量decltype.任何人都可以举一个这样一个更具启发性的用法的例子decltype吗？

作为这篇文章的后续内容,我想知道如何make_unique通过分配函数临时缓冲区数组来实现它的播放,如下面的代码所示.

f()
{
  auto buf = new int[n]; // temporary buffer
  // use buf ...
  delete [] buf;
}

可这与一些调用所替换,以make_unique与将[]的删除-version被继续使用？

内联函数是否需要在性能方面通过const引用传递其参数,如

foo(const T & a, const T &b)

与价值相比

foo(T a, T b)

如果我不改变函数中a和b的值？C++ 11是否会更改此处的具体内容？

我目前正在使用非常聪明的软件包,boost::const_string直到http://libcxx.llvm.org/在Ubuntu上预打包或GCC使其__versa_string(在标头中ext/vstring.h)成为其默认字符串实现.libcxx std::string以及__versa_string默认情况下使用_small -string optimization(SSO).std::ostream但缺少输出到a的默认支持.代码

#include <iostream>
#include <boost/const_string.hpp>

const_string<char> x;
std::cout << x << endl;

除非我们强行x进入一个成为的c字符串c_str(),否则不起作用

std::cout << x.c_str() << endl;

编译和按预期工作.我添加了以下行const_string.hpp

template <typename T>
inline std::ostream & operator << (std::ostream & os, const boost::const_string<T> & a)
{
    return os.write(a.data(), a.size());
}

这应该提高性能比x.c_str(),因为size()是已知的,并不需要通过搜索来计算NULL作为c_str().我为我工作,但我不确定它是否适用于所有情况.我错过了什么吗？

我是D新编程的新手.选择DMD(2.061)或GDC(4.6,4.7或4.8,快照)的优缺点是什么.我应该选择哪种GDC版本？我已成功构建了GCC-4.8和GDC-4.8的最新快照,并编译了一个hello world程序.

以下是我对专业人士的看法:

• GDC:更多平台,运行时性能
• DMD:编译性能,更多测试？

如何通过GDB调试支持 - GDC和DMD之间有什么不同？

GCC __attribute__(bitwise)是什么意思？GCC-4.6的信息页面中未提及该属性.我open-iscsi-2.0.871/include/iscsi_proto.h在源文件中使用了它,它在项目Open-ISCSI中用作它

...
/*
 * If running svn modules we may need to define these.
 * This should not go upstream since this is already properly defined there
 */
#ifdef __CHECKER__
#define __bitwise__ __attribute__((bitwise))
#else
#define __bitwise__
#endif
#ifdef __CHECK_ENDIAN__
#define __bitwise __bitwise__
#else
#define __bitwise
#endif

/*! initiator tags; opaque for target */
typedef uint32_t __bitwise__ itt_t;
/*! below makes sense only for initiator that created this tag */
#define build_itt(itt, age) ((__force itt_t)\ …

为什么mmap默认情况下在cygwin,freebsd和irix6-5上激活缓冲区分配但在linux上没有激活？

见USE_MMAP_FOR_BUFFERS在emacs/src/config.h.并use_mmap_for_buffers在emacs/configure.in.

是不是mmap基于访问优于正常的缓冲区分配？

我正在编写一个包装器容器模板类,std::vector它会自动创建一个multi-resolution pyramid元素std::vector.

现在的关键问题是我希望金字塔的创建是(GCC)自动矢量化的.

内部存储在std :: vector和我的解析金字塔中的所有数据数组都是使用标准的new或allocator模板参数在堆上创建的.有没有我可以帮助编译器强制对我的数据进行特定对齐,以便矢量化可以在具有最佳对齐的元素(数组)(块)上运行(通常为16).

因此我使用自定义分配器, AlignmentAllocator但GCC自动向量化消息输出仍然在第144行中声明包含表达式的未对齐内存std::mr_vector::construct_pyramidmulti_resolution.hpp

for (size_t s = 1; s < snum; s++) { // for each cached scale
...
}

如下

tests/../multi_resolution.hpp:144: note: Detected interleaving *D.3088_68 and MEM[(const value_type &)D.3087_61]
tests/../multi_resolution.hpp:144: note: versioning for alias required: can't determine dependence between *D.3088_68 and *D.3082_53
tests/../multi_resolution.hpp:144: note: mark for run-time aliasing test between *D.3088_68 and *D.3082_53
tests/../multi_resolution.hpp:144: note: versioning for alias …

我试图了解如何使用C++(11)<type_traits>.

这是我的琐碎测试计划

#include <type_traits>

template<class U, class S>
inline U add(typename std::enable_if<std::is_unsigned<U>::value,U>::type a,
             typename std::enable_if<std::is_signed  <S>::value,S>::type b)
{
    return a + b;
}

int main(int argc, const char * argv[], const char * envp[])
{
    unsigned int ui;
    int i;
    auto a = add(ui, i);
    return 0;
}

使用GCC 4.8.1编译时,它的错误为

/home/per/f.cpp: In function ‘int main(int, const char**, const char**)’:
/home/per/f.cpp:15:23: error: no matching function for call to ‘add(unsigned int&, int&)’
     auto a = add(ui, i);
                       ^
/home/per/f.cpp:15:23: note: …