>From: Surya Pratik Saha <spsaha@cal.interrasystems.com> >But, again, the same LRM section says >that, "The function bound by the overload declaration uses the same >scope search rules as a function enable from the scope where the >operator is invoked." That means, The function bound by the overload >declaration can be a forward declaration ( as is the case for function >enable ) with respect to the expression where the operator is invoked. There are no forward references to function declarations. There is the appearance of forward references because unresolved functions are then resolved as hierarchical references. Assuming that the function binding for the overload declaration is not allowed to be a hierarchical reference, this "forward resolution" would not be allowed. In other words, I would interpret the hierarchical resolution to the forward reference as not being part of the normal scope search rules for functions. But that is just my opinion. >A. The design should be a valid one and the function definition of >"fmultcg" would be serach only at evaluation time, as this is a dynamic >choice which completely depends upon where the operator is actually >invoked. I would not call this "dynamic", nor would the search occur at evaluation time. It would be a static search, resolved at compile time. It just might be different for different invocations. Based on the wording of the LRM, I would assume that this was what was intended. It explicitly says that the function is bound based on a scope search from the invocation, not from the overload declaration. This is presumably done independently for each invocation. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Feb 27 15:33:07 2007
This archive was generated by hypermail 2.1.8 : Tue Feb 27 2007 - 15:33:19 PST