Ещё раз: стандарт Си++ явно разрешает "трогать" область имён std при соблюдении некоторых условий.
Только что получил ответ от Howard Hinnant (я связался с ним из-за C++ Standard Library Defect #226): From: Howard Hinnant
Subject: Re: N1387=02-0045: Customization Points.
Date: Fri, 12 Feb 2010 14:03:50 -0500
To: "Maxim Dementiev"
On Feb 12, 2010, at 1:51 PM, Maxim Dementiev wrote:
> Hi Howard,
>
> Thank you so much for your quick and informative reply!
>
> And thank you for invitation to the process of the C++ standardization.
> I'll try.
>
> Unfortunately, I'm not good at English, but I keep trying to improve my English.
Your English is one heck of a lot better than my Russian! :-)
>
> Please, can you help me with “17.6.3.2.1 Namespace std [namespace.std]” from n3000, first paragraph?
> I mean, briefly saying - no/yes.
>
> I'll put numbers and letters to refer the parts later:
>
> ------------- beginning -----------------
> 1. a) The behavior of a C++ program is undefined if
> b) it adds declarations or definitions to namespace std or to a namespace within namespace std
> c) unless otherwise specified.
> 2. a) A program may
> b) add a template specialization for any standard library template to namespace std
> c) only if the declaration depends on a user-defined type of external linkage
> d) and the specialization meets the standard library requirements for the original template and is not explicitly prohibited.
> ------------- end -----------------
>
> The part 1b introduces an action, 1a is the result of 1b.
> 1c states that there are exceptions to that consequence.
>
> 2a explicitly permits (allows) to do the action 2b.
>
> (Why 'may'? Does it mean 'can'?
Yes.
> Unfortunately, I don't have “ISO/IEC 2382-1:1993 - Information technology - Vocabulary - Part 1: Fundamental terms” - may be it precise the meaning of “may” here, like RFC 2119 does for RFCs)
>
> 2c and 2d are conditions of the action 2b.
>
> 2b is a special case of 1b.
> Hence 1a may not be a consequence of 2b because of 1c statement.
>
>
> Or in other words, the wording explicitly allows (permits) adding a template specialization for any standard library template to namespace std (only if 2c and 2d take place) without causing an undefined behavior.
Yes, you have stated it correctly.
>
>
> Can I publish your reply in my blog http://mpd.livejournal.com/ ?
> Thank you again!
Sure.
-Howard
Что ещё раз подтверждает мои рассуждения.
А вот предыдущее, не менее интересное сообщение, в котором Howard соглашается с точкой зрения Jonathan Wakely и приглашает (всех) принять участие в процессе создания следующего стандарта:From: Howard Hinnant
Subject: Re: N1387=02-0045: Customization Points.
Date: Thu, 11 Feb 2010 21:08:18 -0500
To: Maxim Dementiev
On Feb 11, 2010, at 6:48 PM, Maxim Dementiev wrote:
> Dear Howard Hinnant,
>
> I wonder if sdt::distance and std::advance are the customization points for iterators, regarding this discussion:
>
> http://gcc.gnu.org/ml/gcc/2009-08/msg00131.html
>
> Thank you in advance!
>
> Regards,
> Maxim P. Dementiev
> Moscow, Russia
Hi Maxim,
Please understand that my response is a matter of opinion, not of fact, since we are effectively talking about a standard in transition at this point.
In my opinion std::distance and std::advance need not be customization points because the std-definitions are sufficient for all iterators. For the first paper to explore the idea of customization points (and where are they) please see:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1289.html
This paper uses the term "primitive" instead of "customization point", but you should read the two as interchangeable. The latter simply became a better vocabulary term as the discussion evolved over the years.
All that being said, if you disagree with me, you've come to the right place. Anyone can submit an "issue" against the C++0X working draft by simply emailing me. I don't have to agree with the issue. It isn't up to me to decide. More detailed directions for submitting issues can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue
-Howard
Subject: Re: N1387=02-0045: Customization Points.
Date: Fri, 12 Feb 2010 14:03:50 -0500
To: "Maxim Dementiev"
On Feb 12, 2010, at 1:51 PM, Maxim Dementiev wrote:
> Hi Howard,
>
> Thank you so much for your quick and informative reply!
>
> And thank you for invitation to the process of the C++ standardization.
> I'll try.
>
> Unfortunately, I'm not good at English, but I keep trying to improve my English.
Your English is one heck of a lot better than my Russian! :-)
>
> Please, can you help me with “17.6.3.2.1 Namespace std [namespace.std]” from n3000, first paragraph?
> I mean, briefly saying - no/yes.
>
> I'll put numbers and letters to refer the parts later:
>
> ------------- beginning -----------------
> 1. a) The behavior of a C++ program is undefined if
> b) it adds declarations or definitions to namespace std or to a namespace within namespace std
> c) unless otherwise specified.
> 2. a) A program may
> b) add a template specialization for any standard library template to namespace std
> c) only if the declaration depends on a user-defined type of external linkage
> d) and the specialization meets the standard library requirements for the original template and is not explicitly prohibited.
> ------------- end -----------------
>
> The part 1b introduces an action, 1a is the result of 1b.
> 1c states that there are exceptions to that consequence.
>
> 2a explicitly permits (allows) to do the action 2b.
>
> (Why 'may'? Does it mean 'can'?
Yes.
> Unfortunately, I don't have “ISO/IEC 2382-1:1993 - Information technology - Vocabulary - Part 1: Fundamental terms” - may be it precise the meaning of “may” here, like RFC 2119 does for RFCs)
>
> 2c and 2d are conditions of the action 2b.
>
> 2b is a special case of 1b.
> Hence 1a may not be a consequence of 2b because of 1c statement.
>
>
> Or in other words, the wording explicitly allows (permits) adding a template specialization for any standard library template to namespace std (only if 2c and 2d take place) without causing an undefined behavior.
Yes, you have stated it correctly.
>
>
> Can I publish your reply in my blog http://mpd.livejournal.com/ ?
> Thank you again!
Sure.
-Howard
Что ещё раз подтверждает мои рассуждения.
А вот предыдущее, не менее интересное сообщение, в котором Howard соглашается с точкой зрения Jonathan Wakely и приглашает (всех) принять участие в процессе создания следующего стандарта:From: Howard Hinnant
Subject: Re: N1387=02-0045: Customization Points.
Date: Thu, 11 Feb 2010 21:08:18 -0500
To: Maxim Dementiev
On Feb 11, 2010, at 6:48 PM, Maxim Dementiev wrote:
> Dear Howard Hinnant,
>
> I wonder if sdt::distance and std::advance are the customization points for iterators, regarding this discussion:
>
> http://gcc.gnu.org/ml/gcc/2009-08/msg00131.html
>
> Thank you in advance!
>
> Regards,
> Maxim P. Dementiev
> Moscow, Russia
Hi Maxim,
Please understand that my response is a matter of opinion, not of fact, since we are effectively talking about a standard in transition at this point.
In my opinion std::distance and std::advance need not be customization points because the std-definitions are sufficient for all iterators. For the first paper to explore the idea of customization points (and where are they) please see:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1289.html
This paper uses the term "primitive" instead of "customization point", but you should read the two as interchangeable. The latter simply became a better vocabulary term as the discussion evolved over the years.
All that being said, if you disagree with me, you've come to the right place. Anyone can submit an "issue" against the C++0X working draft by simply emailing me. I don't have to agree with the issue. It isn't up to me to decide. More detailed directions for submitting issues can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue
-Howard