Any ideas why Debug code linking against TBB causes "task.h" to go crazy, but Release is fine?

[ayembee]

This applies to the latest TBB 2.2 commercially-aligned release. I've started looking into a few specific areas where we could benefit from threading optimisations in our codebase, and TBB looked nice; seemed to align well to some of our problems areas. So, experimentation began today, simply making sure it would build when included in some of our source.

Linking against TBB in Release is fine -- linking in Debug goes haywire, and all the errors come from the file "task.h"

A sample of specific errors reported (I'm on windows under msvc 7.1) are:

...tbb\\include\\tbb\\task.h(85): error C2059: syntax error : 'constant'
...tbb\\include\\tbb\\task.h(92): error C2059: syntax error : 'constant'
...tbb\\include\\tbb\\task.h(98): error C2059: syntax error : 'constant'
...tbb\\include\\tbb\\task.h(104): error C2059: syntax error : 'constant'
...tbb\\include\\tbb\\task.h(113): error C2059: syntax error : 'constant'
...tbb\\include\\tbb\\task.h(794): error C2433: 'new' : 'inline' not permitted on data declarations
...tbb\\include\\tbb\\task.h(794): error C2365: 'new' : redefinition; previous definition was a 'member function'
...tbb\\include\\tbb\\task.h(794): error C2078: too many initializers
...tbb\\include\\tbb\\task.h(794): error C2440: 'initializing' : cannot convert from 'int' to 'void *'
Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
...tbb\\include\\tbb\\task.h(794): error C2143: syntax error : missing ';' before '('
...tbb\\include\\tbb\\task.h(794): error C2226: syntax error : unexpected type 'size_t'
...tbb\\include\\tbb\\task.h(794): error C2059: syntax error : ')'
...tbb\\include\\tbb\\task.h(794): error C2143: syntax error : missing ';' before '{'
...tbb\\include\\tbb\\task.h(794): error C2447: '{' : missing function header (old-style formal list?)
...tbb\\include\\tbb\\task.h(799): error C2660: 'tbb::internal::allocate_root_proxy::_free_dbg' : function does not take 2 arguments

I am making no changes to the library at all, and cannot see any differences in my two configurations that would cause "task.h" to go nuts. I tried taking out the preprocessor definition "_DEBUG" from the Debug build, just in case, but it didn't help.

What possible compiler settings/preprocessor definitions could be causing this kind of issue? Would really appreciate some suggestions, I can't go anywhere with code that's release-only :-/

Many thanks.

PS: I should point out I'm not compiling TBB itself, just compiling some of my own code with some header includes, linking against the appropriate TBB lib file.

[Alexey-Kukanov]

Most likely, what you see is the result of some preprocessor macros defined by other headers included prior to task.h. One particular suspicion is MFC.

[ayembee]

Hmm. I removed ALL the preprocessor definitions being passed in that I can set myself from the compiler/control string, and even tried making them identical to the release version. Same error. Some other tiny setting somewhere must be at work, but i cannot for the life of me think what it might be...

How/where can I see what you're considering for MFC?

[RafSchietekat]

Try to capture the output of the preprocessor and compare with the input where the problems occur. You may be able to see what may have been defined as a macro in a header that was included earlier in the same compilation unit, confirm that by finding the definition, and undefine it at an appropriate location.

[ayembee]

Finally had the time to return to this issue, but it doesn't want to go away.

Taking a look at the preprocessed code I could see a few cases where 'free' has become 'free_dbg' -- even though I have tried the simple step of unsetting _DEBUG and explicitly setting TBB_USE_DEBUG = 0 immediately before I include the tbb headers.


eg:

// includes for intel threaded building blocks
#undef _DEBUG
#define TBB_USE_DEBUG 0
#include "tbb/task_scheduler_init.h"
#include "tbb/parallel_for.h"
#include "tbb/blocked_range.h"


Once a library isn't obeying its own definitions I have to say I start getting a little lost. Something, somewhere is still somewhow getting the message that it's a debug build, but how? With _DEBUG unset, and TBB_USE_DEBUG set to 0, what's left?

Any more hints would be extremely welcome...

Regards.

[Alexey-Kukanov]

Some other header you include, supposedly MFC, defines "free" as a macro.

[Alexey-Kukanov · Accepted solution]

Ok here is the story. I am looking at Visual C++ 2005but I guess it equally applies to other VS versions.

The header file crtdbg.h in Visual C++ redefines free(p)to _free_dbg(p, something) under the condition of _CRTDBG_MAP_ALLOC macro being defined.

The only places where I found _CRTDBG_MAP_ALLOC defined areafx.h and atldbgmem.h, both headers in atlmfc/include.

Therefore I conclude that this redefinition is for sake of MFC support. And I guess afx.h is included with near every other MFC header.

The easiest workaround I can suggest is to include all TBB headers before any MFC header.

[ayembee]

Was unable to find a direct include to those files, but it's clearly the right explanation -- and I've identified one of our own internal headers as being the one that (somehow/indirectly) ends up bringing that into the code... Ensuring that's declared a little later does the trick.

So, now that Debug/Release both build fine -- it's time to actually get stuck into the code and see just what kind of performance gains we can wring out of this library ;)

Many thanks all.