Mac gcc doesn't allow calling std::string::~string explicitly

Question

strdata->std::string::~string();    

Here is the error I get:

error: '~' in destructor name should be after nested name specifier
        strdata->std::string::~string();
                              ^

I am using a cmake project... My gcc version installed via brew is following:

gcc --version Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin15.2.0 Thread model: posix

I couldn't find the ~string() defined anywhere in the header files. I ended up changing it as follows and that works. It is ok for my use case for now.

strdata->std::string::~basic_string();

This original seems correct and works perfectly in GCC on Linux and CYGWIN. What is the issue which is preventing it from working on mac? Templates? Something else?

Answer 1

This isn't a complete answer. For some reason, using namespace std; works, but without that clang fails. Consider this example:

#include <new>
#include <type_traits>

namespace foo {

struct A {};
typedef A A_t;

}

int main() {
    std::aligned_storage<sizeof(foo::A)>::type storage;

    foo::A_t* obj = new(&storage) foo::A;

    using namespace foo; // Without this line, clang fails.
    obj->foo::A_t::~A_t();
}

Without the using namespace foo; line, clang will give an error expected the class name after '~' to name a destructor. But with that line, it works. Extending this to std::string:

#include <new>
#include <type_traits>
#include <string>

int main() {
    std::aligned_storage<sizeof(std::string)>::type storage;

    std::string* obj = new(&storage) std::string;

    using namespace std; // Without this line, clang fails.
    obj->std::string::~string();
}

it works. It also works with the narrower using std::string;.

This doesn't answer the question of why clang fails. I don't know if it's a bug in clang or in gcc. But at least a workaround exists.

It may be worth reporting this as a bug in clang, and then letting them decide whether or not it really is a bug.