[Boost-users] [boost-users][parameter] ArgumentPack Documentation Best Practices

Subject: [Boost-users] [boost-users][parameter] ArgumentPack Documentation Best Practices
From: Christoph Heindl (christoph.heindl_at_[hidden])
Date: 2011-04-11 07:12:17

Hi,

I wonder if anyone could share his best practices as far as
documenting Boost.Parameter enabled constructors is concerned.
I'm currently doing something along the lines of

/** Construct from named parameters and use defaults where parameters are empty
*
*
* \tparam Opts ArgumentPack of options. The following options are supported
*  - \a min_group_size minimum number of supporting correspondences to
form a group.
*  - \a ntrials number of times to form basis from two randomly
selected correspondences.
*  - \a bin_size_pos quantization size for transformed point coordinates.
*  - \a bin_size_orientation quantization in radians for surface
orientation angles.
*
*/
template<class Opts>
group_geo_hash(const Opts &opts)
{
        this->init(
          opts[Keywords::_min_group_size | 10],
          opts[Keywords::_bin_size_pos | LibFundament::rasFloat(10)],
          opts[Keywords::_orientation_rad | LibFundament::rasFloat(0.2)],
          opts[Keywords::_ntrials | 0]);
        }
}

which is sub-optimal, because default values for options and
option types are missing. Doxygen can deduce types for regular parameters as
well as default values. Ideally this should work for boost.parameters as well :)
Even better, Doxygen could warn about undocumented parameters.

Any thoughts?

Best regards,
Christoph