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