Design by Contract in C++?

An anonymous reader asks: "I have read some of the stuff on Eiffel, watched their tutorial videos about design by contract, and the entire thing sounds like a pretty good idea. However, the problem is that we don't use Eiffel at work, and I highly doubt I could get people to come around to the idea of switching to it. Although we use a lot of C++, I can imagine that a lot of the ideas from Eiffel can be applied there. I have looked around on the net and found a few articles talking about different ways of applying design by contract using assert statements and the like. I also found the dlib C++ library on SourceForge which, among other things, puts a design by contract face on a lot of API calls. So, there are obviously people doing it. What is everyone's experience with Design by Contract in C++? What tools are there that help make it a workable system? Lastly, are there any pitfalls to taking this approach in C++?"

Comments

Verbal Contracts

[dch24]

In the development environment I work in, we use entirely C++, and combine embedded Linux, desktop Linux, and several server OSes. There are six engineers working on my part of the project (the embedded part), and a similar number working on the other parts.

Although we have enough freedom to switch over to a Design By Contract if we all agree to do it, we currently use documentation as a semi-formal contract, starting with design meetings where we verbally define the contract, which we write up piecemeal as we implement sections of code. Obviously, when multiple companies are collaborating on a business system, Design By Contract may be necessary to nail down the project requirements for each participating company. But in-house, what are the advantages of a formalized system over verbal, face-to-face communication? Wouldn't the meetings be held and the documentation be written anyway? As the project evolves, design changes can be implemented in an organized way, but again, the formal definitions would be redundant with the design change meetings.

Re:Verbal Contracts

[NovaX]

What you're thinking of is more on the lines of a UML as blueprint vs. UML as sketch. DBC is purely code-level and is simply a good practice. Good programmers will at least check all preconditions (e.g. if (param == null) {throw new IllegalArgumentException("Param=NULL")}). That's step one of the DBC philosophy. Having the whole process built into the language simply makes it cleaner reduces LOC.

Design by Contract basically means that someone takes the responcibility to make sure inputs and outputs are valid. A verbal contract is loose - everyone assumes that everyone else did the right thing and the data is valid. When someone makes a coding mistake, such as passing in a null object, it may propogate pretty far and cause an error to appear. You'll then spend a lot of cycles trying to fix the problem and work your way back to the real offender. So DBC simply forces an error to happen right away and saves time.

So think of DBC as your friend. It never gets in the way of refactoring, yet kindly points out problems before your customers do. :)

Re:C++0x

[NiceRoundNumber]

One of the proposed additions for C++0x includes Contract Programming functionality built into the core language/library

In addition to assertions, there are a number of helpful ideas that can greatly improve the readability of the language and follow the intent of the programmer, as well as improve the generated code. For instance, a "pure" keyword that specifies that a function is deterministic and has no side-effects; e.g.,square root, or returning an inverted matrix. (So if the function is called twice on the same input, the compiler knows it only has to call the function once.)

Similarly, a good system for handling pointer aliasing; specifying to the compiler which pointers may be aliased to which other ones, or which pointers are not aliased. These often lead to spaghetti code when hand-optimized, but if the concepts were embedded in the language, both the source code and output could become much cleaner.

Nobody said the obvious!

[Anonymous Coward]

Here's this guy working for a company that exists, apparently has cashflow, and at least has some products that are actually working and that customers are buying. So he watches this video that talks about some cool shit, and wants the other programmers at his work to switch over to this cool shit, that may be cool and may also be shit for what they're doing.

It's not just a matter of adding yet more lipstick to that pig, and it's not just a matter of using another language instead. There's an entire infrastructure of concerns that need to be coherently operative as a system. Does it need to run fast? Bye bye Ruby. Does it need to have lots of graphics? Bye bye huge numbers of academically cool and yet real world shit languages.

Forget stuff like design by contract until you've actually established that the language actually has the normal everyday boring functionality that has you yawning in boredom, but which your arse is getting fired if you don't do. Forget aspect orientated programming and all the cool shit (damn, it's cool! AND SHIT!) until you've worked out the changeover costs, the additional overhead of supporting more than one language in-house until the old uncool (but working) stuff is completely phased out.

Work out the business costs, and even more so, work out the business reasons as to why people should spend time and effort changing over vast swathes of your internal IT operations to some trendy new concept that isn't even proven past "that sounds like cool shit". Languages work and don't work for incidental reasons, rarely for specifically designed reasons. If it were purely merit, then Scheme would be what C is now.

Stop flailing around looking for some magic arse concept that will silver bullet everything - it's all shit. Nothing cool has been invented since John von Neumann threw together some cool shit and died before he got around to version two. What you see in front of you is a big pile of quickie crap thrown together in wartime without a hell of a lot of thought put into it. So it's all going to suck regardless of whatever crappy abstraction gets put over the top.

And like putting lipstick on that pig, there's a lot of money to be made making the lipstick and selling it to stupid little piggies.

Re:I don't understand the question...

[EsbenMoseHansen]

Strange. After trying dozens of languages, I still return to C++, and I still think it is my favorite strongly typed language (yeah, I know, nobody can agree on strongly typed, but you know what I mean).

For loosely typed, I'm more torn. Ruby is nice, so is Perl. Python seems a bit limited to me, and the indention thing is just braindead, but maybe that is just a matter of adjustment. I haven't tried Scheme or that functional language that is so popular these days, but I will get around to it.

I do have 3 gripes with C++: No closures, no closures and no closures. Oh yeah, a way to statically initialize arbitrary objects would be nice. I have seen few other valid complaints with it, but lots of silly ones.

For the worst language I have tried yet, I nominate PL/I. For the worst that anybody still uses for new projects, Java, especially it's "let's throw all our type info away" implementation of templates, sorry, generics. And no closures there either. Horrible language.

For best assembler, I nominate C.

As for the question, doing real design by contract would require a pre-processor or manual insertion of suitable code in the beginning and end for every function. Neither is exactly pretty, but I believe lots of other languages do it this way. Personally, I think that excessive preconditions is a sign of poor OO design, but testing invariants do make sense for certain cases. Postconditions are better handled with an ordinary testframework.

And remember that lots of ideas looks awsome on paper, and turns out to be more bother than they are worth in real life.

Re:Must Buy New Book For Latest Proggramming Fad!

[Molt]

For that one example, pretty much. Now try and write me a C++ class function for an employee which is allowed to change the employees details, but not those of their direct manager.. whilst other functions on the employee should be able to. Show me how I can guarantee that an attribute is never decreased in any method, whilst allowing increases quite happily.