Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-10-14 14:15:21

Jim Hyslop wrote:
> Robert Ramey <ramey <at>> 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

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at