C++ PATCH: PR 11493 and PR 11495

[Gerald Pfeifer]

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