   Testing whether exported dll functions are C-compatible
  Hi,I am wondering how I can test whether a dll that exports functions can be tested for C-compatibility.I have myself never programmed in C, but I want the exported functions to be callable (linkable) from a C or C++ application.I could test each function individually, but since there a more than 200 of them, that could take some time. Any alternative? (e.g. marking the library.h as C-file?). I am using MVS2005, and the project manager has automatically created the structure for that file. It contains following code which obviously is not C-compatible:class CmyLib : public CWinApp{public:CmyLib);DECLARE_MESSAGE_MAP()};
  Oh Boy...Well, there is a way but I'm pretty sure you won't like it.Assuming that these functions you wish to export are packaged in a class, you could then just export a function that creates an instance of that class (i.e. a so called “factory” function).This requires that you create an interface to the class itself, which is simply an abstract data type (i.e. a class made up of pure virtual methods), whose method signatures are identical to the methods of the class that you wish to export.A pointer reference (or more brutally, a pointer to a pointer) to such an interface will have to be fed to the factory function, whose job it is, is to set this interface pointer to the newly created class it creates.You can then invoke all the methods of the interface, which in turn, will invoke the identical methods of the class created in the dll.Gah! I'm probably losing you already...This is the tried and tested method I'm using anyway and I am unsure as to how it can be done any other way asides from exporting each and every 200+ functions explicitly (or indeed, implicitly).I'm sure others may have a yet more elegant solution... If not, then I'd be more than happy to elaborate further with actual code.   ;  Thank you CodeStorm.Actually I might not have explained myself correctly. My functions are not part of any class, the class is empty (Windows created it automatically).This is what I have:#if !defined(V_REP_INCLUDED_)#define V_REP_INCLUDED_#ifndef __AFXWIN_H__#error include 'stdafx.h' before including this file for PCH#endif#define VREP_DLLEXPORT extern "C" __declspec(dllexport)typedef unsigned char simBool;typedef char simChar;typedef int simInt;typedef float simFloat;typedef void simVoid;typedef long simLong;typedef unsigned char simUChar;typedef unsigned int simUInt;typedef unsigned long simULong;// Then plenty of enums. Here just one:enum {sim_object_shape_type=0,sim_object_joint_type,sim_object_graph_type,sim_object_camera_type,sim_object_dummy_type,sim_object_proximitysensor_type,sim_object_versatile_type,sim_object_inertia_type,sim_object_path_type,sim_object_renderingsensor_type,sim_object_type_end=sim_object_path_type+100};...// Then what WIndows automatically created:class Cv_repApp : public CWinApp{public:Cv_repApp();DECLARE_MESSAGE_MAP()};// And finally all my functions (here just one):VREP_DLLEXPORT simVoid* simLaunchSimulator(const simChar* applicationName,simBool defaultToolbars);Now above code might not be compatible with a pure C-application. My question was: how to check what in above code is not pure C-code? As an example, the "enum" keyword might not be a C-command (or might be used in a way that is specific to C++) (just an example).In the past I often used:"float buffer[5]", I didn't know this was not C, but C++. So I changed all occurences to "float* buffer"   