This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ coding conventions: namespaces, references and getters (was Re: [PATCH 2/2] Introduce beginnings of a pipeline class.)


On Tue, 2013-07-30 at 11:30 +0200, Martin Jambor wrote:
> 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

How are the dot operator semantics in C different from the dot operator
semantics in C++?

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

Sorry, I have difficulty understanding your reasoning here.  Could you
provide an example for "Putting a reference where none has been before
might result in silent and hard to spot erroneous modifications."?

Cheers,
Oleg


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]