search for: shared_mutex

How can I tell at compile time through predefined macros whether libc++ includes/supports the C++14 header file shared_mutex ? Given that I have identified that libc++ is being used, will this work ? : #if __cplusplus >= 201402 // Header file shared_mutex supported #endif or do I need to check something else ?

On 6/8/2015 10:10 PM, Tim Northover wrote: > On 8 June 2015 at 17:53, Edward Diener <eldlistmailingz at tropicsoft.com> wrote: >> How can I tell at compile time through predefined macros whether libc++ >> includes/supports the C++14 header file shared_mutex ? > > I doubt it's even theoretically possible. Clang can be used with > multiple standard libraries, and there's no real way for it to know > just what you're compiling against (even if it knows in general terms > that it's libc++). I am not talking about clang, I a...

...CMakeFiles/cxx_objects.dir/__/src/new.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/optional.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/random.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/regex.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/shared_mutex.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/stdexcept.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/string.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/strstream.cpp.o projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/system_error.cpp.o projects/libc...

...LLVM_ENABLE_THREADS by default on MinGW. MinGW plus LLVM_ENABLE_THREADS would become unsupported. Do people have objections to 2? I don't really like it either. On Fri, Jun 20, 2014 at 10:33 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > The whole "mutex" and "shared_mutex" files are #ifdef > _GLIBCXX_HAS_GTHREADS so if no _GLIBCXX_HAS_GTHREADS there are no mutexes > and no call_once. thread lives in "thread" which is also #ifdef > _GLIBCXX_HAS_GTHREADS. > "condition_variable" and "future" are the same. > > I have...

It sounds like this version of libstdc++ doesn't support std::recursive_mutex from C++11. This is really unfortunate, because we were hoping that moving to C++11 would allow us to use standard, portable threading primitives. Does this version of MinGW have any C++11 threading support? Is it just recursive_mutex that is missing, or do we have to avoid std::mutex, std::call_once, etc? lld

...d read/write lock on *nix systems. However, in comparison with the approach that implement read/write lock base on std::atomic, the old methods not only has potential performance issue(Sorry I can't provide concrete evidence, any benchmark result is welcome) but also non-standard. Before std::shared_mutex in C++17 got fully adopt by LLVM codebase, I think we can use std::atomic + std::conditional_variable approach like this: https://gist.github.com/mshockwave/b314eb78d4019e7e106e705e864e0398 to power RWMutex. -- Bekket McClane Department of Computer Science, National Tsing Hua University ---------...

...READS would become unsupported. >> >> Do people have objections to 2? I don't really like it either. >> >> >> On Fri, Jun 20, 2014 at 10:33 AM, Yaron Keren <yaron.keren at gmail.com> >> wrote: >> >>> The whole "mutex" and "shared_mutex" files are #ifdef >>> _GLIBCXX_HAS_GTHREADS so if no _GLIBCXX_HAS_GTHREADS there are no mutexes >>> and no call_once. thread lives in "thread" which is also #ifdef >>> _GLIBCXX_HAS_GTHREADS. >>> "condition_variable" and "future"...

...xx > [ 3%] [ 7%] [ 11%] [ 15%] Building CXX object > lib/CMakeFiles/cxx.dir/__/src/iostream.cpp.o > Building CXX object lib/CMakeFiles/cxx.dir/__/src/future.cpp.o > Building CXX object lib/CMakeFiles/cxx.dir/__/src/algorithm.cpp.o > Building CXX object lib/CMakeFiles/cxx.dir/__/src/shared_mutex.cpp.o > [ 19%] [ 23%] [ 26%] [ 30%] Building CXX object > lib/CMakeFiles/cxx.dir/__/src/optional.cpp.o > Building CXX object lib/CMakeFiles/cxx.dir/__/src/typeinfo.cpp.o > [ 34%] Building CXX object lib/CMakeFiles/cxx.dir/__/src/locale.cpp.o > [ 46%] [ 38%] Building CXX object lib/CM...

On 10/3/14 10:16 AM, Dan Albert wrote: >> >> I try to build libc++ and libc++abi for host x86_64(linux) and target >> arm(linux) but fail. >> > > Failing in what way? If this isn't working out of the box, we've done > something wrong. Yeah, it would help to know more specifics about where you're getting stuck. > > jroelofs might know more... For