From: Seungbeom Kim on
Goran wrote:
> On Feb 4, 10:34 pm, "Martin B." <0xCDCDC...(a)> wrote:
>> And I'm personally completely OK with pointer parameters that must not
>> be NULL.
> OK, but why? If it must not be NULL, then pointer means more typing
> and more possibility to pass NULL where you should not.
> But more importantly, using pointers where reference suffices means
> underspecified design for little reason. I use pointer parameters only
> to mark them optional.
> In my experience, situations where non-optional parameter became
> optional are __extremely__ rare. OTOH, I have a lot of existing code
> that is using pointers almost exclusively. End result: there are
> masses of places where NULL check is performed and pointer can't
> possibly NULL, and it's quite unclear what should happen if that
> happens (heck, there are places where there's an assert and that's all
> - whoo-hoo). On the flip side, places where it can be NULL are easy to
> miss, so we tend to check for NULL indiscriminately, making already
> huge code base bigger.

Following a lot of advice that preferred references to pointers,
I used to employ reference data members for those with "points-to"
(or "refers to") semantics, as opposed to "has-a" semantics.
But that made the class nonassignable. So I switched to pointers.
Maybe you can keep the reference function arguments to ensure that
those pointees (or referees) are non-null and valid, but pointers
are still my preferred choice for the internal, actual data members.

Pointers are objects; references are not. This can invite some quite
weird irregularity to the behaviour of whatever is using them.

Seungbeom Kim

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Martin B. on
Goran wrote:
> On Feb 4, 10:34 pm, "Martin B." <0xCDCDC...(a)> wrote:
>>> ....
>>> So in the end, I think that one should just solve this issue through
>>> correct coding and abstain from seeking compiler help.
>> The situation with the Bad class in my example poses a maintenance
>> nightmare.
> That's a possibility, and that's why I proposed a vote (mine clearly
> says that what you did is too rare in the wild to matter ;-) ). Here's
> why I think it is rare: because use of references for class members is
> (well, at least, should be) rare. For example, such classes you can't
> copy it or use operator=. That alone excludes a myriad of uses. Also,
> one should often abstain from such uses due to unclear lifetime
> issues. It's not only about ref-to-temp cases such as yours: with a
> class-member reference, you tie class instance to external object, and
> you can't __ever__ un-tie that; that's dangerous in itself anyhow. Not
> so with pointers.
> In a way, I feel that your bigger error is not pass-by-ref, but use of
> a reference member.

Yes. You really have a point there. For these cases pointer members make
much more sense. My whole example was based on a refactoring case, where
using a const-ref member meant large stretches of code would not have to
be changed from dot-syntax to arrow-syntax.


[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]