TITLE: rationale for not overloading based on return type (Newsgroups: comp.std.c++, 12 Jan 98) SOLOFNENKO: "Alexey N. Solofnenko" > Hi, Dietmar! > > I always thought that it is prohibited to write template parameterized with > return type. STROUSTRUP: bs@research.att.com (Bjarne Stroustrup) That restriction was lifted years ago. Dietmar's code is correct. See Stroustrup: The C++ Programming (3rd edition) or any ISO draft from the last couple of years. SOLOFNENKO: > I have CD2 on my hard drive but I did not really read it (I will). > But in your example you wrote result type explicitly and I tried to > avoid it. That is the matter. C creators trusted programmers (maybe > too much). C++ committee does not. I want to be able to say to > compiler "Yes, these functions differ only with result types and > that is what I want.", but I can not. The programmer knows what > he is doing. STROUSTRUP: Actually, this has nothing to do with trust. I don't think that there is a significant difference in the degree to which I and Dennis trust programmers. The difference is in the way that trust is expressed. There is nothing you can do in C that you cannot do in C++. However, you may have to be explicit about it in C++. For example, in C++ function prototypes are mandatory whereas they are optional in C, this reflects evolution and a difference in compatibility constraints rather than a difference in trust. The reason that C++ doesn't allow overload resolution based on a return type (so that you need to use explicit qualification in the examples below) is that I wanted overload resolution to be bottom up. For example, you can determine the meaning of a subexpression a+b without considering the complete expression that a+b is part of. Overload resolution can be subtle so even though I knew how to use return types as part of resolution (Ada showed how), I decided not to. As a result of this decision, a+b means the same in a+b+c as in a+b+d. See Stroustrup: The Design and Evolution of C++ for more details of the design of C++.