This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH: PR 11493 and PR 11495
On Fri, 18 Jul 2003, Wolfgang Bangerth wrote:
> Below is a patch for this. Let me know if this is what people think is
> what we want.
Thanks a lot! As I wrote, I shouldn't actually read GCC mail until
Wednesday, but as you kindly worked out such a complete patch, I thought
I'd have a look nevertheless. ;-)
This definitely is something I would have loved to find when first
encountering this; my comments below are just trying to make it even
easier for non-experts.
> I have added a note to the place where this message is generated, to
> state that the wording in the message is copied in the manual and that
> they should be kept in synch. Is this appropriate?
Definitely!
> ! Another, similar example involves calling member functions of the base
> ! class:
"_A_ base class"?
In the example, how about keeping the base class a regular class (that
is, no template class)?
> ! Again, the call to @code{f()} is not dependent on template arguments
> ! (none of the arguments -- of which there are none anyway here -- depend
> ! on the type @code{T}, and it is also not otherwise specified that the
> ! call should be in a dependent context), so a global declaration of such
> ! a function must be available, since the one in the base class is not
> ! visible until instantiation time.
Perhaps omit the "-- of which...here --" part, and split the sentence
somehow?
> ! The error can be removed by making the code valid: either write the call
> ! as @code{this->f()}, or @code{Base<T>::f()}.
"To make the code valid, either write..."?
> ! Using the
> ! @code{-fpermissive} flag will also let the compiler accept the code, by
> ! marking all function calls for which no declaration is visible at the
> ! time of definition of the template for later lookup at instantiation
> ! time, as if it were a dependent call. We do not recommend using this
> ! flag for this purpose, since it will generate lots of warnings
Hmm, the flag doesn't generate warnings; perhaps simply omit that part
for brevity?
> ! and also
> ! because it will only catch cases where functions in base classes are
> ! called, not where variables in base classes are used (as in the example
> ! above).
"...because it will not catch cases..."?
Thanks again,
Gerald