3 votesDavid Hunter shared this idea ·
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
Still not supported in VS 15 Preview 2
A further comment by STL at http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx?PageIndex=3#comments confirmed that mutex, thread etc... will not be supported in VS 2015
I have been told, http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx?PageIndex=3#comments, in a comment by Raman Sharma that VS 2015 now supports <atomic> with /clr compiles but not <mutes>, <thread> etc...
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.
I just realized there is one C++ lambda feature that is no possible in C++/CLI. You can't define a
C++ lambda inside the body of a managed type member function. This seems a bit stricter than not being able to define a C++ class inside a Managed class. The C++ lambda may represent a class but it is an anonymous one so I would think the compiler could treat it in a special way.
I'm a bit confused by this. C++ lambda are supported by C++/CLI but .NET lambdas are not. The suggestion seems to talk about C++ 0x and then LINQ. Anyway I would love to see .NET lambdas supported by C++/CLI, capturing unmanaged types in them would be an extra bonus!
A an alternative as I suspect the above may be very hard to achieve how about a /WSomeName which would switch on all warning for which Microsoft headers are warning free. This can change based on VS version/update.
Support for v140_clang_3_7 platform toolset would be great as well
I was asked to clarify my comment about the using the control section of a std::shared_ptr in a managed C++/CLI class.
As of VS 2015 the std::shared_ptr has a member std::_Ref_count_base* _Rep. The _Ref_count_base class has members like _Incref and _Decref that std::shared_ptr uses to manage the reference count.
So the basic idea is to extract the std::_Ref_count_base* and store it in a managed version of shared_ptr which would participate in the reference counting of the unmanaged object. For instance it would decrement the refrence count in its finalizer. Ideally we could just store a pointer to the unmanaged shared_ptr but the interface does not provide any ***** mechanism to increment the reference count. Extracting the _Ref_count_base* from a std::shared_ptr requires a bit of hackery, for instance creating a fake struct with the same layout as a std::shared_ptr and using reinterpret_cast.
Sadly the manged shared_ptr equivalent class has to be a reference type not a value type as there are no destructors on value types.
Note I assume there are cleverer ways to do this. I gave up experimenting when I got something that worked and was reasonable.
I could easily imagine MicroSoft doing a System.Runtime.InteropServices.SharedPtr which would be far more elegant!
One alternative we use is to use something similar to Boost intrusive_ptr. Then managed objects store a raw pointer to an intrusively counted unmanaged object and participate in the reference count of that object. This of course has the usual down sides of intrusive pointers plus non deterministic garbage collection on the managed side can be an issue.
I agree with the post that it would be great if Microsoft provided a managed interop class that could work with the control section of a std::shared_ptr to jointly control the external reference count of an unmanaged object in managed code.