From: lrtaylor@micron.com
To: <svisor@lycos.com>, <gcc-help@gcc.gnu.org>
Subject: RE: Inherited member( void )const - const to be or not to be
Date: Tue, 07 Sep 2004 16:40:00 -0000 [thread overview]
Message-ID: <363801FFD7B74240A329CEC3F7FE4CC40309617B@ntxboimbx07.micron.com> (raw)
Basically, you can't have a const function returning a non-const pointer
or reference to that object, because that would then allow you to call a
non-const function on the object, violating the fact that you declared
the first function as const. If you want to get a non-const pointer to
the object, then you can't declare your getProvider function as const,
because it really isn't, even though it is not changing any members of
the class.
Thanks,
Lyle
-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of SVisor
Sent: Tuesday, September 07, 2004 10:35 AM
To: gcc-help@gcc.gnu.org
Subject: Re: Inherited member( void )const - const to be or not to be
Hi and thanks for the reply, but I do not agree...
...
> Don't use _CONST ... that's a reserved symbol.
Well that was news. Anyway it was just "dummy" code.
...
> All symbols starting with underscore followed by a capital letter are
> reserved. All symbols with two underscores in a row anywhere are
reserved.
name__more is not reserved. __name is reserved. Usage of _Name is not
recomended, but what I know not reserved. At least thats what I have
been taught. No one has _ever_ shown proof of anything else (heck no one
has shown me proof of what Ive learned, I just have accepted it ;-). Do
you have any link to a list of which combinations are reserved and which
are not?
> I've fixed your code, works now just fine. Compiled either way.
NO! You _broke_ it! Now you return a pointer to constant, and thats
_NOT_ what I wanted. I wanted to hint the compiler that a function does
not change members, but I can still change members (and call non
constant member-functions) using the returned pointer (and its legal
C++). The question was more about cast from "this", like this:
virtual CProvider* getProvider( void )const{ return (CProvider*)this; }
It will compile and provide sane working code, but its C (not C++)
styled. And the cast is not _safe_: The code would compile even if the
class would not inherit from CProvider.
...
> BTW: using the -DCONST=const is preferred. So much so, that you
should
I do not agree as thats not portable across all compilers. While my
construct is (well 99.9% of them at least). The code was just dummy code
to show a point, and make it easy to test. You usually know if something
is const or not :-).
// Jarmo
--
> just have const in the code. Const correctness should be worked in
from
> the beginning.
>
> HTH,
> --Eljay
>
> - - - - - - - - -
> // Compile #1: g++ -DCONST=const foo.cpp
> // Compile #2: g++ -DCONST= foo.cpp
> #include <cstdio>
>
> class CProvider
> {
> protected:
> const char* str;
> public:
> CProvider(const char* s)
> : str(s)
> {
> printf("CProvider(%s)\n",str);
> }
>
> void echo() CONST
> {
> printf("CProvider(%s)::echo()\n", str);
> }
> };
>
>
> class CAbstract
> {
> public:
> CAbstract()
> {
> printf("CAbstract\n");
> }
>
> virtual ~CAbstract()
> { }
>
> virtual CProvider CONST* getProvider() CONST = 0;
> };
>
>
> class CAllocated : public CAbstract
> {
> protected:
> CProvider* ptr;
>
> public:
> CAllocated()
> {
> printf("CAllocated\n");
> ptr = new CProvider("Allocated");
> }
>
> virtual CProvider CONST* getProvider() CONST
> {
> return ptr;
> }
> };
>
>
> class CInherited : public CAbstract, public CProvider
> {
> public:
> CInherited()
> : CProvider("Inherited")
> {
> printf("CInherited\n");
> }
>
> virtual CProvider CONST* getProvider() CONST
> {
> return this;
> }
> };
>
>
> int main()
> {
> CAllocated tmp1;
> CInherited tmp2;
>
> tmp1.getProvider()->echo();
> tmp2.getProvider()->echo();
>
> CAbstract* pTmp1 = &tmp1;
> CAbstract* pTmp2 = &tmp2;
> pTmp1->getProvider()->echo();
> pTmp2->getProvider()->echo();
> }
>
>
next reply other threads:[~2004-09-07 16:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-07 16:40 lrtaylor [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-09-06 11:01 SVisor
2004-09-07 12:58 ` Eljay Love-Jensen
2004-09-07 16:35 ` SVisor
2004-09-07 17:10 ` Eljay Love-Jensen
2004-09-21 13:34 ` Claudio Bley
2004-09-21 13:41 ` Claudio Bley
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=363801FFD7B74240A329CEC3F7FE4CC40309617B@ntxboimbx07.micron.com \
--to=lrtaylor@micron.com \
--cc=gcc-help@gcc.gnu.org \
--cc=svisor@lycos.com \
/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).