Topic: Why does std::uninitialized_fill_n return void?
Author: Jared <jaredhoberock@gmail.com>
Date: Mon, 12 Jul 2010 23:58:05 CST Raw View
N3092 says many (if not all) of the XXX_n algorithms return an
iterator pointing to the end of the range:
template<class InputIterator, class Size, class OutputIterator>
OutputIterator copy_n(InputIterator first, Size n, OutputIterator
result);
template<class OutputIterator, class Size, class T>
OutputIterator fill_n(OutputIterator first, Size n, const T& value);
template<class OutputIterator, class Size, class Generator>
OutputIterator generate_n(OutputIterator first, Size n, Generator
gen);
template <class InputIterator, class Size, class ForwardIterator>
ForwardIterator uninitialized_copy_n(InputIterator first, Size n,
ForwardIterator result);
Except for uninitialized_fill_n:
template <class ForwardIterator, class Size, class T>
void uninitialized_fill_n(ForwardIterator first, Size n, const T& x);
I would have expected semantics somewhat similar to
uninitialized_copy_n. Is this an oversight, or is
uninitialized_fill_n special somehow?
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@googlemail.com>
Date: Wed, 14 Jul 2010 03:23:00 CST Raw View
On Jul 13, 7:58 am, Jared <jaredhober...@gmail.com> wrote:
> N3092 says many (if not all) of the XXX_n algorithms return an
> iterator pointing to the end of the range:
>
> template<class InputIterator, class Size, class OutputIterator>
> OutputIterator copy_n(InputIterator first, Size n, OutputIterator
> result);
>
> template<class OutputIterator, class Size, class T>
> OutputIterator fill_n(OutputIterator first, Size n, const T& value);
>
> template<class OutputIterator, class Size, class Generator>
> OutputIterator generate_n(OutputIterator first, Size n, Generator
> gen);
>
> template <class InputIterator, class Size, class ForwardIterator>
> ForwardIterator uninitialized_copy_n(InputIterator first, Size n,
> ForwardIterator result);
>
> Except for uninitialized_fill_n:
>
> template <class ForwardIterator, class Size, class T>
> void uninitialized_fill_n(ForwardIterator first, Size n, const T& x);
>
> I would have expected semantics somewhat similar to
> uninitialized_copy_n. Is this an oversight, or is
> uninitialized_fill_n special somehow?
I agree that uninitialized_fill_n throws away useful information
as currently specified. But it doesn't do it in the same way
as fill_n and generate_n did in C++03. The latter two function
templates do accept pure output iterators, while
uninitialized_fill_n does at least require a ForwardIterator.
For fill_n/generate_n this meant that in the presence of a pure
output iterator there is no chance to proceed inserting more
values into it, because they guarantee only single-pass
iterations (see library defect 865). For uninitialized_fill_n it
is still possible to go to the end of the iterator via
advance(first, n) without violating type constraints.
I agree that this is both inconsistent now with fill_n and
uninitialized_copy_n and it means that for a pure
forward iterator an additional linear traversal is required
to get to the end point. Therefore I suggest that you
send a library issue description to the library chair
as specified on top of
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html
Just have a look at the recommendations given in the
section "How to submit an issue".
HTH & Greetings from Bremen,
Daniel Kr gler
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Jared <jaredhoberock@gmail.com>
Date: Thu, 15 Jul 2010 14:08:37 CST Raw View
On Jul 14, 2:23 am, Daniel Kr gler <daniel.krueg...@googlemail.com>
wrote:
> On Jul 13, 7:58 am, Jared <jaredhober...@gmail.com> wrote:
>
>
>
>
>
> > N3092 says many (if not all) of the XXX_n algorithms return an
> > iterator pointing to the end of the range:
>
> > template<class InputIterator, class Size, class OutputIterator>
> > OutputIterator copy_n(InputIterator first, Size n, OutputIterator
> > result);
>
> > template<class OutputIterator, class Size, class T>
> > OutputIterator fill_n(OutputIterator first, Size n, const T& value);
>
> > template<class OutputIterator, class Size, class Generator>
> > OutputIterator generate_n(OutputIterator first, Size n, Generator
> > gen);
>
> > template <class InputIterator, class Size, class ForwardIterator>
> > ForwardIterator uninitialized_copy_n(InputIterator first, Size n,
> > ForwardIterator result);
>
> > Except for uninitialized_fill_n:
>
> > template <class ForwardIterator, class Size, class T>
> > void uninitialized_fill_n(ForwardIterator first, Size n, const T& x);
>
> > I would have expected semantics somewhat similar to
> > uninitialized_copy_n. Is this an oversight, or is
> > uninitialized_fill_n special somehow?
>
> I agree that uninitialized_fill_n throws away useful information
> as currently specified. But it doesn't do it in the same way
> as fill_n and generate_n did in C++03. The latter two function
> templates do accept pure output iterators, while
> uninitialized_fill_n does at least require a ForwardIterator.
> For fill_n/generate_n this meant that in the presence of a pure
> output iterator there is no chance to proceed inserting more
> values into it, because they guarantee only single-pass
> iterations (see library defect 865). For uninitialized_fill_n it
> is still possible to go to the end of the iterator via
> advance(first, n) without violating type constraints.
>
> I agree that this is both inconsistent now with fill_n and
> uninitialized_copy_n and it means that for a pure
> forward iterator an additional linear traversal is required
> to get to the end point. Therefore I suggest that you
> send a library issue description to the library chair
> as specified on top of
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html
>
> Just have a look at the recommendations given in the
> section "How to submit an issue".
>
> HTH & Greetings from Bremen,
>
> Daniel Kr gler
>
> --
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ your news-reader. If that fails, use mailto:std-...@netlab.cs.rpi.edu]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html ]
Thanks for the explanation -- it makes sense. I've submitted an issue
as you suggested.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]