Jim Hyslop wrote:
Robert Ramey <ramey <at> rrsd.com> writes:
Templates are a red herring here - the use of operator & in this case is independent of templates.
Maybe - but its not independent of the type. The key feature of the & operator in this instance is that its meaning save vs. load changes depending on the type its applied to. Generally I dislike and avoid this kind of invisible mode shifting. But in this case it has proved more useful than error-prone.
I suspected that the & operator was chosen due to its operator precedence being at a particular spot in the operator precedence hierarchy[...]
Except that operator precedence only applies to "built-in" operators - user defined operators are function calls, and have that level of precedence.
I realize this. But once one decides he wants to overload an operator, one has to pick an operator with consideration of its precedence. So that's the main reason I stuck with it.
The usage of << and >> are my own and are obviously analog to the concept of using << and >> for stream input / output respectively.
These I understand and agree with, because the analogy is well-known and understood.
Whow knows, maybe someday & will be added to the above.
So, for better or worse, that's how we arrived here.
Thanks for the explanation. Now that the library has been accepted, I'm not expecting this will change (at least not in the near future), I just wanted to know the rationale behind it. I'll have to pay more attention in the future ;=)
I don't think coming in earlier would have changed this. The usage of the & operator for this purpose seems to have been pretty well recieved. And of course it's not obligatory. One who believes its a detriment can just avoid its usage. That is why is_saving and is_loading are include in the archive interface. Robert Ramey