||Using Design by Contract in C|
|Subject:||Why not GNU nana?|
Response to: Why not GNU nana?
I did take a look at GNU Nana last spring. I am definately guilty of reinventing the wheel to some degree, but here are the reasons I chose to do so:
* By creating a preprocessor I could gather information about the types of function arguments and use that info to make writing the contracts simpler.
* Having your contacts in comments allows you to compile your code normally.
* Also I like having contracts seperated from the function definition.
* I like the readability of OCL.
* Doxygen integration was very important. This would be possible using Nana, but since (IMHO) the DBC for C contracts have good readability, they provide good documentation.
* Postconditions (using @pre) and invariants require a little more work in Nana than in DBC for C.
* Nana requires GCC extensions for some features.
* Some of Nana's features require C++.