public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
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();
> }
> 
> 

             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).