Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

[SOLVED] Setting the value of a tbb::atomic from standard input

Adri_C__S_
Beginner
504 Views

Hi,

this is just something that occurered to me and decided to try. Would it be possible/useful to make something like this work?:

[cpp]

tbb::atomic<char> q;

std::cin>>q;

[/cpp]

I tried and got this error: [plain] error: ambiguous overload for 'operator>>' in 'std::cin >> q'[/plain].

Thanks.

0 Kudos
13 Replies
SergeyKostrov
Valued Contributor II
504 Views
>>...Would it be possible/useful to make something like this work? No. You need to define a C++ operator '>>'. I did a verification and this is what I had: ... ...Error C2679: binary '>>' : no operator found which takes a right-hand operand of type 'tbb::atomic' (or there is no acceptable conversion) ...
0 Kudos
SergeyKostrov
Valued Contributor II
504 Views
Actually, a simple workaround works (!) and here it is: ... tbb::atomic< char > q; std::cin >> ( char & )q; ... Note: Tested with VS 2005 and TBB v4.0 Update 3
0 Kudos
RafSchietekat
Valued Contributor III
504 Views
Ouch, that hurts! I have a special place in my heart for atomics, and this is not how they should be treated, for various reasons, not all of them pedantic, even if at first sight that "simple workaround" seems to be working (I'm surprised that you didn't get scolded by the compiler for doing this?). It's easy enough to define a specific istream overload instead, something like "static inline std::istream& operator>>(std::istream& is, tbb::atomic<char>& a) { char c; is >> c; a = c; return is; }", or something that actually compiles (it probably does, but I haven't tested), or something with templates to accommodate more types. But at the same time you probably wouldn't want that as a standard part of the library, because there's probably no simple way to specify memory semantics (I don't think a manipulator can be defined without bridging the whole family of stream classes?), which is relevant because there's a conflict between what probably applies (relaxed, which is cheap) and what's the safe default (sequentially consistent, which is expensive and is assumed above by the assignment operator), so it even seems better to define a regular function with an explicit name than a fancy-looking operator.
0 Kudos
Adri_C__S_
Beginner
504 Views
Hello there. Thanks for your answers. This is something that I decided to try, just to see what would happen and wanted to know your opinions. Cheers!.
0 Kudos
RafSchietekat
Valued Contributor III
504 Views
I may have left some doubt in my reply above: what was troublesome was the suggested workaround with a cast, but a local stream operator definition should be all right (if used wisely). Also, I've now "unvanished" the tbb::atomic template parameter "char" (using lt/gt references).
0 Kudos
SergeyKostrov
Valued Contributor II
504 Views
>>...This is something that I decided to try... Raf, I think you're over-reacting because I also decided to try it, let's say just for interest... and I promise you that I will never-never again use ( char & ) cast with 'atomic'. Merry Christmas! Best regards, Sergey
0 Kudos
RafSchietekat
Valued Contributor III
504 Views
I hope I didn't overreact so much as try to be clear about several possibly relevant aspects (with a touch of humour, in case this was not obvious). So was there really no complaint about breaking strict aliasing rules, or did you not enable them, or are C-style casts and/or references excluded, or did you ignore what the compiler thought of this, or something else?
0 Kudos
Adri_C__S_
Beginner
504 Views
Raf, I think you're over-reacting because I also decided to try it,
I wasn't the only one then :D Merry Xmas!.
0 Kudos
jimdempseyatthecove
Honored Contributor III
504 Views
Sergey, I think std::in >> (volatile char&)q; would be more syntatically correct, however the >> operator might not accept volatile. What you want to assure is that q is actually written as oppose to held in register. Jim Dempsey
0 Kudos
Adri_C__S_
Beginner
504 Views
however the >> operator might not accept volatile
It won't. I tried to write into a volatile: [cpp] volatile char exit; std::cin>>exit; // g++ complains here with "error: ambiguous overload for 'operator>>' in 'std::cin >> exit" [/cpp] before trying the atomic approach.
0 Kudos
SergeyKostrov
Valued Contributor II
504 Views
I see that discussion continues... :) >>...It won't. I tried to write into a volatile... Here are a couple of test-cases with a Visual Studio C/C++ compiler ( just for your reference ): [ Test-case 1 - Compilation Error ] volatile char chExit1; std::cin >> chExit1; ... Error C2679: binary '>>' : no operator found which takes a right-hand operand of type 'volatile char' (or there is no acceptable conversion) ... [ Test-case 2 - Compilation Warning ] volatile char chExit2; std::cin >> ( volatile char )chExit2; ... Warning C4197: 'volatile char' : top-level volatile in cast is ignored ... [ Test-case 3 - Compiled without any Warnings or Errors ] char chExit3; std::cin >> ( char )chExit3; [ Test-case 4 - Compiled without any Warnings or Errors ] char chExit4; std::cin >> ( char & )chExit4; Merry Christmas, a.c.sant!
0 Kudos
Adri_C__S_
Beginner
504 Views
Sergey Kostrov wrote:

I see that discussion continues... :)

Not discussion, but friendly comments :D
Sergey Kostrov wrote:

Here are a couple of test-cases with a Visual Studio C/C++ compiler ( just for your reference ):

[ Test-case 1 - Compilation Error ]

volatile char chExit1;
std::cin >> chExit1;
...
Error C2679: binary '>>' : no operator found which takes a right-hand operand of type 'volatile char' (or there is no acceptable conversion)
...

[ Test-case 2 - Compilation Warning ]

volatile char chExit2;
std::cin >> ( volatile char )chExit2;
...
Warning C4197: 'volatile char' : top-level volatile in cast is ignored
...

[ Test-case 3 - Compiled without any Warnings or Errors ]

char chExit3;
std::cin >> ( char )chExit3;

[ Test-case 4 - Compiled without any Warnings or Errors ]

char chExit4;
std::cin >> ( char & )chExit4;

Wow, thanks for those tests. Myself, I only tried the second approach, but it's always good to know what works and what not.
Sergey Kostrov wrote:

Merry Christmas, a.c.sant!

Thanks! Same to you!
0 Kudos
Adri_C__S_
Beginner
504 Views
Hello again. I decided to try Sergey's other tests with a MingW compiler: [Test case 1, 2, 3 - Compilation error] [cpp] error: ambiguous overload for 'operator>>' in 'std::cin >>chExit' [/cpp] [Test case 4 - No errors, no warnings] Just curious with the differences between compilers...
0 Kudos
Reply