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
(636) 717-2367
"Premature optimization is the root of all evil." -Donald Knuth