I suggest you ...

Support c++11 concurrency header files in c++/cli

When using the /clr switch in VC++ 2012, it is not possible to include some of the new c++11 header files (i.e. <atomic> / <thread>) as compilation will break.

One typical application of c++/cli is to wrap a native class inside a (managed) ref class to expose its functionality to the .net world.

The restriction previously described prevents a ref calss to consume a native class with members like std::thread or std::atomic<T>.

A workarround (pimpl-idiom) is discussed in this topic:
(http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/9771f61c-05b7-4e3e-96fb-ac9ea31ac3f4)

The former approach requires to change existing code, therefore support for the new c++11 header files in c++/cli is proposed.

480 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Andreas shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    14 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Anonymous commented  ·   ·  Flag as inappropriate

        The unmanaged code should just compile and be unavailable in Dumbo-managed codes like C# and Basic. Perhaps a feature that allows mixed managed/unmanaged interfaces exclusively for C++ could be brainstormed for a futuristic release.

      • Anonymous commented  ·   ·  Flag as inappropriate

        You can keep the operations on std::atomic unavailable in /clr. Many people just need to be able to access a class with a std::atomic data member from managed code. They don't need to operate on the std::atomic itself from managed code. So with /clr you could just declare the atomic types with the correct memory layout and no operations.

      • C.J.B. commented  ·   ·  Flag as inappropriate

        I tried to migrate a project from

        VS 2015 (Version 14.0.25431.01 Update 3)
        to
        VS 2017 (Version 15.2 (26430.16)

        and got an C3821.

        I reduced the problem to the use of atomic variable within an native class with an gcroot variable.

        class nativeInteropClass
        {
        private:
        gcroot<System::Object^> syncObj;

        std::atomic<int> AtomicSuperCounter;
        public:
        nativeInteropClass()
        : syncObj(gcnew System::Object())
        {
        // std::atomic<int> AtomicSuperCounter;
        AtomicSuperCounter.store(0);
        }
        };

      • RomanK commented  ·   ·  Flag as inappropriate

        Simple hack.

        #pragma managed(push,off)

        #ifdef _M_CEE
        # undef _M_CEE
        # include <thread>
        # include <mutex>
        # define _M_CEE 001
        #else
        # include <thread>
        # include <mutex>
        #endif
        #pragma managed(pop)

      • David Hunter commented  ·   ·  Flag as inappropriate

        STL just tweeted that <mutex> will be usable in /clr code in the next toolset update for 2017, maybe 15.3. My guess is that they may announce it at the Build conference

      • John Schroedl commented  ·   ·  Flag as inappropriate

        I just compiled a .cpp file with /clr with #include <atomic> and it built! Mind you, I didn't actually use anything from there yet but it didn't even compile before.

      • Ryan Wong commented  ·   ·  Flag as inappropriate

        Notice to Microsoft: the request is not so much about full functionality of atomic / thread / mutex under C++/CLI which might be incompatible, but about a C++/CLI project being able to parse through the headers of unmanaged classes (properly enclosed within "pragma managed off"). In other words, unmanaged classes inside a C++/CLI project should be allowed to use the unmanaged parts of C++11.

      • Dimitar Dobrev commented  ·   ·  Flag as inappropriate

        I support this issue. <atomic> is being increasingly used, custom atomic classes are being deprecated in its favour.

      • David Hunter commented  ·   ·  Flag as inappropriate

        An alternative is to use the Boost threading stuff which as of Boost 1.53 is very similar to the standard stuff in terms of naming. In fact I use various typedefs so I can switch between boost and standard stuff. I use this extensively in C++/CLI code and have not seen any problems.

        It would be nice if Microsoft made a statement about support for standard thread stuff in C++/CLI.

      Feedback and Knowledge Base