Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Kamikaze Object

Reply
Thread Tools

Kamikaze Object

 
 
atomik.fungus@gmail.com
Guest
Posts: n/a
 
      08-15-2006
Hi
I've made a kamikaze function wrapper that executes the function(s)
when its constructor is called and ends calling its own destructor. I
thought originally of this as a good idea to avoid some typing but
after watching things that I didnt thought would compile i am starting
to doubt.
The original idea for doing so was that once function-objects have done
their job they are a just a waste of memory space.
This is the creature:

#include <iostream>

using std::cout;

class foo {
public:
foo( int num ) { this->operator()( num ); (*this).~foo();
}
private:
void operator()( int &val ) { val += 1; cout << val; }
};

int main()
{
foo funcion( 5 );
funcion.~foo(); //Strange?
funcion.~foo();

return 0;
}

This compiles, although i dont understand why it lets me call 3 times
the same destructor for the same
object.
Other solutions that i come out with for destroying function objects
are:

1.- wrapping the wrapper in a function and declarate it locally inside.
My main goal of hiding the functions on which the "main" function
dependes is kept untouched.
2.- declaring the object locally inside a loop that executes once. This
makes the code look strange.
3.- using a pointer to the object and then new and delete. But im still
left with a useless pointer.

I would really appreciate any advice.

 
Reply With Quote
 
 
 
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      08-15-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> Hi
> I've made a kamikaze function wrapper that executes the function(s)
> when its constructor is called and ends calling its own destructor. I
> thought originally of this as a good idea to avoid some typing but
> after watching things that I didnt thought would compile i am starting
> to doubt.
> The original idea for doing so was that once function-objects have done
> their job they are a just a waste of memory space.


Note that calling the destructor of an object does not relate in any way to
the memory consumption of that object. It just ends the lifetime. The
memory will afterwards be occupied by the dead body of the object until you
explicitly resue it. If you don't and the dead object goes out of scope,
the destructor is implicitly called a second time and you have undefined
behavior.

> This is the creature:
>
> #include <iostream>
>
> using std::cout;
>
> class foo {
> public:
> foo( int num ) { this->operator()( num ); (*this).~foo();
> }
> private:
> void operator()( int &val ) { val += 1; cout << val; }
> };
>
> int main()
> {
> foo funcion( 5 );
> funcion.~foo(); //Strange?
> funcion.~foo();
>
> return 0;


At the return statement, there is a 4th invocation of the destructor.

> }
>
> This compiles, although i dont understand why it lets me call 3 times
> the same destructor for the same
> object.


You have undefined behavior. No diagnostics is required: that is why it
compiles.


> Other solutions that i come out with for destroying function objects
> are:
>
> 1.- wrapping the wrapper in a function and declarate it locally inside.
> My main goal of hiding the functions on which the "main" function
> dependes is kept untouched.
> 2.- declaring the object locally inside a loop that executes once. This
> makes the code look strange.
> 3.- using a pointer to the object and then new and delete. But im still
> left with a useless pointer.


Why are you using a function object instead of a function in the first
place?


> I would really appreciate any advice.


Just use a function. If you have a need for a function object, e.g., because
you want something stateful that collects data within a for_each() loop,
then a kamikaze object won't be useful anyway.


Best

Kai-Uwe Bux
 
Reply With Quote
 
 
 
 
Pierre Barbier de Reuille
Guest
Posts: n/a
 
      08-15-2006
(E-Mail Removed) wrote:
> Hi
> I've made a kamikaze function wrapper that executes the function(s)
> when its constructor is called and ends calling its own destructor. I
> thought originally of this as a good idea to avoid some typing but
> after watching things that I didnt thought would compile i am starting
> to doubt.
> The original idea for doing so was that once function-objects have done
> their job they are a just a waste of memory space.
> This is the creature:
>
> #include <iostream>
>
> using std::cout;
>
> class foo {
> public:
> foo( int num ) { this->operator()( num ); (*this).~foo();
> }
> private:
> void operator()( int &val ) { val += 1; cout << val; }
> };
>
> int main()
> {
> foo funcion( 5 );
> funcion.~foo(); //Strange?
> funcion.~foo();
>
> return 0;
> }
>
> This compiles, although i dont understand why it lets me call 3 times
> the same destructor for the same
> object.
> Other solutions that i come out with for destroying function objects
> are:
>
> 1.- wrapping the wrapper in a function and declarate it locally inside.
> My main goal of hiding the functions on which the "main" function
> dependes is kept untouched.
> 2.- declaring the object locally inside a loop that executes once. This
> makes the code look strange.
> 3.- using a pointer to the object and then new and delete. But im still
> left with a useless pointer.
>
> I would really appreciate any advice.
>


Well, why not simply:

foo(2)(5);

??? foo(2) creates a temporary object that will be discarded as soon as
the expression evaluation is finished ...

Pierre
 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      08-15-2006
(E-Mail Removed) wrote:

> Hi
> I've made a kamikaze function wrapper that executes the function(s)
> when its constructor is called and ends calling its own destructor.


This is never a good idea. The destructor is called automatically when the
object is destoryed.

