Destructor for const object

[Virendra Verma]

This sounds weird, but I am looking for separate behaviors for
destruction of a const and non-const object.

I am trying to develop a smart/auto pointer class for writing objects
to disk implicitly. The destructor of this class saves the object to
the disk if it is dirty. The problem comes in the following scenario
when a function returns an uncommitted pointer class because same
copies will be committed as two separate objects on disk. For example,

DbPtr< T > some_function( )
{
.....
DbPtr<T> pN; // uncommitted copy
return pN; // pN will be committed in the destructor but the
returned
// copy is not. I could define an assignment operator
// for DbPtr<T> as below but the commit operation
// on const object has problems as it has to modifies
// object
}

tempalte<class T>
class DbPtr : public some_base {
public:
~DbPtr<T>( ) { commit(); } // I need to recognize here if I am
destroying
// a const object to bypass commit.
void commit( );
void operator=( const DbPtr<T>& rP ) { *this = rP; }
void operator=( DbPtr<T>& rP ) { rP.commit(); *this = rP; }
}

Thanks in advance.
-- Virendr

[Kevin Goodsell]

Re: Destructor for const object

Virendra Verma wrote:
[color=blue]
> This sounds weird, but I am looking for separate behaviors for
> destruction of a const and non-const object.
>
> I am trying to develop a smart/auto pointer class for writing objects
> to disk implicitly. The destructor of this class saves the object to
> the disk if it is dirty.[/color]

I don't see what 'const' has to do with this.
[color=blue]
> The problem comes in the following scenario
> when a function returns an uncommitted pointer class because same
> copies will be committed as two separate objects on disk. For example,
>
> DbPtr< T > some_function( )
> {
> .....
> DbPtr<T> pN; // uncommitted copy
> return pN; // pN will be committed in the destructor but the
> returned
> // copy is not. I could define an assignment operator
> // for DbPtr<T> as below but the commit operation
> // on const object has problems as it has to modifies
> // object
> }
>
> tempalte<class T>
> class DbPtr : public some_base {
> public:
> ~DbPtr<T>( ) { commit(); } // I need to recognize here if I am
> destroying
> // a const object to bypass commit.[/color]

You seem to have a lot of <T> that I'm pretty sure you don't need.

Again, 'const' does not seem relevant. Your example doesn't include any
'const' objects, and this approach (if it was possible) does not seem
likely to solve your problem.
[color=blue]
> void commit( );[/color]

"Commit" is probably a non-modifying operation, so this should be

void commit() const;

Yes, you should do this even if it has to modify members of the object.
As long as the observable state of the object does not change (that is,
users of the class can't see a difference), the operation should be
const. Use 'mutable' members if you need to. This is why they exist.
[color=blue]
> void operator=( const DbPtr<T>& rP ) { *this = rP; }
> void operator=( DbPtr<T>& rP ) { rP.commit(); *this = rP; }[/color]

I also don't understand what you hope to accomplish with the assignment
operators. Your example doesn't use them, either. And it looks like they
will infinitely recurse.
[color=blue]
> }
>[/color]

It sounds like you want to commit when the final copy is destroyed
(maybe -- it's not completely clear). In that case, you probably want a
reference-counting scheme. const objects have nothing to do with it, and
assignment operators are only related in the sense that they need to
update reference counts, and generally perform some action when a
reference count reaches 0.

Or maybe you want a 'commit_on_dest roy' flag in your class. When an
instance is copied, you could set it in one copy and clear it in the
other. But you have to remember to do this in the assignment operator
*and* the copy constructor.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[tom_usenet]

Re: Destructor for const object

On 12 Apr 2004 08:35:33 -0700, virenbeena@hotm ail.com (Virendra Verma)
wrote:
[color=blue]
>This sounds weird, but I am looking for separate behaviors for
>destruction of a const and non-const object.
>
>I am trying to develop a smart/auto pointer class for writing objects
>to disk implicitly. The destructor of this class saves the object to
>the disk if it is dirty. The problem comes in the following scenario
>when a function returns an uncommitted pointer class because same
>copies will be committed as two separate objects on disk. For example,
>
>DbPtr< T > some_function( )
>{
> .....
> DbPtr<T> pN; // uncommitted copy
> return pN; // pN will be committed in the destructor but the
>returned
> // copy is not. I could define an assignment operator
> // for DbPtr<T> as below but the commit operation
> // on const object has problems as it has to modifies
> // object
>}[/color]

There are no const objects in the example above. Do you mean temporary
objects? Presumably the commit only happens when the last reference
goes out of scope?
[color=blue]
>
>tempalte<cla ss T>
>class DbPtr : public some_base {
>public:
> ~DbPtr<T>( ) { commit(); } // I need to recognize here if I am
>destroying
> // a const object to bypass commit.[/color]

Do you mean whether you are destroying the last reference to an
object? Just use reference counting...
[color=blue]
> void commit( );
> void operator=( const DbPtr<T>& rP ) { *this = rP; }
> void operator=( DbPtr<T>& rP ) { rP.commit(); *this = rP; }
>}
>
>Thanks in advance.[/color]

If you need different behaviour for const DbPtrs, create a partial
specialization:

template <class T>
class DbPtr<T const> : public some_base
{
//specialization for const
};

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Nick Hounsome]

Re: Destructor for const object


"Virendra Verma" <virenbeena@hot mail.com> wrote in message
news:30ee7e04.0 404120735.15a90 573@posting.goo gle.com...[color=blue]
> This sounds weird, but I am looking for separate behaviors for
> destruction of a const and non-const object.
>
> I am trying to develop a smart/auto pointer class for writing objects
> to disk implicitly. The destructor of this class saves the object to
> the disk if it is dirty. The problem comes in the following scenario
> when a function returns an uncommitted pointer class because same
> copies will be committed as two separate objects on disk. For example,
>
> DbPtr< T > some_function( )
> {
> .....
> DbPtr<T> pN; // uncommitted copy
> return pN; // pN will be committed in the destructor but the
> returned
> // copy is not. I could define an assignment operator
> // for DbPtr<T> as below but the commit operation
> // on const object has problems as it has to modifies
> // object
> }
>
> tempalte<class T>
> class DbPtr : public some_base {
> public:
> ~DbPtr<T>( ) { commit(); } // I need to recognize here if I am
> destroying
> // a const object to bypass commit.
> void commit( );
> void operator=( const DbPtr<T>& rP ) { *this = rP; }
> void operator=( DbPtr<T>& rP ) { rP.commit(); *this = rP; }
> }
>
> Thanks in advance.
> -- Virendr[/color]

I don't see what you are trying to do with DbPtr but I suspect that you
should be using a reference counting smart pointer to a real class.
These can be passed around as in your function example without commiting.
When the reference count reaches 0 the smart pointer commits the object it
points to and then
deletes it.
One advantage of separating the commit from the object itself is that you
can then use the object
both inside and outside the database.
Another approach that will work better with exceptions is a separate
transaction class .