Hi Peter,

- we have to comment each pre/post condition manually (and synchronize comments according to changes in the code)

I think that the positive aspect here, when we manually note the pre and postconditions, is that we could express them in a more verbose way and not reveal any implementation details.

Yes, that’s right.

I think that we should only document the pre and post conditions for public functions. The public interface is what we should care to describe well. I think that in general we could document the private functions only briefly.

I agree, I’ll try to make my new comments according to the style we have talked about (http://www.calitko.org/source-talk/692 and http://www.calitko.org/source-talk/694). As for private functions -
I’m used to comment all my functions so I think I’ll keep commenting them according to their importance (can help when one is doing refactoring and there are some aspects that he should know, I mean like notes and warnings).

There are a few benefits of using a bigger variety of assert macros. For example, If we have both REQUIRE and ENSURE representing pre and postcoditions, then we could configure release builds to not check the postcoditions but to still check the precondition. We could also choose whether an exception should be thrown or the application should be abort()-ed upon an assertion fault. Additionally, the source code will bear more semantical information and that is kind of nice.

I’m actually considering switching to assertions throwing exceptions because that would make it possible to see which test caused an assertion to fail. Right now if an assertion is thrown the tester is terminated. Another advantage of using assertions that throw exceptions is that we could check REQUIREs in release builds also. Thus if a precondition is violated, an exception will be thrown instead of allowing the state of an object to be corrupted. If we provide exception handler on a few key positions and our code meets the strong exception safety guarantee, then we could resume operation from a valid state. The operation that caused the exception was effectively ignored.

There is definitely room for experimentation, so I think we should just keep this things in mind and try some of them out.

Indeed. So I’ll now stick to our commenting scheme and I’ll use \pre \post and Q_ASSERT() and if we figure something interesting out, we can change it. Checking REQUIREs in release builds is a very good idea and could be useful for us. Maybe we can make some macros (or use some 3rd party framework) to do that but keep commentig \pre and \post manually?

Have a nice day,

Petr