14882-2003, [lib.uninitialized.copy] is currently written as follows:

"template <class InputIterator, class ForwardIterator>
ForwardIterator uninitialized_copy(InputIterator first, InputIterator
last,
  ForwardIterator result);

1 Effects:
  for (; first != last; ++result, ++first)
    new (static_cast<void*>(&*result))
      typename iterator_traits<ForwardIterator>::value_type(*first);

2 Returns: result"

similarily for N2369, and its corresponding section
[uninitialized.copy].

It's not clear to me what the return clause is supposed to mean, I see
two
possible interpretations:

(a) The notion of "result" is supposed to mean the value given by the
function
parameter result [Note to the issue editor: Please use italics for
'result'].
This seems somewhat implied by recognizing that both the function
parameter
and the name used in the clause do have the same italic font.

(b) The notion of "result" is supposed to mean the value of result
after the
preceding effects clause. This is in fact what all implementations I
checked
do (and which is probably it's intend, because it matches the
specification of
std::copy).

The problem is: I see nothing in the standard which grants that this
interpretation
is correct, specifically [lib.structure.specifications] or
[structure.specifications]
resp. do not clarify which "look-up" rules apply for names found in
the elements
of the detailed specifications - Do they relate to the corresponding
synopsis or
to the effects clause (or possibly other elements)? Fortunately most
detailed
descriptions are unambigious in this regard, e.g. this problem does
not apply
for std::copy.

Proposed resolution:

Change the wording of the return clause to say:

Returns: The value of result after effects have taken place.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Oct 15, 5:39 pm, Daniel Kr   gler <daniel.krueg...@googlemail.com>
wrote:
> 14882-2003, [lib.uninitialized.copy] is currently written as follows:
>
> "template <class InputIterator, class ForwardIterator>
> ForwardIterator uninitialized_copy(InputIterator first, InputIterator
> last,
>   ForwardIterator result);
>
> 1 Effects:
>   for (; first != last; ++result, ++first)
>     new (static_cast<void*>(&*result))
>       typename iterator_traits<ForwardIterator>::value_type(*first);
>
> 2 Returns: result"
>
> It's not clear to me what the return clause is supposed to mean, I see
> two possible interpretations:

The "returns" clause describes the output of the function. And
uninitialized_copy() is a typical function: it accepts
"input" (through parameters), applies some kind of transformation upon
its input (possibly with side effects) and produces "output" (the
value returned by, or effects caused by, the function's operation).
Clearly, every function must have applied its transformation before it
can produce its result and before it can return a value. So the only
possible interpretation applies in this case as it applies to any
other function: that the output of uniitialized_copy() must be the
transformed value of its result parameter. (although the transformed
value might happen to be the same as the input value - see below).

> (a) The notion of "result" is supposed to mean the value given by the
> function
> parameter result [Note to the issue editor: Please use italics for
> 'result'].
> This seems somewhat implied by recognizing that both the function
> parameter
> and the name used in the clause do have the same italic font.

They also have the same name, "result". So the description of
uninitialized_copy() is stating that the output of the function is the
transformed value of its third input parameter.

> (b) The notion of "result" is supposed to mean the value of result
> after the
> preceding effects clause. This is in fact what all implementations I
> checked
> do (and which is probably it's intend, because it matches the
> specification of
> std::copy).

"Result" is more than a notion in this description, it is the name of
uninitialized_copy()'s third parameter - the same parameter whose
transformed value is returned as unitialized_copy()'s output.

> The problem is: I see nothing in the standard which grants that this
> interpretation
> is correct, specifically [lib.structure.specifications] or
> [structure.specifications]
> resp. do not clarify which "look-up" rules apply for names found in
> the elements
> of the detailed specifications - Do they relate to the corresponding
> synopsis or
> to the effects clause (or possibly other elements)?

There is no ambiguity in unitialized_copy()'s description because
"input" is always what a function accepts (and never what it returns)
while "output" is always what a function returns (and never what it
accepted). Colloquially, we might say that a certain function returns
an input value - but formally, that description is inaccurate. In
reality, the function has mapped its input value to the same value on
output (an "identity" transformation). In other words, a function
always applies a transformation upon any input value that it outputs,
so the question then becomes, what effect does the transformation have
on the input value.

In the case of uninitialized_copy(), there is little likelihood that
result's input value will be mapped to the same value on output - in
fact, for that to happen, the first two parameters to
uninitialized_copy() would have to delimit an empty range.

>
> Proposed resolution:
>
> Change the wording of the return clause to say:
>
> Returns: The value of result after effects have taken place.

The current wording says the same thing, only more succinctly.
Furthermore, it is the obvious truth of this expanded description that
makes it so confusing. Does a function ever produce its result before
it has completed its operations? Apparently the answer would appear to
be "yes" or why would this language be needed to rule out an already
impossible, alternative?

Greg




---
[ 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.comeaucomputing.com/csc/faq.html                      ]