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

[Adri_C__S_]

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.

[SergeyKostrov]

>>...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) ...

[SergeyKostrov]

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

[RafSchietekat]

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.

[Adri_C__S_]

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!.

[RafSchietekat]

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).

[SergeyKostrov]

>>...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

[RafSchietekat]

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?

[Adri_C__S_]

Raf, I think you're over-reacting because I also decided to try it,

I wasn't the only one then :D Merry Xmas!.

[jimdempseyatthecove]

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

[Adri_C__S_]

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.

[SergeyKostrov]

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!

[Adri_C__S_]

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!

[Adri_C__S_]

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...