On Sun, Aug 26, 2012 at 4:52 AM, Marc Glisse <marc.gli...@inria.fr> wrote:
> The std::generate(_n) function seems closer than std::fill. Not sure if
> overloading that function (std::generate_n) would make sense, it avoids
> changing the interface.
I'm not wedded to fill. generate_n is fine as well.
> If the goal is to avoid listing several overloads in the class, it is still
> possible to dispatch in the (out-of-class) definition of fill. Or is the
> goal to make it extensible, in the sense that a user can still add
> "specializations" (whatever the technical means used, which don't have to be
> what C++ calls specialization)?
As a first step, for instance, I want to add a function which
optimizes the normal_distribution to use SSE and x86 machines. This
is only useful if I know the type underlying the iterator. It will
have to match the generated value of the distribution. I.e., I want
to define
template<>
template<typename _UniformRandomNumberGenerator>
void
normal_distribution<double>::
fill(double* __f, double* __t,
_UniformRandomNumberGenerator& __urng, const param_type& __param)
{
...
}
As said before, this isn't possible because it's a partially
specialized function.
Defining this as a non-member function isn't practical because each
such function would have to be declared a friend.
What I could imagine working is that the iterator fill/generate_n
functions are defined and in addition the special versions which use
pointers of the result_type of the distribution. There is only one
such type as specified by the template parameter of the distribution
class. This makes it possible to specialize it and at the same time
it is trivial to specify a default. In a standardization effort it'd
be possible to exclusively concentrate on the iterator version.
Implementations could provide the pointer versions as transparent
venues for possible optimizations.
