?
Solved

Calling COM DLL that uses double precision values

Posted on 2003-02-25
18
Medium Priority
?
154 Views
Last Modified: 2010-05-01
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.
0
Comment
Question by:sparticus1701
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 7
  • 5
  • 4
  • +1
18 Comments
 
LVL 28

Expert Comment

by:AzraSound
ID: 8022837
May shed some light:

"INFO: Visual Basic and Arithmetic Precision"
http://support.microsoft.com/default.aspx?scid=kb;en-us;279755
0
 
LVL 1

Author Comment

by:sparticus1701
ID: 8026149
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
 
LVL 28

Expert Comment

by:AzraSound
ID: 8026219
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
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
LVL 1

Author Comment

by:sparticus1701
ID: 8026281
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
 
LVL 7

Expert Comment

by:webJose
ID: 8030697
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
 
LVL 1

Author Comment

by:sparticus1701
ID: 8035446
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
 
LVL 1

Author Comment

by:sparticus1701
ID: 8035453
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
 
LVL 7

Expert Comment

by:webJose
ID: 8036076
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
 
LVL 1

Author Comment

by:sparticus1701
ID: 8036196
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
 
LVL 7

Expert Comment

by:webJose
ID: 8036238
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
 
LVL 1

Author Comment

by:sparticus1701
ID: 8036329
My apologies.  This has been very frustrating and has wasted a week of work for another programmer and myself.
0
 
LVL 7

Expert Comment

by:webJose
ID: 8036465
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
 
LVL 28

Expert Comment

by:AzraSound
ID: 8036546
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
 
LVL 7

Expert Comment

by:webJose
ID: 8036568
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
 
LVL 28

Expert Comment

by:AzraSound
ID: 8037729
Nifty  :-)
0
 
LVL 1

Author Comment

by:sparticus1701
ID: 8037875
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
 

Expert Comment

by:SpideyMod
ID: 8375617
A request for a points refund has been made.  Experts you have 72 hours to object.

SpideyMod
Community Support Moderator @Experts Exchange
0
 

Accepted Solution

by:
SpideyMod earned 0 total points
ID: 8397618
PAQ'd and points refunded.

SpideyMod
Community Support Moderator @Experts Exchange
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

When designing a form there are several BorderStyles to choose from, all of which can be classified as either 'Fixed' or 'Sizable' and I'd guess that 'Fixed Single' or one of the other fixed types is the most popular choice. I assume it's the most p…
If you need to start windows update installation remotely or as a scheduled task you will find this very helpful.
As developers, we are not limited to the functions provided by the VBA language. In addition, we can call the functions that are part of the Windows operating system. These functions are part of the Windows API (Application Programming Interface). U…
Get people started with the process of using Access VBA to control Outlook using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Microsoft Outlook. Using automation, an Access applic…
Suggested Courses
Course of the Month12 days, 8 hours left to enroll

777 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question