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. 14.5.5.2 ], 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. Regards, Tobias