This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ coding conventions: namespaces, references and getters (was Re: [PATCH 2/2] Introduce beginnings of a pipeline class.)
- From: Martin Jambor <mjambor at suse dot cz>
- To: Oleg Endo <oleg dot endo at t-online dot de>
- Cc: David Malcolm <dmalcolm at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 30 Jul 2013 11:30:49 +0200
- Subject: Re: C++ coding conventions: namespaces, references and getters (was Re: [PATCH 2/2] Introduce beginnings of a pipeline class.)
- References: <1374678544-8678-1-git-send-email-dmalcolm at redhat dot com> <1374678544-8678-3-git-send-email-dmalcolm at redhat dot com> <20130725130845 dot GB12455 at virgil dot suse> <1375122002 dot 23374 dot 86 dot camel at surprise> <1375124573 dot 2328 dot 39 dot camel at yam-132-YW-E178-FTW>
Hi,
On Mon, Jul 29, 2013 at 09:02:53PM +0200, Oleg Endo wrote:
> On Mon, 2013-07-29 at 14:20 -0400, David Malcolm wrote:
> > >
> > > The same here and at a few other places. It may be just me not being
> > > used to references... nevertheless, if someone really wants to use
> > > them like this, at least make them const and you will save a night of
> > > frantic debugging to someone, probably to yourself. But I strongly
> > > prefer pointers... it's hard to describe how strongly I prefer them.
> >
> > OK. How do others feel? As I said above, I like the above idiom,
> > since it puts the assertion of non-NULLness in a single place.
>
> I'm voting for references. References can be seen as yet another
> software structuring tool that instantly communicate some properties
> such as you mentioned above. In addition to that it's also a hint of
> ownership, i.e. if I get an object& from somewhere I know that I better
> not even think about whether to delete it or not.
>
well, let me stress again that we should think about this in the
context of GCC. In GCC, we are used to C semantics of the dot
operator and have a lot of existing code that we will continue to use
and mix with new code with the same assumption. Putting a reference
where none has been before might result in silent and hard to spot
erroneous modifications.
At the same time, we are used to lookup whether the pointer we got can
be NULL or not if necessary. Moreover, in GCC, NULL-dereferences are
not particularly dangerous and are easy to debug.
In the context of GCC, there will be no ownership hints of this kind
simply because new code will co-exist with tons of old code which uses
pointers and will not give any such hints and so you can't assume you
could free its pointers. Let me not even mention GC.
Therefore, I'd avoid non const references where we can use pointers.
Thanks,
Martin