amorilia / formast Goto Github PK

See for instance NiDataStream.

I knew I forgot something important!

It would be good to have rpms for:

• native header and shared library
• native python package (system build)
• mingw32/64 header and shared/static library (useful for cross compiling nifskope/niflib in the long term)

Nice to have as well:

• native java package
• native php package
• ...

Original request by @neomonkeus 9ae9936#commitcomment-2101207

Some links to how other documentation systems deal with this:

http://www.stack.nl/~dimitri/doxygen/docblocks.html#cppblock - brief + detailed description
http://www.python.org/dev/peps/pep-0257/#multi-line-docstrings

For example, if c is a Class, in Python:

if c.base_name:
    print(c.get())

will actually print something like _c0f2cc0100000000_p_std__string: the std::string pointer has not been converted back to a Python string.

Implementation note: compounds are probably best tagged as abstract too.

For compilers that support C++11, we could use std::shared_ptr instead of boost::shared_ptr and unsigned long long instead of boost::uint64_t.

boost::optional is used quite a bit, however we could hide everything but a minimal implementation (as in the current swig wrapper), because only a tiny bit of the full interface is needed anyway.

Only niflib requires this at the moment, due to the way it blindly auto-calculates size fields. For the moment, we should read it in to support existing code generation. However, maybe we could think of a better solution in niflib itself in the long term and perhaps drop the "calculated" entirely, since it hasn't anything to do with the actual format.

Integer parsing is used for more than just conditional expressions, so we should factor out the code into a reusable component. For example, at the moment, not all integer expressions in enum definitions will succeed in parsing.

Requested for instance by @harlequinzeg0 amorilia/nifxml#3 (comment)