[C++-sig] Re: Extension DLLs nonfunctioning with MSVC 7.1 (beta)

[Christophe Pradal]

i work with Python2.3,  Visual C++ SP5, STLPort .

i have my own shared_pointer ( RefCountPtr )and want to use it with boost.
If i add an assignement operator with implicit cast:
template<class U> RefCountPtr( const RefCountPtr<U>&ptr ) {...}
i have the following message

ImportError: DLL load failed: Invalid access to memory location.

But when i comment this line, all is OK.

What i want to do is:
in C++:
class A {};
class B : A {};
void f(const RefCountPtr<A>&)

In python
b= B()
f(b)

I think it is a Visual C++ bug, but i don't know how to bypass it.
Thanks again for your help.
Raoul Gough a écrit:

>Christophe Pradal <christophe.pradal at cirad.fr> writes:
>
>  
>
>>Raoul Gough a écrit:
>>
>>    
>>
>>>David Abrahams <dave at boost-consulting.com> writes:
>>>
>>>
>>>      
>>>
>>>>Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>>>
>>>>
>>>>        
>>>>
>>>>>When I build the Python tests with MSVC (7.1 beta, version 13.10.2292)
>>>>>I get non-functioning DLLs. With a debug build, importing an extension
>>>>>module into Python aborts silently, and with the release builds it
>>>>>reports "ImportError: DLL load failed: Invalid access to memory
>>>>>location." I'm reasonably sure this was working a couple of weeks ago.
>>>>>
>>>>>          
>>>>>
>>>[snip]
>>>
>>>      
>>>
>>>>It's working for me with vc7.1 release and a debug-python build:
>>>>
>>>>        
>>>>
>>>[snip]
>>>
>>>Niall Douglas also reports that it works for him. I guess I must have
>>>trashed something in my environment, so I'll have to track it down
>>>locally. Thanks to you both for confirming this.
>>>      
>>>
>>Hello,
>>I have the same problem with MSVC 6 SP5 and  STLport and a recent
>>boost on cvs.
>>When i try to import my module,
>>i have the following message
>>
>>File "<stdin>", line 1, in ?
>>ImportError: DLL load failed: Invalid access to memory location.
>>
>>Is Raoul solve is problem?
>>    
>>
>
>No, I haven't ever figured out why this occurs, because I usually use
>g++ anyway. I did determine that the generated DLLs are broken
>internally in some way, for instance the dependency walker sometimes
>just reports that the DLL is corrupt. I've tried different versions of
>the Microsoft linker with identical results, so I was guessing that
>the problem is introduced during the compilation phase.
>
>On the other hand, your environment is quite different to mine - I
>have the beta version of the .NET compiler (MSVC 7.1 beta) and the
>Microsoft-supplied (Dinkumware?) standard library. This is all very
>weird, but I'll try to investigate it further. Any more details about
>your experiences with this could be helpful.
>
>  
>