Lifetime of member variables in C++ object

[nagashre]

class A
{
public:
A():a(0), b(0){}

handleMyMsg( char* aa, char*bb);

private:

processMessage();
processMessage2();
char* a;
char*b;
}

Object of type A is created once and handleMyMsg is called several
times with different values for the arguments. processMessage and
processMessage2 are helper functions which needs to work on the
arguments passed to handleMyMsg.

Is it a bad idea to have member variables a and b which are
initialized witht he values of aa and bb every time handleMyMsg is
called?

In other words, is it a bad idea to have member variables which do not
have the same lifetime as the object which owns it?

[Victor Bazarov]

na******@gmail.com wrote:

class A
{
public:
A():a(0), b(0){}

handleMyMsg( char* aa, char*bb);

A return value type is missing here.

>
private:

processMessage();
processMessage2();
char* a;
char*b;
}

A semicolon is missing.

Both errors suggest you're not posting real C++ code. It is actually
preferable that you do post real code, otherwise we're not sure what
your problem is.

>
Object of type A is created once and handleMyMsg is called several
times with different values for the arguments. processMessage and
processMessage2 are helper functions which needs to work on the
arguments passed to handleMyMsg.

Is it a bad idea to have member variables a and b which are
initialized witht he values of aa and bb every time handleMyMsg is
called?

They are not initialised. They are probably assigned some values.
It's unclear _how_ it's done (since you omitted the implemetation of
the 'handleMyMsg' function).

In other words, is it a bad idea to have member variables which do not
have the same lifetime as the object which owns it?

No, it's not an inherently bad idea. It all depends on what you
need/use them for.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-11-01 21:10, na******@gmail.com wrote:

class A
{
public:
A():a(0), b(0){}

handleMyMsg( char* aa, char*bb);

private:

processMessage();
processMessage2();
char* a;
char*b;
}

Object of type A is created once and handleMyMsg is called several
times with different values for the arguments. processMessage and
processMessage2 are helper functions which needs to work on the
arguments passed to handleMyMsg.

Is it a bad idea to have member variables a and b which are
initialized witht he values of aa and bb every time handleMyMsg is
called?

Yes, it is a very bad idea. If processMessage() and processMessage2()
needs access to the arguments passed to handleMyMsg() then you should
pass them as arguments to those functions too.

In other words, is it a bad idea to have member variables which do not
have the same lifetime as the object which owns it?

That is not really what happens, lifetime is a well defined concept in
C++ and does not mean what you are thinking of.

--
Erik Wikström

[Tadeusz Kopec]

na******@gmail.com wrote:

class A
{
public:
A():a(0), b(0){}

handleMyMsg( char* aa, char*bb);

private:

processMessage();
processMessage2();
char* a;
char*b;
}

Object of type A is created once and handleMyMsg is called several
times with different values for the arguments. processMessage and
processMessage2 are helper functions which needs to work on the
arguments passed to handleMyMsg.

Is it a bad idea to have member variables a and b which are
initialized witht he values of aa and bb every time handleMyMsg is
called?

In other words, is it a bad idea to have member variables which do not
have the same lifetime as the object which owns it?

Your member variables are pointers and their lifetime is the same as the
lifetime of the object which owns them. In function handleMyMsg you
simply assign them new values which has nothing to do with their lifetime.
But if their values are used only during the execution of handleMyMsg
then it's a design flaw to keep them as members. Just pass them to the
helper functions.

--
Tadeusz B. Kopec (tk****@NOSPAMPLEASElife.pl)

First rule of optimization: Don't do it.
Second rule of optimization (advanced): Don't do it yet.