Prev: Layout of a most derive object of a type
Next: Call for Paper The International Journal of Computer Science (IJCS)
From: Seungbeom Kim on 5 Feb 2010 02:48
Goran wrote:
> On Feb 4, 10:34 pm, "Martin B." <0xCDCDC...(a)gmx.at> 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 http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Martin B. on 5 Feb 2010 02:48
Goran wrote:
> On Feb 4, 10:34 pm, "Martin B." <0xCDCDC...(a)gmx.at> 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.

br,
Martin

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 | 
Pages: 1
Prev: Layout of a most derive object of a type
Next: Call for Paper The International Journal of Computer Science (IJCS)