Passing Variable Argument to DLL

[kubu]

I am working on a plugin architecture where each plugin requires a different set of input arguments. These inputs need to be provided through a GUI by the user of the program. I figured the easiest way might be to represent the inputs through XML. So the DLL provides a function that returns an xsd string. Based on this string a GUI is dynamically created for the user to enter the data. Then the entered data is passed to the dll through an XML file which can also be verified by the XSD file. Does that sound like a reasonable approach or are there better ways to do this?

[helios]

That sounds too complex to me for an internal communication channel. XML might make sense if you were talking to a separate process, but in this case where both ends are in the same address space, why not simply move around data structures?

[kubu]

Thanks for the input. Data structures would be preferred. However, it was my understanding that data structures are problematic with dlls as both compilers (for the dll and the consumer of the dll) have to use the same data alignment. Even more important, each plugin has a different set of parameters, hence each plugin has a different data structure. The consumer of the dll will have to have access to these custom data structures and visualize them as input field to the user. In C# that would be easy using reflection. However, I am not aware of a mechanism to do this in C (it needs to be cross-platform compatible, hence using C/C++). If there is such a mechanism or there is another way to do this then I am certainly open to that.

[helios]

Data structures would be preferred. However, it was my understanding that data structures are problematic with dlls as both compilers (for the dll and the consumer of the dll) have to use the same data alignment.

AFAIK, as long as both compilers are using the same header, they should generate identical memory layouts, otherwise it would be impossible to make calls to system APIs.

Even more important, each plugin has a different set of parameters, hence each plugin has a different data structure. The consumer of the dll will have to have access to these custom data structures and visualize them as input field to the user. In C# that would be easy using reflection. However, I am not aware of a mechanism to do this in C

This just describes a KeyValuePair[], where

struct Variant{
    int type;
};

struct KeyValuePair{
    const char *key;
    Variant *value;
};

struct VariantInt{
    int type;
    int value;
};

//etc. 

Basically this is roughly equivalent to an XML DOM plus strong types (XML has a single type: text). Of course if you use XML you save yourself the effort of implementing this, but you're adding the work of generating an XML and then immediately parsing it just to pass around data that resides within the same address space anyway.

[JLBorges]

> Does that sound like a reasonable approach or are there better ways to do this?

Yes, it does sound very reasonable. As far as possible, avoid structures/binary data for communicating with plug-ins.

ESR on the importance of being textual:

Interoperability, transparency, extensibility, and storage or transaction economy: these are the important themes in designing file formats and application protocols. Interoperability and transparency demand that we focus such designs on clean data representations, rather than putting convenience of implementation or highest possible performance first. Extensibility also favors textual protocols, since binary ones are often harder to extend or subset cleanly. Transaction economy sometimes pushes in the opposite direction — but we shall see that putting that criterion first is a form of premature optimization that it is often wise to resist. ...
...
When you feel the urge to design a complex binary file format, or a complex binary application protocol, it is generally wise to lie down until the feeling passes. ...
...
Designing a textual protocol tends to future-proof your system. ...

http://www.faqs.org/docs/artu/textualitychapter.html

If the richness of XML is not essential (it probably isn't in this case), JSON could be a simpler option. https://en.wikipedia.org/wiki/JSON

[helios]

To me, it sounds like he's talking about either inter-process communication (including networking) or configuration formats, not that he's referring to the specific case where both endpoints are in the same address space.

If you want a compromise between the two, there's also stuff like Google's Protobuf, or Cap'n Proto, designed by the same guy.