Calling COM DLL that uses double precision values

We have a COM dll that is written in C++.  The dll does quite a few things with double precision floating point numbers.  However, it is designed such that given all the same inputs, you should always get out the same thing.

The code calculates two double values, say like d1 and d2.  Then we have a conditional statement like "if (d1 < d2) {...".  We know about the danger of using comparisons with doubles that can't be perfectly represented in binary.  But given the same inputs, we should always get the same sequence, there are no random variables in these equations.

This code has been tried and true for years, so we know there's not a bug, and as of yet we have always called it from other C++ modules.

We know want a VB6 module to call this code.  When it does, the numbers we should be getting out of d1 and d2 are not the same.  They begin to differ around the 10th decimal place.  Because of these differences, the if statement occasionally evaluates differently, and the results do not match that of when it was called from C++.

For kicks and giggles we wrote two more test apps in C# and VB.NET, and they seem to work fine.

The first reaction is to use an epsilon value to replace the < operator, and set that epsilon in the 10th decimal place range.  Doing so does make it so that the C++ and VB6 callers get the same result, but it breaks the results we were getting from the old C++ module, and that's no good for us.

What we want to know right now is, what is happening under the covers that makes VB6 evaluate double precision operations different.  We think it's way down in the runtime, and we don't know what's going on that low in the code.
LVL 1
sparticus1701Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

AzraSoundCommented:
May shed some light:

"INFO: Visual Basic and Arithmetic Precision"
http://support.microsoft.com/default.aspx?scid=kb;en-us;279755
0
sparticus1701Author Commented:
Like I said before, we know about precision round off.  The is C++ code which has the same round off problem, but given identical inputs (which are all integers), when it's called from VB, the results are different.

One would expect that given the same inputs to an equation, the same round offs would occur, and you would always have the same result.

The question is, is the VB runtime doing something to the C++ code besides just passing it directly to the processor?
0
AzraSoundCommented:
That is what I don't understand...if all the VB code does is pass the data values into your C++ dll, I don't see how the dll would perform calculations any differently.  When the dll initially receives the values from VB, does it appear they are intact and correct?  Once processing is passed on to your dll, VB should have nothing to do with how the dll performs its calculations.  If it does, it would be a learning experience for me, as well, to see why that is so.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

sparticus1701Author Commented:
We have verified that the inputs are received correctly.  Logically, VB should just send all the code directly to the CPU.  But what we are seeing would suggest that the VB runtime is marshalling data somehow.

We are attempting to change the COM dll to a COM exe so that the C++ code will remain in it's own memory space rather than residing in VB's.  We are hopeful for that.
0
webJoseCommented:
Show the IDL definition of the method to retrieve the results.  Also show the VB code that makes the call, along with the variable declarations.
0
sparticus1701Author Commented:
Basically the only thing passed through the interface is a string, which is a filename to a list of parameters that the C++ code reads in.  It performs all it's calculations from that data.
0
sparticus1701Author Commented:
An interesting thing is, if we use the Debug build, it works fine.  Only the Release build exhibits this behavior (when called from VB6).
0
webJoseCommented:
Ok, if the debug build works, it may be a memory problem.  For example, memory allocations using the new operator will allocate 4 extra bytes just in case.  This is not the case of the release build.

There are also other differences that may be causing the problem.  Have you debugged using the VB exe?

And it would really help us if you showed what I asked for.
0
sparticus1701Author Commented:
We have figured that it dealt with memory, since it only occurs in the VB app memory space.  But it's not the C++ code.  This code has been around for years, passed all Boundschecker tests, and has been visually reviewed by half a dozen programmers over the last years.

All the VB code has been debugged.  This occurs in shipping software as well as small test apps.

For security I must obfuscate the code a little:

[local] HRESULT CreateDesign ([in] BSTR bstrFilePath);

The VB caller is as follows:

dim oDesigner as DesignerLib.CoDesigner

call oDesigner.CreateDesign(strFilePath)


"And it would really help us if you showed what I asked for." -- Don't get holier than thou on me.  You haven't earned that right.
0
webJoseCommented:
Since English is not my mother tongue, I may be misunderstanding, and if so, please forgive me.

But if "You haven't earned that right." is the attitude you'll show towards respectful requests for information, you can forget about me.
0
sparticus1701Author Commented:
My apologies.  This has been very frustrating and has wasted a week of work for another programmer and myself.
0
webJoseCommented:
Ok, since it seems that VB will not pass any information other than the filename (I was hoping the method you were going to show was passing numeric data), then I must rule in favor of VB.  VB is fully COM-compliant and there should be no memory problems in that respect.  Furthermore, the only information VB is passing is a filename!

What I suggest is that you debug the C++ dll using the VB executable.  You could build the VB exe with debug information so you can step through the VB code as well.  Try debugging like this and see what happens.
0
AzraSoundCommented:
Agreed, passing only a filename should have no effect on your calculations.  If there is any other communication between VB and your COM DLL, please post it here.

Can you debug VB and your COM DLL simultaneously?  Such as in VB you can have two separate instances of VB opened, a standalone exe project, and a COM DLL project, and step through both.
0
webJoseCommented:
AzraSound:

Yes, you can debug a C++ dll with almost any exe.  Particularly, if you build a VB exe with debug information, then use it to debug a dll the exe is using in Visual C++, VC++ will use the debug info generated by VB so you can actually see the VB code in VC++!!  It is freakin' great if you ask me. :-)
0
AzraSoundCommented:
Nifty  :-)
0
sparticus1701Author Commented:
We already know that the debug C++ works, and stepping into the release code is not an option.

Also, if there were a bug in the C++ dll, calling it from a C++ app would yield the same bug.

COM is an issue, since VB has no problem calling in COM.  Previously, this also ran in a standard Win32 dll and calling it from VB had the same problem.

The problem really must be something the VB runtime is doing to memory, or something is wrong with the VC++6 compiler and it's interoperability with VB.

0
SpideyModCommented:
A request for a points refund has been made.  Experts you have 72 hours to object.

SpideyMod
Community Support Moderator @Experts Exchange
0
SpideyModCommented:
PAQ'd and points refunded.

SpideyMod
Community Support Moderator @Experts Exchange
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.