> I thought originally of this as a good idea to avoid some typing but
> after watching things that I didnt thought would compile i am starting
> to doubt.
> The original idea for doing so was that once function-objects have done
> their job they are a just a waste of memory space.


Usually, they take up a very small portion of memory, if any at all. Also,
calling the destructor won't free their memory.

> This is the creature:
>
> #include <iostream>
>
> using std::cout;
>
> class foo {
> public:
> foo( int num ) { this->operator()( num ); (*this).~foo();
> }
> private:
> void operator()( int &val ) { val += 1; cout << val; }
> };


The size of an objects of this class is on most compilers 1 byte. After
optimization, it's quite possible that it's reduced to 0 bytes.

>
> int main()
> {
> foo funcion( 5 );
> funcion.~foo(); //Strange?
> funcion.~foo();
>
> return 0;
> }


How about just:

int main()
{
foo(5);
}

You get a temporary that is constructed (which will call your operator()),
then immediately afterwards destoryed.

> This compiles, although i dont understand why it lets me call 3 times
> the same destructor for the same object.


The compiler doesn't care. And actually, the destructor is called again when
main() reaches its end. Technically, calling the destructor multiple times
results in undefined behavior, so don't ever do it.

> Other solutions that i come out with for destroying function objects
> are:
>
> 1.- wrapping the wrapper in a function and declarate it locally inside.
> My main goal of hiding the functions on which the "main" function
> dependes is kept untouched.
> 2.- declaring the object locally inside a loop that executes once. This
> makes the code look strange.


You don't need a loop to make a code block.

> 3.- using a pointer to the object and then new and delete. But im still
> left with a useless pointer.
>
> I would really appreciate any advice.


I think you spend way too much time on thinking about how to remove an
overhead that is somewhere between negligible and non-existent.

 
Reply With Quote
 
Heinz Ozwirk
Guest
Posts: n/a
 
      08-15-2006
<(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed) ps.com...
> Hi
> I've made a kamikaze function wrapper that executes the function(s)
> when its constructor is called and ends calling its own destructor. I
> thought originally of this as a good idea to avoid some typing but
> after watching things that I didnt thought would compile i am starting
> to doubt.
> The original idea for doing so was that once function-objects have done
> their job they are a just a waste of memory space.
> This is the creature:
>
> #include <iostream>
>
> using std::cout;
>
> class foo {
> public:
> foo( int num ) { this->operator()( num ); (*this).~foo();
> }
> private:
> void operator()( int &val ) { val += 1; cout << val; }
> };
>
> int main()
> {
> foo funcion( 5 );
> funcion.~foo(); //Strange?
> funcion.~foo();
>
> return 0;
> }
>
> This compiles, although i dont understand why it lets me call 3 times
> the same destructor for the same
> object.


Actually the destructor is called 4 times -- first with (*this).~foo() in
the constructor, then twice explictly in main and finally it is
automatically called when execution leaves the scope of 'function', that is
at the end of main.

Explicitly calling a destructor is rarely a good idea. If you implement your
own memory management for some container, it might be usefull, but in
every-day programming you should better forget about it.

If you want your function objects to be destroyed once they are no longer
used, you have two simple methods to do so:

1. Enclose the desired scope in braces, in your example

int main()
{
...
{ foo function(5); }
...
}

2. Use a temporary, anonymous object

int main()
{
...
foo(5);
...
}

Whatever you do, do not call the destructor explicitly, especially not in a
constructor.

> Other solutions that i come out with for destroying function objects
> are:
>
> 1.- wrapping the wrapper in a function and declarate it locally inside.
> My main goal of hiding the functions on which the "main" function
> dependes is kept untouched.


And how do you wrap the wrapper of the wrapper?

> 2.- declaring the object locally inside a loop that executes once. This
> makes the code look strange.


Solution 1 above does the same without the loop.

> 3.- using a pointer to the object and then new and delete. But im still
> left with a useless pointer.


Don't use pointers, unless there is good reason to do so.

> I would really appreciate any advice.


Create a simple wrapper and let its user decide how long an instance of that
class should exist. If the users thinks, the wrapper should live beyond the
scope of a function, he can use new/delete; if he doesn't care how long it
keeps its data, he can define it at function level; and if he likes, he can
open a narrower scope or use a temporary object as described above.

HTH
Heinz

 
Reply With Quote
 
atomik.fungus@gmail.com
Guest
Posts: n/a
 
      08-15-2006
Thanks for ilustrating me the basics of anonymous objects. I'll fetch
some more info on the net.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Object creation - Do we really need to create a parent for a derieved object - can't the base object just point to an already created base object jon wayne C++ 9 09-22-2005 02:06 AM
Error:Object reference not set to an instance of an object. Suresh Kojhani ASP .Net 1 07-29-2004 12:10 PM
Error !Object reference not set to an instance of an object. !!! Help Parthiv Joshi ASP .Net 2 07-02-2004 10:28 AM
Object reference not set to an instance of an object. yysiow ASP .Net 1 07-12-2003 03:30 PM
Object reference not set to an instance of an object. Chris Fink ASP .Net 2 07-03-2003 06:48 PM



Advertisments