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
(thinking…)
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Andreas shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

14 comments

Sign in
(thinking…)
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