Re: dll dependencies
"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:f4n3fm$iu8$1@news.datemas.de...
jc wrote:
[... path1 is OK, but...]
but if i choose path2 m_strxmlfname will get corrupted
The code you posted sheds no light on the problem, however, you can
get closer to finding the cause of your trouble if you, while in the
debuger, put a conditional breakpoint and supply the condition that
would indicate the change in 'm_strxmlfname' (whatever that is).
Essentially you need to understand _while running your program_, who
and when changes (corrupts) your variable. That should definitely
get you a bit further in your research.
Another thing is that if you create a static object, like a global,
say, XML parser, in a DLL and then try passing it by address around
to other modules in your program, you can definitely be in hot water
because DLLs can have their own heaps (not shared) and an address
from it might look like a valid pointer while in the other module,
All pointers are good process-wide. You can't mix and match allocator with
a different deallocator, but the address returned is perfectly good to use
from any DLL.
Now, if you have inline functions using that pointer, instead of making
v-table calls, you will most likely run into ODR violations.
but it doesn't have to be. That's why you should probably use no
singletons or at least avoid creating them in the data segment and
instead always use dynamic creation ('new') from the RTL, which they
all should link in as a DLL (make sure they all have the same link
flag for the RTL).
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask