Re: [boost] [explore] Extending namespace std
Hello again. I previously presented an argument of why our best option for container streaming is to extend namespace std. I was surprised by the dearth of responses, but I understand that we're all busy and I admit was a bit wordy. Here is my argument again with, heavily snipped. I think this is the most important issue in making this a boost library. Thanks for reading. Jeffrey Faust wrote:
In my opinion the ideal interface is the most natural, simplest, and the most familiar to C++ developers: 'cout << c;' where c is a container of type C.
The only way I know how to make 'cout << c;' work for all cases is to put operator<<(C) in the same namespace as C. For example, variant<C, ...> will not stream if C is in std and operator<<(C) is not.
In regards to extending namespace std, I understand what the standard says and I think I understand the reasons behind it. One could add something to namespace std that conflicts with an existing item, changing the behavior. This is undefined behavior, and the standard is right in restricting it. I don't believe this problem exists for this library in how we plan to extend std.
If we know that on all supported compilers that extending namespace std in this way behaves correctly, what is the concrete problem of doing so?
-- Jeff Faust
Jeffrey Faust wrote:
In regards to extending namespace std, I understand what the standard says and I think I understand the reasons behind it. One could add something to namespace std that conflicts with an existing item, changing the behavior. This is undefined behavior, and the standard is right in restricting it. I don't believe this problem exists for this library in how we plan to extend std.
How can anyone possibly know that? That is, how could two different developers who didn't know each other possibly know that they weren't going to conflict? Of course if you wanted to officially extended the namespace that would be a different thing entirely. Robert Ramey
"Robert" == Robert Ramey <ramey@rrsd.com> writes:
Robert> Jeffrey Faust wrote: >>> In regards to extending namespace std, I understand what the >>> standard says and I think I understand the reasons behind it. >>> One could add something to namespace std that conflicts with an >>> existing item, changing the behavior. This is undefined >>> behavior, and the standard is right in restricting it. I don't >>> believe this problem exists for this library in how we plan to >>> extend std. Robert> How can anyone possibly know that? That is, how could two Robert> different developers who didn't know each other possibly Robert> know that they weren't going to conflict? Robert> Of course if you wanted to officially extended the namespace Robert> that would be a different thing entirely. It is more than conflict: the C++ standard fully defines the content of std and compilers are not required to implement it as they implement other namespaces, as long as they behave as if such a namespace was defined. In particular, turning the entire namespace std { } block into a compiler-time nop is entirely ok. Not that this happens with any of the presently available compilers, but it could. On the other hand, if we can get some nice functionality that cannot be achieved otherwise, I wouldn't have too many problems with being pragmatic and extending std. If it becomes very useful, it might be accepted into the standard or additional mechanisms not relying on extending std may be provided. Best regards, Maurizio
participants (3)
-
Jeffrey Faust -
Maurizio Vitale -
Robert Ramey