Shaver did a pretty good summary where we are going with dehydra.
--- Begin Message ---
FYI! Hope I didn't lie too much!
Mike
(I still need to make that "highly evolved predator" post)
---------- Forwarded message ----------
From: Mike Shaver <[EMAIL PROTECTED]>
Date: Fri, Mar 7, 2008 at 8:26 AM
Subject: Re: [Sweng-Gamedev] documentation formats
To: [EMAIL PROTECTED]
On Thu, Mar 6, 2008 at 10:15 PM, Jon Watte <[EMAIL PROTECTED]> wrote:
> Reference documentation (which is what doxygen helps the most with)
> needs to answer the obvious questions:
> 1) Why does this parameter exist?
> 2) What are the legal values?
> 3) Are there any caveats or requirements?
> and it should ideally also answer
> 4) For more information or relations to other places, where do I look?
And I think that in more expressive or powerful languages, or perhaps
more powerful analysis tools, many of those things could be extracted
from the code itself: dependent types, contracts, cross-references
with common calling pattern grouping, etc.
I bet you could get pretty far just analyzing assertions that are in a
function before any other code is called, in terms of establishing
invariants and type-invisible conditions.
Whether for code analysis or documentation (I don't think they're much
different tasks; reference documentation caches the most frequently
needed analyses, really), people might find Mozilla's work on static
analysis tools interesting. GCC + JavaScript AST manipulation API =
big wins for us.
We're using these tools to find bad patterns (temporaries reused
without sequence point? check; error codes not propagated? check.
pointer usage that will interfere with a switch to garbage
collection?) and rewrite code to instrument it or migrate APIs (where
are all the callers of this deprecated method on this interface?), or
look for optimization opportunities (refcounting excesses) . These
tools are designed to work on an, um, industrial-scale codebase that
builds on many platforms and has many of its own syntactic and
semantic quirks. Our template usage isn't as heavy as some codebases
might be, but the ones we do use are important, often complex, and
need to be portable across platforms and compilers. We intend to
support Objective-C and Objective-C++ as well as the current C++ and C
capabilities, but since we're hooking into the middle bits of GCC any
GCC-supported language should work relatively well.
We very much want to see these tools used to replace our current
heuristic source-indexing tools (http://mxr.mozilla.org) with
something that can "know more" about the code. Right now in our
mercurial repository, where we're building Mozilla 2, static analysis
in the build will let you say "this class should only be allocated on
the stack" or "this class is final and can't be inherited from". We
won't need to feel language envy nearly as often, as we use
static-checking.js to give us static coverage, and our code can be
more self-documenting.
(The on-the-stack case is easy enough to find at runtime, but at least
in our app we have paths that only run on some platforms, and it won't
surprise you to discover that our test coverage isn't 100%. Static
analysis is a much better fit for us here.)
Using dehydra to generate language bindings for pure-C++ interfaces
should be quite possible as well; like SWIG, if SWIG did what you
wanted, or like boost::python if you weren't restricted to python and
didn't need the boilerplate.
Taras Glek's blog is as good a place as any to start:
http://blog.mozilla.com/tglek/
Mike
--- End Message ---
_______________________________________________
Dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
