Programming "by Contract"

The contract

• Create a library, with the following structure:

  • ./include/
  • ./source/
  • ./cmake/
  • ./tests/

• The library should be self-contained, in its own namespace,
  only allowed dependencies are stl libraries (C++98)

• It should perform integration on the unit tensor product element

• It should be 'object oriented', meaning that there should be one
  abstract class, templated on the dimension of the unit box,
  instantiated for dim = 1, 2, 3, defining only the interface of
  the function

  • Quadrature<dim> quad; // Empty constructor
  • Quadrature<dim> quad(points, weights); // full constructor

• And there should be some trivial implementations, like
  TrapezQuadrature, or SimpsonQuadrature, or TensorProductQuadrature

• When compiled, there should be two objects: libquadrature.debug,
  and libquadrature.release, which you can link to your programs
  with -lquadrature.debug or -lquadrature.release (after specifying
  correctly -L and -I options)

• The library should strictly follow this coding conventions:
  https://www.dealii.org/developer/doxygen/deal.II/CodingConventions.html

• The debug version should perform extensive checking in input,
  output, and internal conditions, while the release version should
  not perform any checking (used only for production runs)

• Each component and function of the library should be documented
  first, a unit test should be written in ./tests, and ctest
  should be used to launch all tests, submitting results to cdash

• All unit tests should be written before the actual
  implementation. Example: integrate a linear function between 0 and
  1 and check that the results is exactly what you get from
  TrapezQuadrature<1>

• The cmake directory should contain cmake include files, include
  should contain only the definition of the C++ functions,
  and source should contain only the implementation of the functions

• When the library is installed, only include files and the library
  itself should be copied over

• The directory tests should contain pair of files:

  • unit_test_01.cc
  • unit_test_01.output

• The test is considered passed if the actual output of the program
  matches the one contained in the .output file, using numdiff,
  to avoid numerical roundoff

• Add a .travis.yml file to the repository, and make sure that at
  every pull request, the full testuite is run

• Design decisions are taken together, at the early stage of the
  project, when only documentation and test unit is available

• Documentation should be extracted automatically from code using
  Doxygen (or equivalent tool)