我正试图为一个项目设置铿锵声.我希望能够提供干净的输出,并鼓励尽可能使用-fix模式.但是,在某些情况下需要例外.

很有可能使用

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wreserved-id-macro"
// Code that is being specially exempted
#pragma clang diagnostic pop

对于想要在本地禁用编译器警告的等效情况,是否可以通过clang-tidy执行类似的操作？

我试过了

#pragma clang diagnostic push
#pragma clang diagnostic ignored "readability-identifier-naming"
// Code that is being specially exempted
#pragma clang diagnostic pop

并且还clang替换为clang-tidy.不幸的是,当clang用作pragma目标并使用常规clang进行编译时,我得到了编译警告

warning: pragma diagnostic expected option name (e.g. "-Wundef") [-Wunknown-pragmas]

和

warning: unknown pragma ignored [clang-diagnostic-unknown-pragmas]

编译时,如果我用来clang-tidy代替clang.clang-tidy在源上运行时,都不会对自身的输出产生影响.

这与x86_64 Linux上的3.8 clang和clang-tidy.

我试图使用C++ 17标准中提出的新并行库功能,但我无法使其工作.我试着用的了最新版本的编译g++ 8.1.1和clang++-6.0和-std=c++17,但也似乎支持#include <execution>,std::execution::par或任何类似.

声称,在查看并行算法的cppreference时,有很多算法列表

技术规范提供以下69种算法的并行化版本algorithm,numeric并且memory:( ...长列表...)

听起来像算法已经准备好'在纸上',但尚未准备好使用？

在一年多前的SO问题中,答案声称这些功能尚未实现.但到现在为止,我希望看到某种实现方式.有什么我们可以使用的吗？

我是铿锵的新手,所以我可能会做些傻事.但我花了几个小时寻找解决方案,包括在这里搜索,我没有找到问题解决-flto与发行版提供的软件包.这个描述的细节是特定于Fedora 18的,但我在Ubuntu 13.04上遇到了类似的问题,所以这个问题并不是特定于Fedora.这是我或铿锵.

问题:我正在尝试编译一个简单的hello-world程序,clang++ -flto以获得链接时优化的好处.没有-flto它工作正常.使用-flto无法链接.调用clang -flto -o hello hello.o -v以查看完整的链接器命令行,我得到:

