> Cint checks parameter matches from exact match to user conversion > all together with all the arguments. In this case, > TPhCalKey("String","String",100) > Cint searches in following order > TPhCalKey(char*,char*,int) > template<class T,E> TPhCalKey(T,T,E) > TPhCalKey(char*,char*,(any integral type)) > TPhCalKey(void*,void*,(any numerical type)) > TPhCalKey(anyUserConv(char*),anyUserConv(char*),anyUserConv(int)) > > In this case, because all 3 parameters matched with user defined conversion > before it sees the true candidate. This behavior is not fully compliant to > the standard , but speeds up overloading resolution in interpreter > environment. Please understand the speed advantage and stand with current > implementation. Yes, I understand what CINT is doing. I'm claiming the opposite: I think this particular variation from the standard is unintuitive and leads to subtle changes in code behavior between compiled and interpreted versions, and that this is worth a small speed penalty. At least for ROOT users, I suspect that little of the 'real work'/bulk of CPU time of code is spent in interpreted code. Certainly for us (Phobos), we use scripts first as control and direction of a ROOT session and second as a way to do fast prototyping, debugging and testing. I think this deviation causes potential problems with both of these uses. Furthermore, the standard says that a case where there is a real ambiguity in a function call is an error and must be detected. CINT's current behavior here is to accept an ambiguous function, picking one essentially randomly, and issue no diagnostic. Solving the problem about sub-resolution within classes of conversion would certainly fix this second deviation from the standard as well. Is the speed advantage really that big a deal? Most functions (except constructors) will have only at most a few overloads, and even for constructors, the cases where more complicated resolution is needed shouldn't be all that common; I wouldn't expect the time spent in overload resolution to expand by much except in pathological cases (all you need to do is make a list of those matching at a given stage, and make a single pass through them to find the best candidate if there is more than one). From profiling, you should be able to say how much time CINT currently spends in overload resolution versus its other tasks, in usual cases; is it really significant? George
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:21 MET