algorith implementation

[Fraser Ross]

template <class OutputIterator, class Size, class T>
void fill_n (OutputIterator first, Size n, const T& value)
{
while (n-- 0) *first++ = value;
}

If Size must be convertible to an integral type is this not an
implementation that excludes passing an enum value as the second
parameter? An enum value is convertible to an integral type so the
implementation does not match the specification.



Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------

http://www.usenet.com

[Victor Bazarov]

Re: algorith implementation

Fraser Ross wrote:

template <class OutputIterator, class Size, class T>
void fill_n (OutputIterator first, Size n, const T& value)
{
while (n-- 0) *first++ = value;
}
>
If Size must be convertible to an integral type is this not an
implementation that excludes passing an enum value as the second
parameter? An enum value is convertible to an integral type so the
implementation does not match the specification.

Correct. Where did you find this one? A better way would be to make
it

void fill_n (OutputIterator first, Size n_arg, const T& value)
{
size_t n = n_arg; ...

, probably.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Jens Theisen]

Re: algorith implementation

Victor Bazarov wrote:

Correct. Where did you find this one?

I found the same issue in gcc's STL. Indeed sgi's STL documentation
defines the requirement to be that Size must be an integral type.

Jens

[Victor Bazarov]

Re: algorith implementation

Jens Theisen wrote:

Victor Bazarov wrote:

>Correct. Where did you find this one?

>
I found the same issue in gcc's STL. Indeed sgi's STL documentation
defines the requirement to be that Size must be an integral type.

The requirement now exists in the Standard (since 1997), so any C++
standard library implementation that doesn't use a local variable is
not going to work with enums, as the OP hinted.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Fraser Ross]

Re: algorith implementation

I'm using the Rogue Wave STL with BCB6.

Fraser.



Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------

http://www.usenet.com

[Kai-Uwe Bux]

Re: algorith implementation

Jens Theisen wrote:

Victor Bazarov wrote:

>Correct. Where did you find this one?

>
I found the same issue in gcc's STL. Indeed sgi's STL documentation
defines the requirement to be that Size must be an integral type.

But the standard does say otherwise:

[25.2.5]

template<class ForwardIterator , class T>
void fill(ForwardIte rator first, ForwardIterator last, const T& value);

template<class OutputIterator, class Size, class T>
void fill_n(OutputIt erator first, Size n, const T& value);

Requires: Type T is Assignable (23.1), Size is convertible to an integral
type (4.7, 12.3).

Effects: Assigns value through all the iterators in the range [first,
last)or [first, first +n).



Best

Kai-Uwe Bux

[Jens Theisen]

Re: algorith implementation

Victor Bazarov wrote:

The requirement now exists in the Standard (since 1997), so any C++
standard library implementation that doesn't use a local variable is
not going to work with enums, as the OP hinted.

The standard I'm looking at was released 1998. And after all, it's
C++98, isn't it? How come that I still have the "convertibl e" variant?

Jens

[Bo Persson]

Re: algorith implementation


"Victor Bazarov" <v.Abazarov@com Acast.netskrev i meddelandet
news:yqudnUlZYM __-nXZnZ2dnUVZ_vud nZ2d@comcast.co m...

Fraser Ross wrote:

> template <class OutputIterator, class Size, class T>
> void fill_n (OutputIterator first, Size n, const T& value)
> {
> while (n-- 0) *first++ = value;
> }
>>
>If Size must be convertible to an integral type is this not an
>implementati on that excludes passing an enum value as the second
>parameter? An enum value is convertible to an integral type so the
>implementati on does not match the specification.

>
Correct. Where did you find this one? A better way would be to
make
it
>
void fill_n (OutputIterator first, Size n_arg, const T& value)
{
size_t n = n_arg; ...
>
, probably.
>

That would fail for negative values instead.

This is tricky. :-)


Bo Persson

[Clark S. Cox III]

Re: algorith implementation

Bo Persson wrote:

"Victor Bazarov" <v.Abazarov@com Acast.netskrev i meddelandet
news:yqudnUlZYM __-nXZnZ2dnUVZ_vud nZ2d@comcast.co m...

>Fraser Ross wrote:

>> template <class OutputIterator, class Size, class T>
>> void fill_n (OutputIterator first, Size n, const T& value)
>> {
>> while (n-- 0) *first++ = value;
>> }
>>>
>>If Size must be convertible to an integral type is this not an
>>implementatio n that excludes passing an enum value as the second
>>parameter? An enum value is convertible to an integral type so the
>>implementatio n does not match the specification.