$ clang++ -flto -o hello hello.o -v
clang version 3.2 (tags/RELEASE_32/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
 "/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o hello /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../.. -L/lib -L/usr/lib -plugin /usr/bin/../lib/LLVMgold.so hello.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crtn.o
/usr/bin/ld: /usr/bin/../lib/LLVMgold.so: error loading plugin
/usr/bin/ld: /usr/bin/../lib/LLVMgold.so: error in plugin cleanup (ignored)
clang: error: linker command failed with exit code …

这是我在Mac OS X上使用clang ++面临的问题的缩小版本.这是经过严格编辑以更好地反映真正的问题(第一次尝试描述问题并没有表现出问题).

失败

我在C++中有一大块软件,在目标文件中有大量符号,所以我-fvisibility=hidden用来保持我的符号表小.众所周知,在这种情况下,必须特别注意vtable,我想我遇到了这个问题.然而,我不知道如何以一种令gcc和clang取悦的方式优雅地解决它.

考虑一个base具有向下转换运算符as的derived类,以及包含一些有效负载的类模板.pair base/ derived<T>用于实现类型擦除:

// foo.hh

#define API __attribute__((visibility("default")))

struct API base
{
  virtual ~base() {}

  template <typename T>
  const T& as() const
  {
    return dynamic_cast<const T&>(*this);
  }
};

template <typename T>
struct API derived: base
{};

struct payload {}; // *not* flagged as "default visibility".

API void bar(const base& b);
API void baz(const base& b);

然后我有两个不同的编译单元提供类似的服务,我可以将其近似为相同功能的两倍:向下转换base为derive<payload>:

// bar.cc
#include "foo.hh" …

我只使用特定于C++的头文件(例如<cstdlib>),但是我仍然获得全局声明的函数,而不仅仅是std命名空间中的函数.有没有办法,也许是编译器开关,以防止这种情况？

例如,以下代码:

#include <cstdlib>
float random() { return 0.0f; }
int main() { return 0; }

无法在linux下编译,出现以下错误:

> g++ -c main.cpp main.o
main.cpp: In function ‘float random()’:
main.cpp:2:14: error: new declaration ‘float random()’
/usr/include/stdlib.h:327:17: error: ambiguates old declaration ‘long int random()’

要么

> clang++ main.cpp -o main.o
main.cpp:2:7: error: functions that differ only in their return type cannot be overloaded
float random() { return 0.0f; }
/usr/include/stdlib.h:327:17: note: previous declaration is here
extern long int random …

假设以下代码:

namespace test 
{ 
    namespace detail 
    { 
    }

    inline namespace v1 
    { 
        namespace detail 
        { 
            void foo() 
            { 
            }
        }
    }
}

int main()
{ 
    test::detail::foo(); 
}

我们可以看到,这段代码与Clang编译; 然而,与海湾合作委员会没有关系 - 海湾合作委员会抱怨说这namespace detail是不明确的:

main.cpp:20:11: error: reference to 'detail' is ambiguous
     test::detail::foo(); 
           ^
main.cpp:4:5: note: candidates are: namespace test::detail { }
     { 
     ^
main.cpp:10:9: note:                 namespace test::v1::detail { }
         { 
         ^

哪个编译器在这里做正确的事情？

在使用clang的线程消毒剂时,我们注意到了数据竞争警告.我们认为这是由于std :: string的copy-on-write技术不是线程安全的,但我们可能是错的.我们减少了对此代码的警告:

void test3() {
  std::unique_ptr<std::thread> thread;

  {
    auto output = make_shared<string>();
    std::string str = "test";
    thread.reset(new std::thread([str, output]() { *output += str; }));
    // The str string now goes out of scope but due to COW
    // the captured string may not have the copy of the content yet.
  }

  thread->join();
}

在使用线程清理程序编译时:

clang++ -stdlib=libc++ -std=c++11 -O0 -g -fsanitize=thread -lpthread -o test main.cpp

要么

clang++ -std=c++11 -O0 -g -fsanitize=thread -lpthread -o test main.cpp

并且当多次运行时,它最终会产生此警告:

WARNING: ThreadSanitizer: data race …

我正在尝试使用clang ++在Windows上使用Boost.Thread.

在包含boost/thread.hpp时,我遇到以下编译错误:

使用-DBOOST_USE_WINDOWS_H:

In file included from D:/env/boost/boost_1_58_0\boost/thread.hpp:13:
In file included from D:/env/boost/boost_1_58_0\boost/thread/thread.hpp:12:
In file included from D:/env/boost/boost_1_58_0\boost/thread/thread_only.hpp:15:
In file included from D:/env/boost/boost_1_58_0\boost/thread/win32/thread_data.hpp:11:
D:/env/boost/boost_1_58_0\boost/thread/win32/thread_primitives.hpp:223:67: error: conflicting types for 'GetProcAddress'
                __declspec(dllimport) detail::farproc_t __stdcall GetProcAddress(void *, const char *);
                                                                  ^
/mingw/include\winbase.h:1675:27: note: previous declaration is here
WINBASEAPI FARPROC WINAPI GetProcAddress(HINSTANCE,LPCSTR);
                          ^
In file included from D:/env/boost/boost_1_58_0\boost/thread/thread_only.hpp:15:
In file included from D:/env/boost/boost_1_58_0\boost/thread/win32/thread_data.hpp:11:
D:/env/boost/boost_1_58_0\boost/thread/win32/thread_primitives.hpp:223:67: warning: redeclaration of 'GetProcAddress' should not add 'dllimport' attribute [-Wdll-attribute-on-redeclaration]
                __declspec(dllimport) detail::farproc_t __stdcall GetProcAddress(void *, const char *);
                                                                  ^ …

请查看此代码段.我知道它没有多大意义,它只是为了说明我遇到的问题:

#include <iostream>
using namespace std;

struct tBar
{
    template <typename T>
    void PrintDataAndAddress(const T& thing)
    {
        cout << thing.mData;
        PrintAddress<T>(thing);
    }

private:
    // friend struct tFoo; // fixes the compilation error

    template <typename T>
    void PrintAddress(const T& thing)
    {
        cout << " - " << &thing << endl;
    }
};

struct tFoo
{
    friend void tBar::PrintDataAndAddress<tFoo>(const tFoo&);
    private:

    int mData = 42;
};

struct tWidget
{
    int mData = 666;
};

int main() 
{
    tBar bar;
    bar.PrintDataAndAddress(tWidget()); // Fine …

今天我正在阅读clang的C++ 17支持页面.我注意到一些奇怪的事情.功能匹配模板模板参数与兼容参数(P0522R0)标记为部分,因为它必须通过开关激活.他们的笔记说:

尽管是缺陷报告的解决方案,但默认情况下,此功能在所有语言版本中都被禁用,并且可以使用Clang 4中的标志-frelaxed-template-template-args显式启用.标准的更改缺少相应的更改对于模板部分排序,导致合理且先前有效的代码的模糊错误.预计这个问题很快就会得到纠正.

激活此功能后会出现什么样的构造？为什么它会破坏代码？