Calling a DLL with a & (ampersand) in the declaration

[peabody_bass]

Hi,

I'm trying to call an external DLL and having issues calling an important function.  The 'FindDevices' call has the following declaration:

long FindDevices(long &DeviceCount);

I've never come across calling an external function with an ampersand (indicating that a reference, rather than a pointer, shall be passed) before.  Is this possible with LabView?

I've tried many permutations of the DLL configuration, but it usually crashes the entire development environment.  Here is a link to the DLL and *.h file if you'd like to give it a shot.  It's a 64-bit DLL, and I've been developing this on 64-bit Labview and Windows 7 x64.  It also requires the configuration file 'ZStepperSettings.xml' to be in the same directory as the DLL.

Thanks for your time.

[nyc_(is_out_of_here)]

Do you think that that may be that is a typo or a mistake?

Could you call the manufacturer and find out?

[nathand]

It's a C++ reference (but see also http://yosefk.com/c++fqa/ref.html). I've never needed to call such a function from LabVIEW - most manufacturers provide headers for standard C, not C++ - but you could try passing the parameter as though it were a standard pointer, it's likely to work.

[peabody_bass]

Thanks for the reply.  Passing as a (32-bit signed) pointer was the first thing I tried.  It causes LabView to crash (only 90% of the time though, which is weird/disturbing).

I'm trying to get more information from the manufacturer.  My goal is just to ditch the DLL completely as it's just managing a COM port and parsing serial commands.

[nathand]

Does it work the other 10% of the time, or it just doesn't crash? If it works, then I'd suspect maybe some other part of the Call Library setup is wrong, for example using the wrong calling convention.

[rolfk]

For scalars the C++ reference syntax should be equal to a standard C pointer. For other datatypes that is certainly not guaranteed. Since long is a scalar I would guess the problem to be elsewhere. Are you sure the calling convention is correct?

Also the effect that it only causes the 1097 error sometimes, as well as crashing only sometimes is not so strange. There is no supervisor that can 100% surely detect if there is some memory violation during a call to an external function. Eventhough the parameter configuration is wrong or the DLL does something bad, this doesn't always result in a behaviour that LabVIEW could detect or would always cause a crash. It depends on the actual memory layout of your process at the moment this function is called if the error will be causing one of these problems. But be assured that if there is an error in how the function is configured or a bug in the function about how it access the memory especially for writing operation, something bad is done to the memory that will sooner or later cause very serious problems to your application.

EDIT: It seems that while C++references for scalar types are usually implemented as pointers by the compiler, there is nothing in the C++ standard that mandates this nor defines in any way how they should be implemented. So basically C++ references are not a safe datatype to use if you want to allow a function to be callable by anything else than code compiled with the same C++ compiler. Basically anything C++ specific is not safe at all in that sense. And anything standard C conformant mostly only by convention and not by specific requirements set forth in the C standard.