Re: Destructor for const object
From: Virendra Verma (virenbeena_at_hotmail.com)
Date: 04/14/04
- Next message: tom_usenet: "Re: What is a good idiom for handling a lazy object?"
- Previous message: jimjim: "Re: why it seems that std::list::erase() doesnt free objects in a list, if the latter holds pointers to them?"
- In reply to: Nick Hounsome: "Re: Destructor for const object"
- Next in thread: Nick Hounsome: "Re: Destructor for const object"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 14 Apr 2004 08:05:26 -0700
"Nick Hounsome" <nh002@blueyonder.co.uk> wrote in message news:<FJ5fc.121$og6.111@news-binary.blueyonder.co.uk>...
> "Virendra Verma" <virenbeena@hotmail.com> wrote in message
> news:30ee7e04.0404131108.1df58d18@posting.google.com...
> I believe I have to use a reference counted class. The problem with
> > the above scenario was that I was using class variables for DbPtr
> > class which get duplicated before returning and thus committing both
> > copies. Here is the code that does the trick. DbBasePtr class is only
> > a single copy and keeps track commit status. If the copy is already
> > committed, second commit will simply be ignored.
> >
>
> It is still not clear what you are trying to do but I believe that it is
> still
> totally wrong.
Sorry, for lack of clarification.
The DbAutoPtr<T> class is only for disk i/o of objects. The objects on
disk is a chunk of bytes whose address, size and class ids are
maintained elsewhere. If program knows these object references, it
will automatically load the blob into memory and construct the object
of right type. These disk objects do not have polymorphic behavior.
That is another public implementation on top of this interface. May be
I should rename this class to DskAutoPtr. At a lower level is
implemented recovery mechanism. All this class does is load objects
into memory, maintain status if the object has become dirty via
pointer operators and commit them on destruction whenever object is
deleted. BTW, this class is private to database implementor and it
needs to be extremely efficient.
>
> 1. For the DbAutoPtr you cannot have the reference count in the pointer.
> It must either be in the object pointed to or on the heap.
Why not? The reference count is part of DbBasePtr class which
maintains object parameters such as its disk address, size and a
pointer to memory holding disk data. When data is read from disk, it
is a clean copy. Once you modify/extend the data it becomes dirty and
the object may be relocated to different disk space.
> 2. DbAutoPtr ctor should take a T* because it is supposed to point to a T.
Nop because these objects need to be on a special heap so that I can
apply recovery mechanism (rollback or commit).
> 3. The pointer should ONLY do the owning/commit. Use a separate mechanism to
> create new instances or find them initially in the db.
In my case, the pointer also manages the memory for reasons mentioned
in 2) above.
> 4. The sizeof suggests an extremely dodgy implementation. I suggest that you
> should be allocating
> these things with a custom new: as in DbAutoPtr<X> xp = new(db) X;
Yes, it is. For compactness and efficiency, disk objects need to be
contigious. For a B++ index node, for example, the size of object is
class size plus the size of entries in the node. Once you reference
this object via DbAutoPtr class, entire index node is loaded and
mapped to the index node class. Naturally, node reference (such as its
disk address etc) in the index node entry will be loaded and when I
need to reference them I will create DbAutoPtr object and use it in
normal way to traverse down the tree.
> > I have another question. In my DbAutoPtr<T> class below, which
> > operator gets called for the rvalue operand, a->? Is there an implicit
> > or elegant (without creating or typecasting to a const object) way of
> > "const T& operator->( ) const" version to be called as the rvalue is
> > not being modified?
>
> 1. What's wrong with const T*?
There is nothing wrong except that I have to create one by copying it
which means that data base implementor has to be aware of the cost of
dirtying an object as he is doing it unintentionally in my example. I
was trying to avoid using fault on reference mechanism supported by
the operating system. It seems that I can't avoid it.
> > bool isNull( ) const;
>
> unnecessary and unnatural - it should work like an ordinary ptr
True, but I needed to know if it is NULL pointer. I could have created
a NULL pointer class and provided a comparison operator.
Unfortunately, this class is not intended to be a public/library class
- just create a nicer database code so that it is easier to maintain.
Sophistication is not the goal.
>
> >
> > fsize_type address( );
> > fsize_type address( ) const;
> > size_type size( ) const;
> > void setAddress( fsize_type nAdr );
> > void setSize( size_type nSize );
> > bool loadData( );
> > bool writeData( );
>
> All this stuff above belongs somewhere else.
That's why it called DbAutoPtr not a general AutoPtr class. It simply
manages references to objects on disk.
>
> >
> > const DbBasePtr * basePtr( ) const;
>
> ?
I needed this for debugging purposes.
>
> >
> > // protected:
> > const T * pointer( ) const;
> > T * pointer( );
> >
> > protected:
> > DbRefCount< DbBasePtr > _oData; // Object data
>
> How does this work then?
>
DbRefCount manages DbBasePtr class which in turn manages object
reference, load, write operations and ofcourse memory copy of the
database object such as B++ Index node. The layout of pointer in
DbRefCount<> class is as follows:
reference_count + DbBasePtr class
So when you copy DbAutoPtr<T>, reference_count gets incremented,
therefore there is only one copy of DbBasePtr class.
Thanks again.
- Next message: tom_usenet: "Re: What is a good idiom for handling a lazy object?"
- Previous message: jimjim: "Re: why it seems that std::list::erase() doesnt free objects in a list, if the latter holds pointers to them?"
- In reply to: Nick Hounsome: "Re: Destructor for const object"
- Next in thread: Nick Hounsome: "Re: Destructor for const object"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
