Hello George and Rene, just an update, I am implementing new overloading scheme. It is about 60% done and working with some simple cases. Now, I am concenred about backward compatibility. Overload resolution behavior will change once new implementation is activated. This is one of the most complicated thing to implement in C++ spec. It will take time that it settles to a reasonable quality. Thank you Masaharu Goto >Hi Masa, >I agree with George on this point. >Could you clarify what you mean by performance penalty ? Only when you >generate the byte code or when you execute it ? Could you quantify how >much >overhead it could be in the case the overhead is at run time ? >I have no idea on how much work it is to implement the same behaviour >as the compilers, but I think it is important to not diverge from the >standard C++ on this point. > >Rene > > >George Heintzelman wrote: >> >> > 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. his behavior is not fully compliant t o >> > 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:22 MET