From: Michael Veksler <VEKSLER@il.ibm.com>
To: Rene Rebe <rene@rocklinux-consulting.de>
Cc: gcc@gcc.gnu.org, valentin@rocklinux-consulting.de
Subject: Re: GCC 3.4.0 and template type resolution bug (OT)
Date: Thu, 29 Apr 2004 12:15:00 -0000 [thread overview]
Message-ID: <OF48D4B9D5.534B38CB-ONC2256E85.0035C138-C2256E85.003A2FB6@il.ibm.com> (raw)
In-Reply-To: <20040429.095341.607969633.rene@rocklinux-consulting.de>
This is off topic for gcc@gcc.gnu.org....
You should take it to comp.lang.c++.moderated or some such.
René Rebe wrote:
> Michael Veksler wrote:
> >
> > You should use this->m_info, otherwise the compiler will look for
m_info
> > outside your classes,
>
> I find this behavior a bit counter-intuitive. In which section is it
> enforced by the ANSI standard?
I don't have the time to re-read that section in the standard.
This behavior makes a lot of sense. Consider the following:
int count;
template <class T> struct A {
int count;
};
template <class T> struct B : public A<T> {
int Get() { return count; }
};
// First specialization.
template <> struct A<int> {};
Now, what do you think should happen in B<int>::Get() ?
Obviously, A<int>::count does not exist, so
it is either an error, or A<int>::Get() should
read ::count.
Now, consider an extension to the example:
// A second specialization
template <> struct B<int> : public A<int> {
int Get() { return count; }
};
It looks quite redundant - it looks exactly the same
as the non-specialized case. The only difference is
that here, it is not obvious why it should be rejected.
B<int> can simply use ::count. To be consistent,
the non-specialized B<int> should also access ::count.
Conclusion:
The only consistent way to handle B<T>
it is to access ::count from any B<T>.
Now, for gcc-3.2 and many other "old days" compilers
will do something inconsistent:
If global count is accessible B<double>::Get() will
access the global variable. If count is inaccessible,
B<dobule>::Get() will access A<double>::count.
This means that even with gcc-3.2 you should use
this->count to access the base class. Otherwise your
private count is practically exposed to spoofing
(mostly accidental).
next prev parent reply other threads:[~2004-04-29 10:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-29 7:53 GCC 3.4.0 and template type resolution bug Rene Rebe
2004-04-29 8:04 ` GCC 3.4.0 and template type resolution bug (no) Michael Veksler
2004-04-29 11:45 ` Rene Rebe
2004-04-29 12:15 ` Michael Veksler [this message]
2004-04-29 12:19 ` Giovanni Bajo
2004-04-29 9:08 ` GCC 3.4.0 and template type resolution bug Vladimir Prus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=OF48D4B9D5.534B38CB-ONC2256E85.0035C138-C2256E85.003A2FB6@il.ibm.com \
--to=veksler@il.ibm.com \
--cc=gcc@gcc.gnu.org \
--cc=rene@rocklinux-consulting.de \
--cc=valentin@rocklinux-consulting.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).