http://www.xmlhelpline.com/blog/2010/02/xsd-design-1-schema-included-via-2.html

Seems almost silly now. But definitely need to resolve the relative URLs before doing any comparisons (include or import).

However, Microsoft toolchain is lacking love and totally archaic (sorry windows developers).

gcc employs a much more interesting solution: http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html

Interesting, I didn’t know about this option. I tried to add it to the test case and it turned the duplicate symbol errors into warnings plus issued this one:

warning LNK4088: image being generated due to /FORCE option; image may not run

While I think the image will run fine in this particular case (the two DLLs will simply use their own instantiations of the functions), this may no be the case in other cases (e.g., if a template has static data members; in this case each DLL will end up with its own version).

The other problem with this approach is that it will also mask other, unrelated, duplicate symbol errors. The user can always read through the list of warnings to make sure nothing suspicious is there but that can quickly become too much since this will have to be done after every change to the code.

However, this seems like the only viable work around for the case of two independent DLLs that I described above.

Thanks for the information!
Boris

I am not sure what you are want to achieve with XLW. Do you want to be able to access the command line data from Excel?

The CLI language is specific to the concepts of the command line interface and, to a lesser extent, C++. The upside of this is that it is very clean and simple. The downside is that it is hard to reuse for something else.

There would be several issues with XML Schema, similar to YANG. First, it would be very verbose. Second, there is no language mechanism for capturing option aliases. While we could use default values in attributes to model default option values, they will only work for built-in XML Schema types. Then there is the issue of using custom C++ types for options which won’t be easy with XML Schema.

I am planning to release CLI 1.0.0 on Sunday. You can try it and then see if you can achieve something that simple and elegant with XML Schema ;-).

Very interesting blog. Why not using an xml schema to represent command/argument/option structure and implement a parser that creates a CLI reader?

Thanks, I am glad you are enjoying both (the blog and XSD).

Regarding Fusion’s associative tuples: This is the same approach as the one used in the CLI parser from libcult which is discussed in the next post. In particular, there is the limit on how many tuples you can have in the map (10 by default, which is way too low for a CLI parser). They also use partial template specialization to implement all this apparatus.

As mentioned in the next post, this approach does not scale to a large number of options (say, 100). In this case the compilation time and the object code size (due to the enormous symbol length) become unacceptable. There is also the verbosity problem since we have to repeat each option name at least three times.

The implementation can be improved using the C++0x variadic templates feature. There is nothing that we can do about the verbosity problem, however (see the next two posts for details).

But nice idea, nevertheless. This is probably as good as we can get if we have to define the command line interface in the C++ source code.

Very interesting blog, a pleasure to read! Also, I’ve been using XSD in a project and it’s very nice! Thanks.