Re: A scoped_ptr class that does not allow NULL ?

From:

Tim H <thockin@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Tue, 1 Jun 2010 07:03:41 -0700 (PDT)

Message-ID:

<4a34f19f-d07d-466e-bef0-30f885877aad@g1g2000pro.googlegroups.com>

On May 31, 10:38 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:

On 1 juuni, 07:24, Tim H <thoc...@gmail.com> wrote:

On May 31, 8:23 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:

On 1 juuni, 03:32, Tim H <thoc...@gmail.com> wrote:

Does such a thing exist? It seems handy for self-documenting, at
least.

I whipped this up. Am i missing something?

<snip implementation>

Why you need it not to be NULL? NULL is important value of pointer.
Typical usage:

class Bar
{
public:
    Bar();
    beTricky();
};

void foo()
{
    boost::scoped_ptr<Bar> BarPtr; // is NULL

    try
    {
       // can't declare BarPtr here, otherwise would
       // be destroyed at end of block
       BarPtr.reset( new Bar() );
    }
    catch( ... )
    {
       // error handling, not sure it rethrows
       // and may result BarPtr remains NULL
    }

    if ( BarPtr )
       BarPtr->beTricky();
}

IOW i do not understand usage of pointers that can not be NULL. Can
you elaborate?

I have a lot of classes that take ownership of pointers (part of a
syntax tree for a language grammar). Those pointers can not be NULL,
or else the classes do not work.

I found myself littering the code with either asserts or with tests
for NULL, or else I kept referring back to the grammar to see if NULL
was viable (in some cases it is, in many it is not). I found myself
wanting a scoped_ptr class member that gets initialized from the ctor
and is very clear about ownership and expectations.

Now, I just look at the data member and it is
"NeverNullScopedPointer<Expression> m_expr;" and I know that the
expression is required to be non-NULL.

Understandable. When member scoped_ptr may not be NULL you need it to
be checked in constructors and where it is reset().

However when dealing with parsing trees the error messages are most
important thing. Usualy it is written by human what you parse and
human always demands detailed explanations how fool he is.

An errant NULL is an error in the parser, not the parsee :)

I would end up (when using your NeverNullScopedPointer) catching
"NeverNullScopedPtr reset to NULL" and "NeverNullScopedPtr initialized
to NULL" asap and then forming readable explanations what went wrong.
That results with double work since if i did put explicit NULL checks
(into constructors/reset locations) i could immediately throw useful
error messages/codes from there. Also if constructor initializes
multiple NeverNullScopedPtr i have to make the checks each time before
calling it otherwise how to make difference between two
"NeverNullScopedPtr initialized to NULL"?

Adding the extra traps for NULL literals actually caught one place
where I had screwed up, and making the ctor arg not have a default
value of NULL caught 2 places where I had forgotten to init a pointer.

You should have some static code analyzer that can detects
uninitialized members. I think most of them do but i may be wrong.

but uninitialized members such as scoped_ptr are perfectly fine.

So that was my use case. I was just wondering if there was already
something like this or if this was actually useful. Also hoping to
get feedback on any screw-ups I made.

Looks fine. Paranoid like i am most constructors that have 1 member i
declare "explicit" almost automatically.
Also these (T catches_null) members i would perhaps declare private.
But that is just matter of taste really.

Hmm, good point.