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. 22.214.171.124 ], but the possibility of creating ambigous situations can't be
> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk