Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-03-11 10:53:19

Pavel Chikulaev wrote:
> "Tobias Schwinger" wrote :
>>Honest answer: I belive this idea is no good.
> If I need numbers It's doesn't mean that user will see
> them. I'm just going to put unique number to each tree

Oh, I've nothing against numbers in general !
...and I wasn't concerned about hiding them from the user, either.

> shape. And use with maximum value to remove
> disambiguos situations.

Problems like the one you describe here (like hitting the boundaries of
the language) are usually solved best by stepping back and finding a way
dodge around it instead of using hammer and crowbar to solve them.

( The design of a software component can be seen as a path through a
decision tree. When encountering a leaf node and the design is not
complete, it is necessary to ascend and take another branch.
The boost mailing list is a forum where you can meet people very trained
and experienced in traversing these trees. The right questions at the
right nodes will literally boost the traversal process ;-) )

>>Isn't it enough to tell your lib operator + and operator * are "expression
>>object factories" rather than imperative routines ?
> Bad English. Please try again with simplier words :)

expression object factory:
  function (only) returning an expression object (to be evaluated later)

imperative routines (in this context):
  function that does the calculation (and returns the result)

>>It might be possible to partially allow stuff like this using overloading [
>>ref. ], but the possibility of creating ambigous situations can't be
>>fully eliminated.
> I'm already using this. But aforementioned examples were
> exclusions where that rule doesn't work.

That's why I called them ambiguous.



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