Rules for DLL Function Signatures

[humble_learner]

Hi,

Are there any specific rules as regards parameters that make up a DLL function signature which is exposed to the outside world ?

In addition, Is it an accepted practice to have DLL function signatures which
1.Take class objects as parameters (object parameters, pointer to object or reference to object)
2. Return class objects as parameters (object parameter, pointer to object parameter, or reference object)

I suppose it is acceptable to return an object pointer from a DLL, because that is one of the ways in which plug-ins are implemented (where the return type is an Interface pointer)

Please do let me know.

The DLL is expected to be consumed by C or C++ clients.

[Alex F]

1. Yes.
2. Yes.
3. For any object allocated in Dll, supply Release function which should delete it. Client should not try to release objects allocated in another Dll.

[Paul McKenzie]

1. Yes.
2. Yes.
3. For any object allocated in Dll, supply Release function which should delete it. Client should not try to release objects allocated in another Dll.

Yes, this is the correct guideline. There are some exceptions to rule 3), and that is if The DLL uses the Windows API to allocate the memory (i.e. GlobalAlloc and those funtions).

For example, various third-party DLL's that deal with imaging will allocate the memory using GlobalAlloc, HeapAlloc, etc. and it's the responsibiltiy of the app to release the image memory. Of course, this needs to be documented to the user of the DLL.

Regards,

Paul McKenzie

[Ajay Vijay]

1.Take class objects as parameters (object parameters, pointer to object or reference to object)
2. Return class objects as parameters (object parameter, pointer to object parameter, or reference object)

I would say no to both. What if the class definition changes and function is still assuming the old version' class has been passed, or vice versa. The same goes for returning a class object - doesn't matter if you return the object or the pointer to object.

Would you ever try to return std::vector from a DLL function? Or would you expect a function taking map<string,list<int>::iterator> & ? These classes would definitely change! The client might be using other version of STL, and your DLL might be working in other version of STL. STL doesn't have DLL, no runtime library, thus size/definition would definitely differ!

The only case, where I can expect taking/returning the class, when the same DLL is exporting the classes. Even in that case, I may check at runtime - using ASSERT to check it in debug, and performing sizeof checks in release. Though, for performance reasons, I may omit runtime check at release version.

[Alex F]

IWould you ever try to return std::vector from a DLL function? Or would you expect a function taking map<string,list<int>::iterator> & ?

Yes, STL objects should never be passed between Dll and its client. This is well-known problem. Interesting, what is general rule for all templates, not only STL.

[Ajay Vijay]

Yes, STL objects should never be passed between Dll and its client. This is well-known problem. Interesting, what is general rule for all templates, not only STL.

I would not take the trouble of passing CDataExchange or CWordArray either.

[Igor Vartanov]

I suppose it is acceptable to return an object pointer from a DLL, because that is one of the ways in which plug-ins are implemented (where the return type is an Interface pointer)

1. Pointer to object is not the same thing as interface pointer
2. Interface pointer is a standard way for dealing with/interchanging objects in plugin technology
3. Interface declaration must follow __stdcall convention to guarantee real cross-compiler compatibility

[Ajay Vijay]

Interface declaration must follow __stdcall convention to guarantee real cross-compiler compatibility

Did you mean the object-oriented interface term, or the interface you are giving via your exported functions? Former is not possible since calling conventions apply to functions only. Latter doesn't fit the discussion.

[Igor Vartanov]

Former is not possible since calling conventions apply to functions only.

Actually, this is what I meant (not sure what you did):

typedef struct {
    virtual int __stdcall foo0() = 0;
    virtual int __stdcall foo1(int a) = 0;
    virtual int __stdcall foo2(int a, int b) = 0;
} MyFooInterface, *PMyFooInterface;

[Ajay Vijay]

The discussion is about arguments and return types from a function.

And typedefining a structure with virtual function??

[Arjay]

The only time I would expose classes from a dll is if I only used the dll within exe projects I controlled. That way, I could always rebuild both the exe and the dll.

[Igor Vartanov]

The discussion is about arguments and return types from a function.

Yep, exactly. Arguments and return types, as well as objects and interfaces, dlls and plug-ins.

And typedefining a structure with virtual function??

Man, it looks like you never delved into COM and plug-in technologies. Lucky guy.

[Ajay Vijay]

Yep, exactly. Arguments and return types, as well as objects and interfaces, dlls and plug-ins.

The OP asked if it is okay to pass or return the class objects. Interfaces are different thing. Yes you can pass interfaces, with less issues than classes. The definition of interface, and importance of it are off beat, as per this thread.

Man, it looks like you never delved into COM and plug-in technologies. Lucky guy.

Hmm. You did not get me. A typedef struct {...}theStruct; definition reminds me of C, and code compatibility with C. Now, when you include a pure virtual function in it, it become obscure.

COM Interaface? Well, that also uses IDL/ODL files, which are composed of classes/coclasses and not C-style struct typedefs.

Interface declaration must follow __stdcall convention to guarantee real cross-compiler compatibility

This seriously has nothing to do with DLL exported function signatures, taking class objects.

[Ajay Vijay]

@Igor,
I guess you are more concerned about this following statement.

I suppose it is acceptable to return an object pointer from a DLL, because that is one of the ways in which plug-ins are implemented (where the return type is an Interface pointer)

But, in my way of interpreting it, he is just giving an example on how Plug-ins are implemented. With that knowledge, he is quite sure that object/class-pointer may be returned from an exported DLL function. But again, I believe, he is not concerned about interfaces as such, and __stdcall convention in interfaces.

[Igor Vartanov]

Ajay, I really appreciate your input. But would you just slow down with guessing? and let the thread originator utter a couple of words about his real point of interest? Thank you.