Le 01/09/12 20:15, Lorenzo Caminiti a écrit :
On Sep 1, 2012 9:56 AM, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
Le 27/08/12 23:15, Vicente J. Botet Escriba a écrit :
= doxygen =
BTW, have you tried to generate contract documentation using doxygen? Doxygen's preprocessor is too simple and it cannot correctly expand the macros. To generate Doxygen docs of code that contains the contract macros, you'd have to expand it before running Doxygen using you compiler -E or something like Wave so to feed Doxygen the code with the macros already expanded. You'd have to expand with all contracts disabled so Doxygen will see your normal code and generates docs for it. NO This was not what I was expecting for doxygen ;-)
A different question (I'm not sure which one you intended to ask) is if my lib macros can automatically generate Doxygen's @pre, @post, and @inv tags (they are named something like that).
Yes, something like this is what I was requesting. I don't care about whether the macros generate doxygen tags as @pre,@post and @inv. What I want is an automatic generation for quickbook documents using doxygen.
An older rev used to do that--see release 0.3.469 in the Release Notes section (idea taken from [Tadin04], see Bibliography section and Features at bottom of Contract Programming Overview section). However, the Doxygen docs simply repeated the assertion code in the docs so it was more or less like looking at the contract code from the declarations (without the function definition code). Such automatically generated docs where of little value then the macros got too complex for the Doxygen pp anyway so this feature was abandoned.
Are you saying that the user can look at the code as it describes clearly the pre/post/inv and the documentation is not needed anymore? Does you mean that people using your Contract library, and wanting an hypertext documentation, will need to rewrite the pre/post/inv documentation by hand if they want the information is on their hypertext docs?
= enable-if =
Have you an example of the use of enable_if and contracts in the documentation?
This should work as usual but I just realized I don't have an example for it. I'll test it and add an enable_if example.
I was wondering if the library should not use enable_if to emulate C++ proposed Concepts, as e.g. it seems Boost.Generic does. More I think on how you are emulating C++ concepts, more I think that the emulation doesn't corresponds to what a C++Concept user could expect. The use of Boost.ConceptCheck doesn't seems to match the C++11 proposed Concept semantics. I'm not saying that Boost.ConceptCheck is not useful, but the semantic is different. Best, Vicente