We've expanded our news coverage and improved our search! Visit news.oreilly.com for the latest or search for all things across O'Reilly!
advertisement

Article:
  Using Design by Contract in C
Subject:   Why not GNU nana?
Date:   2004-11-02 07:13:19
From:   cmills
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++.


That said Nana is a great library and many people may find it a more apropriate solution than DBC for C. Nana is probably more space efficient and faster than DBC for C (although I haven't tested this). DBC for C could use Nana to get some of that speed. At the very least if you are using DBC for C and are worried about code size you can define your dbc_error() macro to asm("hlt") (like Nana does) or abort() and ignore the error message.


For those interested in DBC for C I am releasing a new version today. I got a lot of great feed back from people over the weekend and some bug reports too. :) Many thanks to Marc Verwerft for his bug reports.


Information about and the lastest version of DBC for C can be found here:
http://dbc.rubyforge.org


-Charlie