I'd like to put in a request that any warnings that are disabled in a TBB header are re-enabled at the end of that header. Currently I only see one example - atomic.h disables warning 4146 and does not re-enable it.
This is potentially alarming for us because we carefully select which warnings we want to see in our code, and then treat all occurrences of such warnings as errors in our build. If we include a header that disables one of these warnings, then we will no longer see that warning in any of our code that includes that header, directly or indirectly. Some Microsoft headers have the same behaviour, which has caused us significant pain in the past, so I'd like to be sure we can avoid it in TBB if at all possible.
For this particular case it would just want a
near the end of the file. However doing this does open you up to other problems, for example if you disable warning 4146 in another TBB header and then include atomic.h, the warning will be left in an enabled state after the include, meaning you still see the warning even though it looks like you disabled it. For that reason I'd also like to request that disable/default warning regions are as localized as possible, and as a policy warnings should not be disabled until all headers have been included.
And of course ideally, as in the thread below, all warnings would be fixed. :-)
A couple of additional warning we see in our builds with TBB and VC8 are C4244 (conversion from 'uintptr_t' to 'int', possible loss of data) in atomic.h and tbb_machine.h, and C4189 (local variable "count" is initialised but not referenced.)in tbb_machine.h. Might be worth enabling these particular warnings by default in your builds? Looks like they are still present in the latest dev drop.