[C++-sig] code generation problems

[James Mastro]

I am having a big problem with BPL. When my extension module is compiled by
bjam I think it is giving me bad code. I have a couple of functions in a C++
object that have almost the same signature, just slightly different names. I
have a free function in the extension module for each of these that calls
into the C++ object:

MyObject*    gObject;
void DoSomethingToObject( int data )
{
    gObject->DoSomething( data );
}

void SomethingElseToObject( int data )
{
    gObject->SomethingElse( data );
}

gObject is a valid ptr.

When this code executes, the gObject->DoSomething call actually calls
gObject->SomethingElse and vise versa! So I went and changed names thinking
maybe it was confused by similar names, that didn't help. I went as far as
to add some bogus parameters to SomethingElse but even that did not work. It
still happily calls the wrong function even though it was called with a
different number of parameters. Now I don't trust the VS debugger at all,
but as I step through the code everything seems to make sense. It's
executing the code it's stepping through, it's not just displaying the wrong
lines of code as it has done before for me.
The 2 free functions that are called from Python get called fine. They're 
called by other C++ code not related to my module and it works fine. It's 
just
the call into gObject that is bad from the wrapped free functions. If you 
ignore the fact that it's calling
a function with different number of parameters and filling those in with
garbage, even after the bogus call everything is working OK until an
assertion of mine fails because the wrong function has been called at the
wrong time. The gObject class looks just fine to me. Calling some other 
gObject member functions instead works fine. It's just the DoSomething and 
SomethingElse ones that are problematic. Thinking I probably had
bad code elsewhere or something I moved the calls to these 2 free functions
up so they're basically the first things called by the Python script, but I
get the same result.

Are there any known problems with compiling modules that would lead to
something like this? I don't even know where to start. I guess I will have
to try to come up with a small example demonstrating the problem. This is 
using boost 1.32 with vc-7_1.

-jim