From 2735070125789429774 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,b154d5af8d1c3e9 X-Google-Attributes: gidf78e5,public From: shapcott@wallaby.cig.mot.com (David B. Shapcott [C]) Subject: Re: Overloaded Virtuals Date: 1997/02/24 Message-ID: <199702222109.QAA12375@po_box.cig.mot.com>#1/1 X-Deja-AN: 221122801 References: <199702211659.LAA13507@po_box.cig.mot.com> <5elru4$o1k@mulga.cs.mu.OZ.AU> X-Original-Date: 22 Feb 1997 21:07:29 GMT Organization: Cellular Infrastructure Group, Motorola X-Auth: PGPMoose V1.1 PGP comp.std.c++ Newsgroups: comp.std.c++ Originator: austern@isolde.mti.sgi.com In article <5elru4$o1k@mulga.cs.mu.OZ.AU>, Fergus Henderson wrote: > >The warning is correct. But why? >[...] >However, my copy of gcc 2.7.2 accepts it, so I think perhaps >you have oversimplified your example. My fault. IT around here has 17 versions of gcc installed on different machines. I must have compiled in the wrong xterm. When I made sure that the machine had 2.7.2 and my paths were set up correctly, it compiled and dispatched the virtuals according to overloading. > [...] So now 2.7.2 and MetroWerks dispatch the virtuals by the distinguished names according to overloading and SparcWorks does not. The questions remains what justification exists for this behaviour in SparcWorks? And if it is ANSI-compliant to hide Foo:apply(void) and Foo::apply(char *) because of Bar::apply(int), why? (And my 'vastly' simplified example did show the wrong pointer type in main; only if the derived class ptr is used does the compiler issue errors.) -- D. Brad Shapcott [C] Contractor, Motorola Cellular Infrastructure Group "Theory changes the reality it describes." --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]