Hi,

In the current draft for C++0x std::copy_n() is defined as returning an
iterator to the one-past-last element copied. However, std::fill_n() and
std::generate_n() functions do not return anything. This seems to make
it impossible to solve the following problem satisfactorily:

Given an output iterator which dereferences to an int, write into it n
1's followed by n 2's using std::fill_n() (similarly for std::generate_n
()).

I am proposing that for C++0x std::fill_n() and std::generate_n() return
an iterator similarly to the std::copy_n(). In addition to solving the
aforementioned problem, this will also provide consistency.

Note a similar problem will be with all '_n' versions of the algorithms.

What do you think?

--
http://kaba.hilvi.org

[ 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                      ]

On 28 Feb., 03:40, Kaba <n...@here.com> wrote:
> In the current draft for C++0x std::copy_n() is defined as returning an
> iterator to the one-past-last element copied. However, std::fill_n() and
> std::generate_n() functions do not return anything. This seems to make
> it impossible to solve the following problem satisfactorily:
>
> Given an output iterator which dereferences to an int, write into it n
> 1's followed by n 2's using std::fill_n() (similarly for std::generate_n
> ()).
>
> I am proposing that for C++0x std::fill_n() and std::generate_n() return
> an iterator similarly to the std::copy_n(). In addition to solving the
> aforementioned problem, this will also provide consistency.
>
> Note a similar problem will be with all '_n' versions of the algorithms.

Yes, the problem is real, there exists a library issue for this:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865

IMO a similar problem exists for the param function in the
seed_seq component of the random number library, see

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1313

[Note that the proposed resolution is yet incomplete, because
it awaits the upcoming wording changes of the working draft
to take the removal of concepts into account]

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                      ]

Kaba wrote:
> Hi,
>
> In the current draft for C++0x std::copy_n() is defined as returning an
> iterator to the one-past-last element copied. However, std::fill_n() and
> std::generate_n() functions do not return anything. This seems to make
> it impossible to solve the following problem satisfactorily:
>
> Given an output iterator which dereferences to an int, write into it n
> 1's followed by n 2's using std::fill_n() (similarly for std::generate_n
> ()).
>
> I am proposing that for C++0x std::fill_n() and std::generate_n() return
> an iterator similarly to the std::copy_n(). In addition to solving the
> aforementioned problem, this will also provide consistency.
>
> Note a similar problem will be with all '_n' versions of the algorithms.
>
> What do you think?
>

It's already been done: LWG 865.

--
    Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

[ 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                      ]