"concurrentqueue.h:366:63: error: no template named 'has_trivial_destructor'"

[yuikns]

OS: OSX 10.10.2

ERROR MESSAGE:

concurrentqueue.h:366:63: error: no template named 'has_trivial_destructor' in namespace 'std'; did you mean
      'has_virtual_destructor'?
        template<typename T> struct is_trivially_destructible : std::has_trivial_destructor<T> { };
                                                                ~~~~~^~~~~~~~~~~~~~~~~~~~~~
                                                                     has_virtual_destructor
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:971:51: note: 'has_virtual_destructor' declared here
template <class _Tp> struct _LIBCPP_TYPE_VIS_ONLY has_virtual_destructor
                                                  ^

Compiler:

$ gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix

Realted Macros :
__GNUC__ : 4
__GNUC_MINOR__ : 2
__APPLE__ : 1

My fix :
line 362: ( https://github.com/cameron314/concurrentqueue/blob/master/concurrentqueue.h#L362 )

- #if !defined(__GNUC__) || __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
+ #if defined(__APPLE__) || !defined(__GNUC__) || __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)

It works, but I think it seems too ugly.

[cameron314]

Hmm, that is ugly. An old GCC 4.2 with a modern LLVM backend. I'll have to think about that.
Shouldn't it be !defined(__APPLE__) && (...) though?

[ljsnogard]

I fixed it with this:

namespace std
{
    template<typename> struct has_trivial_destructor;
    template<typename> struct is_trivially_destructible;
}


namespace Freebird_cxx11_trait_util
{
    template<typename T>
    class have_cxx11_trait_helper
    {
        template<typename T2, bool = std::is_trivially_destructible<T2>::type::value>
        static std::true_type test(int);

        template<typename T2, bool = std::has_trivial_destructor<T2>::type::value>
        static std::false_type test(...);

    public:
        typedef decltype(test<T>(0)) type;
    };

    template<typename T>
    struct have_cxx11_trait : have_cxx11_trait_helper<T>::type
    { };

}

// ....

template<typename It>
        static inline auto deref_noexcept(It& it) MOODYCAMEL_NOEXCEPT -> decltype(*it)
        {
            return *it;
        }

        template<typename T>
        using is_trivially_destructible
            = typename std::conditional<
                    Freebird_cxx11_trait_util::have_cxx11_trait<T>::value,
                    std::is_trivially_destructible<T>,
                    std::has_trivial_destructor<T>
                >::type;

#ifdef MOODYCAMEL_CPP11_THREAD_LOCAL_SUPPORTED

which can be found on Stackoverflow

http://stackoverflow.com/questions/12702103/writing-code-that-works-when-has-trivial-destructor-is-defined-instead-of-is

[cameron314]

I've committed your original macro-based fix for now (you were right about the condition, by the way, I was mixing up the two lines). I'm not sure how slightly older compilers will react to the template wizardry involved in the second one (somebody commented on that SO question that it's broken on clang 3.1).

Thanks for reporting this, and for the fixes! Much appreciated.

[ljsnogard]

./concurrentqueue.hpp:396:70: error: no template named 'has_trivial_destructor' in namespace 'std'; did you mean 'has_virtual_destructor'?
template struct is_trivially_destructible : std::has_trivial_destructor { };
~~~~~^~~~~~~~~~~~~~~~~~~~~~
has_virtual_destructor
/usr/include/c++/v1/type_traits:971:51: note: 'has_virtual_destructor' declared here
template struct _LIBCPP_TYPE_VIS_ONLY has_virtual_destructor
^

1 error generated.

clang++ --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
Thread model: posix

[cameron314]

Seems the error came back to haunt us? I'll look into this shortly, thanks for the report.

[cameron314]

Sorry about that. It should be fixed now. Obviously the GCC version detection doesn't work very well with clang because it defines the GCC macros (but isn't bug-for-bug compatible).

[yuikns]

@cameron314 sorry for reopen this issue, there is no necessary to use __APPLE__ and __clang__ they both, because in OSX 10.10.x, even I use gcc to compile those files, the macro __clang__ also has been defined.

At first, I use __APPLE__ is because of I have no FreeBSD and I am not sure the situation may be different in another clang compiler.

Maybe you can just remove the first __APPLE__ and just write as

#if defined(__clang__) || !defined(__GNUC__) .|| some others

It is not a bug, I just think this may seems more beautiful.

[cameron314]

Hmm, yep, makes sense. The gcc on Mac OS X must simply be a wrapper around clang. Thanks for the pull request!

[yuikns]

My pleasure, your code is really useful and make some contribution for this project is also means help myself.