>Correct. Where did you find this one? A better way would be to
>make
>it
>>
> void fill_n (OutputIterator first, Size n_arg, const T& value)
> {
> size_t n = n_arg; ...
>>
>, probably.
>>

>
That would fail for negative values instead.

Is that really a problem? Is the behavior of std::fill_n even defined by
the standard when n_arg is negative?

--
Clark S. Cox III
clarkcox3@gmail .com

[Bo Persson]

Re: algorith implementation


"Clark S. Cox III" <clarkcox3@gmai l.comskrev i meddelandet
news:12ehgm6cct mvhff@corp.supe rnews.com...

Bo Persson wrote:

>"Victor Bazarov" <v.Abazarov@com Acast.netskrev i meddelandet
>news:yqudnUlZY M__-nXZnZ2dnUVZ_vud nZ2d@comcast.co m...

>>Fraser Ross wrote:
>>> template <class OutputIterator, class Size, class T>
>>> void fill_n (OutputIterator first, Size n, const T& value)
>>> {
>>> while (n-- 0) *first++ = value;
>>> }
>>>>
>>>If Size must be convertible to an integral type is this not an
>>>implementati on that excludes passing an enum value as the second
>>>parameter? An enum value is convertible to an integral type so
>>>the
>>>implementati on does not match the specification.
>>Correct. Where did you find this one? A better way would be to
>>make
>>it
>>>
>> void fill_n (OutputIterator first, Size n_arg, const T& value)
>> {
>> size_t n = n_arg; ...
>>>
>>, probably.
>>>

>>
>That would fail for negative values instead.

>
Is that really a problem? Is the behavior of std::fill_n even
defined by
the standard when n_arg is negative?

Yes, it is. The committee has specifically rejected undefined
behaviour for that case.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2025.html#426

Bo Persson

[Victor Bazarov]

Re: algorith implementation

Jens Theisen wrote:

Victor Bazarov wrote:

>The requirement now exists in the Standard (since 1997), so any C++
>standard library implementation that doesn't use a local variable is
>not going to work with enums, as the OP hinted.

>
The standard I'm looking at was released 1998. And after all, it's
C++98, isn't it? How come that I still have the "convertibl e" variant?

I must have misunderstood. The Standard says "convertibl e". However,
the implementation that makes direct use of the argument and tries to
decrement it using -- is not going to work with a "convertibl e" type.
It will only work with true integral type.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Fraser Ross]

Re: algorith implementation

A suitable implementation is easy enough to make. It surprises me how
much library code uses pre increment and decrement operators. They can
be less efficient.

Fraser.

void fill_n (OutputIterator first, Size n_arg, const T& value)
{
size_t n = n_arg; ...

, probably.

>
That would fail for negative values instead.
>
This is tricky. :-)
>
>
Bo Persson

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------

http://www.usenet.com

[Fraser Ross]

Re: algorith implementation

I meant to type post not pre.


"Fraser Ross"

It surprises me how
much library code uses pre increment and decrement operators. They

can

be less efficient.

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------

http://www.usenet.com

[Default User]

Re: algorith implementation

Fraser Ross wrote:

A suitable implementation is easy enough to make.

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or the group FAQ list:
<http://www.parashift.c om/c++-faq-lite/how-to-post.html>




Brian

[Bo Persson]

Re: algorith implementation


"Fraser Ross" <fraserATmember s.v21.co.ukskre v i meddelandet
news:1156174651 _15@sp6iad.supe rfeed.net...

>A suitable implementation is easy enough to make. It surprises me
>how
much library code uses pre increment and decrement operators. They
can
be less efficient.
>
Fraser.

I don't think it is obvious how to select a proper integral type for
n, when you don't know what type Size might be. In this case, if n_arg
happens to be negative, converting it to size_t will not work well.

If Size happens to be a class type with a user defined convertion
operator, how do we know what type(s) it will convert to? Signed, or
unsigned?


Bo Persson

>
>

void fill_n (OutputIterator first, Size n_arg, const T& value)
{
size_t n = n_arg; ...
>
, probably.
>

>>
>That would fail for negative values instead.
>>
> This is tricky. :-)
>>
>>
>Bo Persson