[global.functions] says:

> Unless otherwise specified, global and non-member functions in the standard library shall not use functions from another namespace which are found through argument-dependent name lookup (3.4.2).

This sounds clear enough. There are just two problems:

1. Both implementations I tested (VS2005 and GCC 3.4.3) do unqualified
calls to the comma operator in some parts of the library with operands
of user-defined types.

2. The standard itself does this in the description of some
algorithms. E.g. uninitialized_copy is defined as:

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

If understood literally, it is required to call operator,
(ForwardIterator, InputIterator).

For detailed discussion with code samples see
http://stackoverflow.com/questions/8719829/should-the-implementation-guard-itself-against-comma-overloading.

Proposal:

1. Add an exception to the rule in [global.functions] by permitting
the implementation to call the comma operator as much as it wants to.
I doubt we want this. or

2. Fix the description of the said algorithms and perhaps add a note
to [global.functions] that brings attention of the implementers to
avoid this pitfall.

Sincerely
Yakov Galka


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 2012-01-25 08:30, Yakov Galka wrote:
>  [global.functions] says:
>
>>  Unless otherwise specified, global and non-member functions in the standard library shall not use functions from another namespace which are found through argument-dependent name lookup (3.4.2).
>
>  This sounds clear enough. There are just two problems:
>
>  1. Both implementations I tested (VS2005 and GCC 3.4.3) do unqualified
>  calls to the comma operator in some parts of the library with operands
>  of user-defined types.
>
>  2. The standard itself does this in the description of some
>  algorithms. E.g. uninitialized_copy is defined as:
>
>>  Effects:
>>       for (; first != last; ++result, ++first)
>>         ::new (static_cast<void*>(&*result))
>>           typename iterator_traits<ForwardIterator>::value_type(*first);
>
>  If understood literally, it is required to call operator,
>  (ForwardIterator, InputIterator).
>
>  For detailed discussion with code samples see
>  http://stackoverflow.com/questions/8719829/should-the-implementation-guard-itself-against-comma-overloading.
>
>  Proposal:
>
>  1. Add an exception to the rule in [global.functions] by permitting
>  the implementation to call the comma operator as much as it wants to.
>  I doubt we want this. or
>
>  2. Fix the description of the said algorithms and perhaps add a note
>  to [global.functions] that brings attention of the implementers to
>  avoid this pitfall.
>
>  Sincerely
>  Yakov Galka

This issue has been forwarded to the LWG working group.

Greetings from Bremen,

Daniel Kr  gler


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]