Problem in calling c++ dll

[nvo]

Hi,

I'm having problems getting a dll written in c++ to work when called in LabView. I do not have the source code but I know it works since I tested it with a Visual C++ demo. I get a 1097 error the first time I call it and no errors any time after that. However, the dll doesn't seem to do anything. I have attached the header file and my labview code below.

Edit: I can't seem to upload attachments so i'll post screenshots

relevant portion of header file:

#ifndef

#define

#include

using

#ifdef

extern

#endif

//#pragma pack(1)

typedef

} LicenceDate;

LicenceDate expiryDate;

} SoftwareLicence;

LicenceDate expiryDate;

} EsessionLicence;

#ifdef

SoftwareLicence &PSoftwareLicence,

EsessionLicence &PESessionLicence);

[nathand]

Sorry, but that formatted so poorly (and it looks like it lost some words) in the copy-paste that it will be hard to help. What error do you get when you try to attach a file? If you can't attach the header, try pasting it into a code block (there's a button for it in the editor, to the left of the smiley face), which will prevent it from attempting to auto-format.

[nvo]

#ifndef passdecipherdynlowsafe_h
#define passdecipherdynlowsafe_h 1
#include <string>
using namespace std;
#ifdef __cplusplus
extern "C" {
#endif

//#pragma pack(1)
typedef struct {
		unsigned short year; //base year + 1900
		unsigned short month; //base month + 1 
	} LicenceDate;

typedef struct {
		LicenceDate   expiryDate;
		unsigned int  privateFeature;
	} SoftwareLicence;

typedef struct {
		unsigned short maxNbOfToken;
		LicenceDate    expiryDate;
	} EsessionLicence;	


#ifdef WIN32

	//checkLicenceKey
	__declspec(dllexport) bool __cdecl AfxDisplayMessage1 (
							unsigned short PSoftwareNb,
         const string &PLicenceKeyValue, 
         const string &PProductServerId, 
    	const string &PLicenseServerId,
    	unsigned short PVersion,    	
    	unsigned short PRelease,
    	bool& PIsWellFormed,
    	bool& PIsSoftwareLicenceValid,
    	SoftwareLicence &PSoftwareLicence,
    	bool& PIsESessionLicenceValid,
    	EsessionLicence &PESessionLicence);
#else
...

 I hope that's better 😃

[nathand]

First, I don't know how successful you'll be calling a C++ DLL. LabVIEW normally only calls DLLs that provide a standard C interface, without the C++ extensions. (This seems to be the day to ask about it, though - someone else also asked about passing C++ references today, as your DLL does.)

It would help if you can attach your VI. What error are you getting when you try to attach a file? Have you tried a different web browser? If you can't attach your VI, try a snippet instead, since that's an image but it contains actual code. Also, I'm still on LabVIEW 2012, so please save in that version or earlier if you'd like me to look at it.

Have you tried increasing the Error Checking level to "Maximum" in the Call Library configuration, to see if you get a more descriptive error? Are you sure the calling convention is correct? Most likely it should be C, and not WINAPI.

[rolfk · Accepted solution]

You can't really interface this function directly to the Call Library Node. The problem here are the string parameters. That are C++ object template classes, something only the C++ compiler that created the DLL can guarantee to handle properly.

People using C++ need to understand that using C++ objects in parameter interfaces makes a DLL basically almost certainly unusable for any other compiler than the one that was used to create the DLL. It can be even as bad as requiring the same version of the compiler since there still exists basically no binary standard about how to pass C++ objects to functions. Maybe that C11 does define something but most modern C compilers have even trouble to fully conform to the C99 standard, which as the name states was released in 1999 (with some addendums released in 2001, 2004 and 2007).

string being a C++ template type has even more complications than just the binary object interface, as each compiler comes with its own crafted template header classes.

[nvo]

@Nathand I'm not getting an error message. I browse for the file and then hit Add Attachment and the window jumps back to the top without actually adding it. I'll try again in a different browser.

@Rolfk, I was afraid of that. I will ask the creator of the dll if he can replace the string objects with char.

[rolfk]

Also ask him to remove the reference parameters. While they SHOULD be equal to a pointer technically, there is no guarantee that a C++ compiler will implement it that way. C++ (and C) are on purpose very vague about specifying implementation details in order to allow a C compiler builder to optimize the generated code as much as possible to the actual hardware implementation. For instance C nowhere specifies that a byte is 8 bits. Theoretically one could design a CPU that uses nine bits (they actually existed) for a "byte" and create a C compiler that uses that for the byte datatype. C among other things only specifies that sizeof(byte) <= sizeof(short) <- sizeof(long) and that int should represent the natural integer type for the target tsystem. But look at all modern 64 bit implementions that define an int still as 32 bit integer to see what natural can mean. bool is not defined at all how big it should be other than it needs to be big enough to represent the two logical states and that it can not have any other meaning than true or false and it requires the representation to be addressable meaning it must be a unit that can be addressed directly in memory which excludes the implementation as bit on most actual CPU architectures.

Basically if he prepends the prototype of all exported functions with extern "C" and doesn't get any compiler and linker errors and warnings anymore, he is reasonably safe that he doesn't depend on any C++ specialismes in the function interface, that often are not even transferable between different C compilers.

[nvo]

Removing the C++ types solved the problem. Thank you everyone for your help!