[Boost-testing] Boost Threads and Mac

From: Stephen W. Carson (StephenC_at_[hidden])
Date: 2006-03-09 17:58:25

    We're trying to benefit from all this testing I've been doing with 
CodeWarrior for the Mac. Our Mac programmer has been trying to build 
boost thread from boost version 1.32.0 in the CodeWarrior GUI and got 
the following errors:
Error: illegal explicit conversion from 'unsigned long' to
'std::vector<void *,std::allocator<void *>> *'
tss.cpp        line 114      MPGetTaskStorageValue(tss_data->native_key));

Error: function call 'MPSetTaskStorageValue({lval} unsigned long, 
std::vector<void *, std::allocator<void *>> *)' does not match
'MPSetTaskStorageValue(unsigned long, unsigned long)'
tss.cpp        line 130      if 
(MPSetTaskStorageValue(tss_data->native_key, temp.get()) != noErr)

    I suggested she try out the latest stable source (v1.33.1) and you 
can see her conclusions below.

    I guess my main question is how this is building on my Mac as part 
of the tests. In general I found the whole process of getting the tests 
set up correctly quite confusing and I am not sure how to pull out of 
the JAM sctips the knowledge we need to set CodeWarrior GUI to build 
boost. Rene? Anyone?

-------- Original Message --------

Hi Stephen,

I have been looking at the latest boost source code, and that tss.cpp 
file has not changed...

I also looked for the functions MPGetTaskStorageValue() 
and MPSetTaskStorageValue() using Spotlight everywhere on my Mac, and 
nowhere is either of these functions defined in the way that tss.cpp is 
attempting to use them.

Basically, tss.cpp is calling MPGetTaskStorageValue() with the correct 
parameter, but expecting it to return a vector, when in fact it returns 
an unsigned long.

/from Multiprocessing.h:/
typedef UInt32                          TaskStorageValue
...
extern TaskStorageValue
MPGetTaskStorageValue(TaskStorageIndex taskIndex)             
AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER;

/from tss.cpp:/
typedef std::vector<void*> tss_slots;
...
    tss_slots* slots =;
...
    slots =tatic_cast<tss_slots*>(
        MPGetTaskStorageValue(tss_data->native_key));

Similarly, tss.cpp is calling MPSetTaskStorageValue(), passing an 
unsigned long (which is correct) and a vector, while the function is 
defined to expect 2 parameters, both of which are unsigned long.

/from Multiprocessing.h:/
EXTERN_API_C( OSStatus )
MPSetTaskStorageValue(
  TaskStorageIndex   index,
  TaskStorageValue   value);

/from tss.cpp:/
        std::auto_ptr<tss_slots> temp(new tss_slots);
        if (MPSetTaskStorageValue(tss_data->native_key, temp.get()) !=oErr)
            return 0;

So, I haven't actually tried to compile the latest code, but it sure 
looks to me like it would be a futile undertaking.

Is there any way to check whether tss.cpp was something that was 
included in your testing?

I compared the previous tss.cpp (the one that does compile for me) and 
it is extremely different.  Here is some code from it that used these 
functions:
    TaskStorageValue ulValue =PGetTaskStorageValue(m_key);
...
    cleanup_handlers* handlers =einterpret_cast<cleanup_handlers*>(
        MPGetTaskStorageValue(key));
and
        OSStatus lStatus =PSetTaskStorageValue(key,
            reinterpret_cast<TaskStorageValue>(handlers));
...

-- 
Stephen W. Carson, Software Engineer
DirXion Software in St. Louis, MO
[phone]
"Premature optimization is the root of all evil." -Donald Knuth