Using C++11 threads in Visual Studio 2012 CLR applications

[Saeed Amrollahi]

Dear All
Hello

I would like to use C++11 basic threading facility like std::thread
in a C++ CLR project. Unfortunately, the pre-processor issued the following
error message:
fatal error: C1189: #error: <thread> is not supported when compiling with
/clr or /clrure.
I can't change my project type, because it has to uses the .NET framework
to connect to SQL Server database. What other threading facilities, VS 2012
has for such conditions? PPL, Concurrency Runtime, ...
FYI, I'm eager to use Native C++11 thread facilities as first and best
option and I'm not interested on using .NET framework threads.

Please shed some light.
-- Saeed Amrollahi Boyouki

 

[Victor Bazarov]

I would like to use C++11 basic threading facility like std::thread
in a C++ CLR project. Unfortunately, the pre-processor issued the following
error message:
fatal error: C1189: #error: <thread> is not supported when compiling with
/clr or /clrure.
I can't change my project type, because it has to uses the .NET framework
to connect to SQL Server database. What other threading facilities, VS 2012
has for such conditions? PPL, Concurrency Runtime, ...

CLR threads, Windows threads, to name a couple. But...

The 'comp.lang.c++' newsgroup is for discussions on the language, not on
any tools that might bear "C++" in their name or claim to implement C++
compiler. Usually, like in your case, there are other places where you
can discuss those; see http://msdn.microsoft.com/.

FYI, I'm eager to use Native C++11 thread facilities as first and best
option and I'm not interested on using .NET framework threads.

Are you expecting to be commended for [saying] that? What makes you
think that native threading facilities are best?

In your case, the "native facilities" don't seem available. Are you not
interested in accomplishing the ultimate goal - to build your program?
I can't imagine there are no threads in .NET, so the only thing seems to
be stopping you is that you're "not interested". Aside from the desire
to learn the "native facilities", what's directing you *away* from the
truly *native* mechanisms in your *apparent* platform of choice (.NET)?

Learn the tools you have, the native platform means are part of those.
If you learn the language and all library elements, it's good. But
you're going to be limited by [the absence of] their implementation.
It's like saying that you're eager to learn to sail, and not interested
in using a row-boat, while treading water in the middle of the ocean
with a couple row-boats at your disposal.

Either way, best of luck, of course!

V

 

[Saeed Amrollahi]

CLR threads, Windows threads, to name a couple. But...



The 'comp.lang.c++' newsgroup is for discussions on the language, not on

any tools that might bear "C++" in their name or claim to implement C++

compiler. Usually, like in your case, there are other places where you

can discuss those; see http://msdn.microsoft.com/.

OK. I guess comp.lang.c++ isn't totally irrelevant to answer this question.

FYI, I'm eager to use Native C++11 thread facilities as first and best

option and I'm not interested on using .NET framework threads.

Are you expecting to be commended for [saying] that?

No!
What makes you think that native threading facilities are best?
As you may be know (my previous post about C++ multi-threading,)
I try hard to learn and apply C++ threads facility, and my policy is to
use native C++11 facilities in first place, If I can't, I'll use
other platform-dependent or third-party threading libraries.
It's just my personal preference.

In your case, the "native facilities" don't seem available. Are you not

interested in accomplishing the ultimate goal - to build your program?

Actually, I'm very interested to finalize my development W.R.T my
preferences.

I can't imagine there are no threads in .NET, so the only thing seems to

be stopping you is that you're "not interested". Aside from the desire

to learn the "native facilities", what's directing you *away* from the

truly *native* mechanisms in your *apparent* platform of choice (.NET)?



Learn the tools you have, the native platform means are part of those. All right.

If you learn the language and all library elements, it's good. But

you're going to be limited by [the absence of] their implementation.

It's like saying that you're eager to learn to sail, and not interested

in using a row-boat, while treading water in the middle of the ocean

with a couple row-boats at your disposal.

I asked the question to remove such difficulties/ambiguities you just
mentioned.

Either way, best of luck, of course!

Thank you. I'll try to focus on CLR threads.

 

[Tobias Müller]

Dear All
Hello

I would like to use C++11 basic threading facility like std::thread
in a C++ CLR project. Unfortunately, the pre-processor issued the following
error message:
fatal error: C1189: #error: <thread> is not supported when compiling with
/clr or /clrure.
I can't change my project type, because it has to uses the .NET framework
to connect to SQL Server database. What other threading facilities, VS 2012
has for such conditions? PPL, Concurrency Runtime, ...
FYI, I'm eager to use Native C++11 thread facilities as first and best
option and I'm not interested on using .NET framework threads.

If your code is mainly in .NET (i.e. if you are using ^ and gcnew alot),
then use .NET threads. But then I'd suggest that you use C# instead of
C++/CLI anyway.

If you only use .NET for the database connection, then use C++ threads.
You can easily wrap your .NET database classes in a native interface. You
don't have to compile your entire project with /clr, you can use it for a
single file and compile the rest normally. You can even switch it on and of
in a single file with a #pragma.

Don't use C++/CLI as your main programming language, that only leads into
problems. C++/CLI is useful for calling .NET from native code, but
otherwise use plain C++ or C# if you need .NET alot.

Tobi

 

[Saeed Amrollahi]

Note this is not a C++ question (/clr is not C++). You may get better

answers from some Microsoft or Windows forums.



Anyway, you could always try to split your project into two and encapsulate

either threading parts or database access into a separate static or dynamic

library. Not sure if it would be worth it.

Unfortunately, the project is small enough to split it to smaller ones.
BTW, Thank you for your answer.
-- Saeed