Does covariant return types hold for non-virtual?
in [C++]
|
Prev: Constrained name value pairs or pre-filled names types?
Next: So, it's not just ANY compile error that can be used with SFINAE.
From: Alf P. Steinbach on 18 May 2010 00:53 * Paul Bibbings: > "Alf P. Steinbach"<alfps(a)start.no> writes: >> On 17.05.2010 01:48, * Paul Bibbings: >>> >>> Whatever `covariant' means "in general" is irrelevant [to using this term >>> in general] owing to the fact that the ISO defines the term specifically >>> according to what it requires for its purposes. > > May I politely suggest that the above style of quoting, in which words > have been added by yourself which may not be immediately obvious as > such, is unhelpful, particularly where that addition completely > changes the meaning of those words. It's common practice to put such clarifications/interpretations/context in square brackets. > Rather, it is my assertion that "Whatever `covariant' means 'in general'" > is irrelevant /in the context of the OP's original question/ which, as the > Subject line shows, was "Does covariant return types hold for > non-virtual?" As I pointed out then, both directly to the OP and also to Joshua, who also think so, the OP's question had nothing to do with covariance. So I didn't think you could be arguing that in response to me, it would be completely meaningless, as if I'd maintained the opposite. If your articles had mentioned that this was what they were about then I'd not made the assumption about what they were arguing, expressed in the brackets you disliked above. However, I'll give my telepathy circuit a severe bashing for not engaging. ;-) Cheers & hth., - Alf -- blog at <url: http://alfps.wordpress.com> [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Joshua Maurice on 18 May 2010 00:51 On May 17, 11:21 am, "Alf P. Steinbach" <al...(a)start.no> wrote: > On 17.05.2010 01:42, * Joshua Maurice: > > On May 15, 1:32 pm, "Alf P. Steinbach"<al...(a)start.no> wrote: > >> On 15.05.2010 00:22, * Joshua Maurice: > >>> A::foo could just > >>> as easily have the return type "int" or "std::string", and the > >>> analysis would come out the same. > > >> No, in that case none of the example expressions would compile. > > >> The first example expression works because foo has a result type that is covariant with respect to each foo declaration's > containing class. > > > Ok. Let's do this then. I first fixed up your example so it would > > actually compile. Here it is: > > struct A > > { > > A& a() { return *this; } > > A& foo() { return *this; } > > }; > > struct B : A > > { > > B& b() { return *this; } > > B& foo() { return *this; } > > }; > > void foo() > > { > > B().foo().b().a(); //compiles fine > > B().a().foo().b(); //compile error > > } > > "ComeauTest.c", line 14: error: class "A" has no member "b" > > B().a().foo().b(); > > > Now, here's the same code with my suggested modification: > > struct A > > { > > A& a() { return *this; } > > int foo() { return 1; } > > }; > > struct B : A > > { > > B& b() { return *this; } > > B& foo() { return *this; } > > }; > > void foo() > > { > > B().foo().b().a(); //compiles fine > > B().a().foo().b(); //compile error > > } > > "ComeauTest.c", line 14: error: expression must have class type > > B().a().foo().b(); > > > So, I ask again: how does "covariant" come into this analysis at all? > > Add a test case like > > B().a().foo().a() > > and you'll see some difference between A::foo() having 'int' and 'A&' result type. > > Sorry for not providing a clarifying enough example. > > More generally, covariant result types of non-virtual methods is the common > solution to implementing that covariance where the compiler and/or language > doesn't support it. See my reply else-thread to Paul Bibbings. In short, I don't > believe that you're serious. I am serious. (I'm always serious.) I believe I now see the point which you are trying to make. You are trying to talk about an idiom / pattern to have covariant return types of member functions of the same name in a hierarchy without using compiler support for covariant return types of overriding virtual functions. It is a good point to make, and it is useful to know. However, if I were to explain to a student why the second and third expressions do not compile, I would not talk about "patterns to work around lack of compiler support for covariant return types of virtual functions". I would instead explain what the compiler is doing, what steps it is taking, and the likely error messages you will see when you do it. From this perspective, the compiler does not know or care about your pattern, your goal, or any covariant analysis. Here is your original claim from else-thread which is the original point of contention: > Now writing B().foo().b().a() should work nicely, but writing B().a().foo().b() > should not compile. The first expression works because the result type of foo is > covariant. Succinctly, you are explaining from the perspective of someone implementing a specific pattern to have covariant return types of functions without using C++ standard support for covariant return types of overriding virtual functions. This was not clear at all in the context of your first post. In the original context of your quote in your first post in this thread, the quote is so unclear and misleading that I will still label it incorrect. In context, the correct answer is: "It will not compile because there is no member function named 'b' found in the type 'A'." However, if it was explicitly stated or understood that we were trying to implement this specific pattern, then it makes little sense to say "There is no member function named 'b' found in type 'A'." Instead, the correct answer in this new context is "You need covariant return types to make this pattern work." -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Paul Bibbings on 19 May 2010 01:42 "Alf P. Steinbach" <alfps(a)start.no> writes: >> Rather, it is my assertion that "Whatever `covariant' means 'in general'" >> is irrelevant /in the context of the OP's original question/ which, as the >> Subject line shows, was "Does covariant return types hold for >> non-virtual?" > > As I pointed out then, both directly to the OP and also to Joshua, who > also think so, the OP's question had nothing to do with covariance. I would have thought that the OP's question has everything to do with covariance, simply on account of the fact that the question contains the term `covariant': "Does covariant return types hold for non-virtual?" To pull away from this and assert that the question has "nothing to do with covariance" is merely to side-step the question itself and answer another question as one that you perhaps prefer, essentially. This does not change the fact that the answer is "No," of course, which is perhaps what you intended by "nothing to do with covariance." Stating it in the simpler form, however, makes it easier to answer within the language of the Standard, for which the term `covariant' is defined, as I have maintained. > So I didn't think you could be arguing that in response to me, it > would be completely meaningless, as if I'd maintained the opposite. If > your articles had mentioned that this was what they were about then > I'd not made the assumption about what they were arguing, expressed in > the brackets you disliked above. However, I'll give my telepathy > circuit a severe bashing for not engaging. ;-) I think your confusion has arisen from your wanting to focus on the content of the example given rather than on the question itself, perhaps as being of more interest to you. In so shifting the focus off to the left, so to speak, you chose to take the term (covariant) with you and defined it according to your own meaning. At this point we lost our commonality of language (the language of the Standard governing the C++ language element we are discussing). In this way it is then easy to see how you had lost contact with the actual question as the context of my response, otherwise it is incomprehensible how you might suppose that it would require `telepathy' in order to merely remember the context of the question as posed. On these terms, clarifying my assertion above (offered merely to compensate for your mis-quoting), nonetheless does not mean that the points that I have raised in response to your assertions do not still apply. The fact remains that your discussion does not illustrate covariance, as defined. Defined terms must be used as such. Regards Paul Bibbings -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Alf P. Steinbach on 19 May 2010 07:35 * Paul Bibbings, on 19.05.2010 18:42: > "Alf P. Steinbach"<alfps(a)start.no> writes: > >>> Rather, it is my assertion that "Whatever `covariant' means 'in general'" >>> is irrelevant /in the context of the OP's original question/ which, as the >>> Subject line shows, was "Does covariant return types hold for >>> non-virtual?" >> >> As I pointed out then, both directly to the OP and also to Joshua, who >> also think so, the OP's question had nothing to do with covariance. > > I would have thought that the OP's question has everything to do with > covariance, simply on account of the fact that the question contains the > term `covariant': "Does covariant return types hold for non-virtual?" > To pull away from this and assert that the question has "nothing to do > with covariance" is merely to side-step the question itself and > answer another question as one that you perhaps prefer, essentially. The OP's question had nothing to do with covariance, and everything to do with ambigious lookup. See my reply to the OP. For that matter, see other's replies; AFAICS everyone's in agreement on that. > This does not change the fact that the answer is "No," of course, One can not answer "No", in any meaningful way, to a piece of code & some facts, which was how the OP presented his real question. Neither can one, as I see it, answer "No" in any meaningful way to the subject line's question, which itself, IMO, was and is meaningless since it had no relation to the code and facts. Really stretching it one /could/ interpret the subject line as a question about restrictions on result types placed by the language. But the OP didn't mention any restrictions, and this interpretation does not fit the code. So, a simple "no" as an answer, far from being "of course", is IMHO completely meaningless. In that connection, I note that the OP responded once in this thread, and that was to my reply. And that OP's response to my reply started with "Yes". [snip] > On these terms, clarifying my assertion above (offered merely to > compensate for your mis-quoting), This is the main reason I'm replying. I have not misquoted you. Adding context in square brackets in a short quote of three or four lines is common practice. Square brackets containing text that clarifies some context is recognized as such by nearly all. There is no intent to pretend that the text in the brackets is quoted text. Indeed in this kind of forum it would be practically impossible to deceive that way even if it wasn't a recognized convention, since it will be pointed out & corrected by the person quoted. ;-) All you have to do when you feel that such a clarification doesn't capture your intended meaning is to follow up stating what you did mean -- not talk about "mis-quoting" and such, which is just silly for a simple misunderstanding. Cheers & hth., - Alf -- blog at <url: http://alfps.wordpress.com> [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Paul Bibbings on 20 May 2010 12:35
"Alf P. Steinbach" <alfps(a)start.no> writes: > * Paul Bibbings, on 19.05.2010 18:42: >> On these terms, clarifying my assertion above (offered merely to >> compensate for your mis-quoting), > > This is the main reason I'm replying. I have not misquoted you. Adding > context in square brackets in a short quote of three or four lines is > common practice. > > Square brackets containing text that clarifies some context is > recognized as such by nearly all. There is no intent to pretend that > the text in the brackets is quoted text. I was trying to follow through any guidance on this in the article "news.newusers.question: Quoting style in newsgroups postings" (http://www.anta.net/misc/nnq/nquote.shtml), reached via the FAQ for this group at 5.4 - "Many more general netiquette questions are answered in the newsgroup news.announce.newusers. This newsgroup contains many must-read articles for new users." - but couldn't find anything to this effect. However, one reason that I would propose that it is ill-advised to alter quotes in this way is that the quoted text itself may, of course, *already* contain text in square brackets, in which case standard quoting mechanisms effectively remove any subsequent distinction between whether such an inclusion is the OP's or an addition by the respondent. Avoidance of such forms of addition is therefore not mandated against by the FAQ (perhaps it should be?), but I would want to suggest, IMHO, that it would best be avoided in the interest of clarity. Regards Paul Bibbings -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |