Hello,

my posting is inspired by the results of the recent thread
"fill_n an array of enums".

I observe that the requirements clause of std::fill_n (25.2.5/p. 1),
namely

"[..] Size is convertible to an integral type (4.7, 12.3)."

leads to an unnecessary restriction of its application area.

It makes an canonical usage like that of an arbitrary output
stream Os impossible, which may provide its own spezialization
of std::iterator_traits<Os>::difference_type that not necessarily
is either convertible to an integral type or which's conversion would
lead to loss of range.
E.g. an imaginable definition of my very **huge** stream could use
something like the proposed big integer class

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1744.pdf

I'm wondering why not a similar approach was taken as in case of
std::uninitialized_fill_n (20.4.4.3/p. 1) where **no** explicit
requirement is provided for the type Size, but instead the effects
clause fully specifies the requirements. Thus a single effects clause
could be provided as:

for (; n--; ++first)
   *first =3D x;

which would also nicely work with user-defined "integral" types. As far
as I see this proposed change would not prevent implementors to provide
the same kind of optimizations (e.g. std::memset for character=20
sequences) as already available for std::fill_n.

What do you think?

Greetings from Bremen,

Daniel Kr=FCgler

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]