«

I modify my code into following sample code.
CTest is a class only constructed once when the device power on.
CTest::ExecuteRunState is a function entered periodically.
Do you think whether it is necessary to put the local variables into
class private members?
Otherwise, each time entering the ExecuteRunState(), those local
variables will be decleared and initionalized one time. It's a waste
of cpu resource.


class CTest
{
public:
CTest();
~CTest();

private:
void CTest(const CTest & m_CTest);
void ExecuteRunState(); //This function will entered periodically
};


void CTest::ExecuteRunState()
{

tMV measurement = 0;
tMVq quality = 0;
tMVt timeStamp = 0;

//Here those three variables will gain the newest values.
pData->GetNewestValue(&measurement, &quality, &timeStamp);
CalFreq(&measurement);
}

wrote:
> I modify my code into following sample code.
> CTest is a class only constructed once when the device power on.
> CTest::ExecuteRunState is a function entered periodically.
> Do you think whether it is necessary to put the local variables into
> class private members?
> Otherwise, each time entering the ExecuteRunState(), those local
> variables will be decleared and initionalized one time. It's a waste
> of cpu resource.
>
>
> class CTest
> {
> public:
> CTest();
> ~CTest();
>
> private:
> void CTest(const CTest & m_CTest);
> void ExecuteRunState(); //This function will entered periodically
> };
>
>
> void CTest::ExecuteRunState()
> {
>
> tMV measurement = 0;
> tMVq quality = 0;
> tMVt timeStamp = 0;
>
> //Here those three variables will gain the newest values.
> pData->GetNewestValue(&measurement, &quality, &timeStamp);
> CalFreq(&measurement);
> }

I don't think it's really necessary and is probably premature optimization
to do so. Global variables are generally frowned upon. If the variables
are only used inside the funciton ExecuteRunState, then that's where they
should be declared. Of course this presumes that tMV, tMVq and tMVt have
rather trivial constructors.


--
Jim Langston

Jim Langston wrote:
> wrote:
>> I modify my code into following sample code.
>> CTest is a class only constructed once when the device power on.
>> CTest::ExecuteRunState is a function entered periodically.
>> Do you think whether it is necessary to put the local variables into
>> class private members?
>> Otherwise, each time entering the ExecuteRunState(), those local
>> variables will be decleared and initionalized one time. It's a waste
>> of cpu resource.
>>
>>
>> class CTest
>> {
>> public:
>> CTest();
>> ~CTest();
>>
>> private:
>> void CTest(const CTest & m_CTest);
>> void ExecuteRunState(); //This function will entered periodically
>> };
>>
>>
>> void CTest::ExecuteRunState()
>> {
>>
>> tMV measurement = 0;
>> tMVq quality = 0;
>> tMVt timeStamp = 0;
>>
>> //Here those three variables will gain the newest values.
>> pData->GetNewestValue(&measurement, &quality, &timeStamp);
>> CalFreq(&measurement);
>> }
>
> I don't think it's really necessary and is probably premature optimization
> to do so. Global variables are generally frowned upon. If the variables
> are only used inside the funciton ExecuteRunState, then that's where they
> should be declared. Of course this presumes that tMV, tMVq and tMVt have
> rather trivial constructors.
>
>

Given the concern on performance, and that GetNewestValue obviously
writes to them, why initialise them at all?

Andy

Andy Champ wrote:
> Jim Langston wrote:
>> wrote:
>>> I modify my code into following sample code.
>>> CTest is a class only constructed once when the device power on.
>>> CTest::ExecuteRunState is a function entered periodically.
>>> Do you think whether it is necessary to put the local variables into
>>> class private members?
>>> Otherwise, each time entering the ExecuteRunState(), those local
>>> variables will be decleared and initionalized one time. It's a waste
>>> of cpu resource.
>>>
>>>
>>> class CTest
>>> {
>>> public:
>>> CTest();
>>> ~CTest();
>>>
>>> private:
>>> void CTest(const CTest & m_CTest);
>>> void ExecuteRunState(); //This function will entered
>>> periodically };
>>>
>>>
>>> void CTest::ExecuteRunState()
>>> {
>>>
>>> tMV measurement = 0;
>>> tMVq quality = 0;
>>> tMVt timeStamp = 0;
>>>
>>> //Here those three variables will gain the newest values.
>>> pData->GetNewestValue(&measurement, &quality, &timeStamp);
>>> CalFreq(&measurement);
>>> }
>>
>> I don't think it's really necessary and is probably premature
>> optimization to do so. Global variables are generally frowned upon.
>> If the variables are only used inside the funciton ExecuteRunState,
>> then that's where they should be declared. Of course this presumes
>> that tMV, tMVq and tMVt have rather trivial constructors.
>>
>>
>
> Given the concern on performance, and that GetNewestValue obviously
> writes to them, why initialise them at all?

It is not necesarry to initialize them, but if they are classes or
structures they can have constructors anyway. For the given examples here
they are most likely trivial (int, float, etc..). But maybe tMV is some
class that when it is constructed reads data from a database for whatever
reason, then it is not trivial.

Just becasue you don't initialize a variable doesn't mean it doesn't have to
be constructed.

--
Jim Langston

On Mar 21, 10:06*pm, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> Andy Champ wrote:
> > Jim Langston wrote:
> >> tjum...@gmail.com wrote:
> >>> I modify my code into following sample code.
> >>> CTest is a class only constructed once when the device power on.
> >>> CTest::ExecuteRunState is a function entered *periodically.
> >>> Do you think whether it is necessary to put the local variables into
> >>> class private members?
> >>> Otherwise, each time entering the ExecuteRunState(), those local
> >>> variables will be decleared and initionalized one time. It's a waste
> >>> of cpu resource.
>
> >>> class CTest
> >>> *{
> >>> *public:
> >>> * *CTest();
> >>> * *~CTest();
>
> >>> *private:
> >>> * * void CTest(const CTest & m_CTest);
> >>> * * void ExecuteRunState(); //This function will entered
> >>> *periodically };
>
> >>> void CTest::ExecuteRunState()
> >>> {
>
> >>> tMV *measurement = 0;
> >>> tMVq quality = 0;
> >>> tMVt timeStamp = 0;
>
> >>> //Here those three variables will gain the newest values.
> >>> pData->GetNewestValue(&measurement, &quality, &timeStamp);
> >>> CalFreq(&measurement);
> >>> }
>
> >> I don't think it's really necessary and is probably premature
> >> optimization to do so. *Global variables are generally frowned upon.
> >> If the variables are only used inside the funciton ExecuteRunState,
> >> then that's where they should be declared. *Of course this presumes
> >> that tMV, tMVq and tMVt have rather trivial constructors.
>
> > Given the concern on performance, and that GetNewestValue obviously
> > writes to them, why initialise them at all?
>
> It is not necesarry to initialize them, but if they are classes or
> structures they can have constructors anyway. *For the given examples here
> they are most likely trivial (int, float, etc..). *But maybe tMV is some
> class that when it is constructed reads data from a database for whatever
> reason, then it is not trivial.
>
> Just becasue you don't initialize a variable doesn't mean it doesn't have to
> be constructed.
>
> --
> Jim Langston
> tazmas...@rocketmail.com- Hide quoted text -
>
> - Show quoted text -

Thanks for your reply

In this example tMV is actually not a trivial class and I just give an
initialize example and with 0.
The problem is these three classes will constructed each time
ExecuteRunState() is periodically entered.
And I intend to put these three classes initialization into CTest
class constructor.
In this way, I also have to update UML class diagram to add these
three attributes.

On Mar 21, 6:28*pm, Andy Champ <no....@nospam.com> wrote:
> Jim Langston wrote:
> > tjum...@gmail.com wrote:
> >> I modify my code into following sample code.
> >> CTest is a class only constructed once when the device power on.
> >> CTest::ExecuteRunState is a function entered *periodically.
> >> Do you think whether it is necessary to put the local variables into
> >> class private members?
> >> Otherwise, each time entering the ExecuteRunState(), those local
> >> variables will be decleared and initionalized one time. It's a waste
> >> of cpu resource.
>
> >> class CTest
> >> *{
> >> *public:
> >> * *CTest();
> >> * *~CTest();
>
> >> *private:
> >> * * void CTest(const CTest & m_CTest);
> >> * * void ExecuteRunState(); //This function will entered periodically
> >> *};
>
> >> void CTest::ExecuteRunState()
> >> {
>
> >> tMV *measurement = 0;
> >> tMVq quality = 0;
> >> tMVt timeStamp = 0;
>
> >> //Here those three variables will gain the newest values.
> >> pData->GetNewestValue(&measurement, &quality, &timeStamp);
> >> CalFreq(&measurement);
> >> }
>
> > I don't think it's really necessary and is probably premature optimization
> > to do so. *Global variables are generally frowned upon. *If the variables
> > are only used inside the funciton ExecuteRunState, then that's where they
> > should be declared. *Of course this presumes that tMV, tMVq and tMVt have
> > rather trivial constructors.
>
> Given the concern on performance, and that GetNewestValue obviously
> writes to them, why initialise them at all?
>
> Andy- Hide quoted text -
>
> - Show quoted text -

It's regulated by our company programming GL that every variable
should be initialized after decleared.

wrote:
>
> It's regulated by our company programming GL that every variable
> should be initialized after decleared.

I like your other reply better

Regulations (GL == Guidlines?) are there to be broken - when you have
good reason.

Andy

Andy Champ wrote:

> wrote:
> >
> > It's regulated by our company programming GL that every variable
> > should be initialized after decleared.
>
> I like your other reply better
>
> Regulations (GL == Guidlines?) are there to be broken - when you have
> good reason.

Guidelines are, that's why they are guidelines. Rules aren't. When I
worked making deliverable software, code that violated a rule in a
Coding Standard did not pass peer review, and would be noted in a
defect that would have to be cleared by the programmer. Regardless of
how "good" the programmer felt the reason was.

Of course, I work R&D these days, and most code is prototype only.






Brian

wrote:
> On Mar 21, 10:06 pm, "Jim Langston" <tazmas...@rocketmail.com> wrote:
>> Andy Champ wrote:
>>> Jim Langston wrote:
>>>> tjum...@gmail.com wrote:
>>>>> I modify my code into following sample code.
>>>>> CTest is a class only constructed once when the device power on.
>>>>> CTest::ExecuteRunState is a function entered periodically.
>>>>> Do you think whether it is necessary to put the local variables
>>>>> into class private members?
>>>>> Otherwise, each time entering the ExecuteRunState(), those local
>>>>> variables will be decleared and initionalized one time. It's a
>>>>> waste of cpu resource.
>>
>>>>> class CTest
>>>>> {
>>>>> public:
>>>>> CTest();
>>>>> ~CTest();
>>
>>>>> private:
>>>>> void CTest(const CTest & m_CTest);
>>>>> void ExecuteRunState(); //This function will entered
>>>>> periodically };
>>
>>>>> void CTest::ExecuteRunState()
>>>>> {
>>
>>>>> tMV measurement = 0;
>>>>> tMVq quality = 0;
>>>>> tMVt timeStamp = 0;
>>
>>>>> //Here those three variables will gain the newest values.
>>>>> pData->GetNewestValue(&measurement, &quality, &timeStamp);
>>>>> CalFreq(&measurement);
>>>>> }
>>
>>>> I don't think it's really necessary and is probably premature
>>>> optimization to do so. Global variables are generally frowned upon.
>>>> If the variables are only used inside the funciton ExecuteRunState,
>>>> then that's where they should be declared. Of course this presumes
>>>> that tMV, tMVq and tMVt have rather trivial constructors.
>>
>>> Given the concern on performance, and that GetNewestValue obviously
>>> writes to them, why initialise them at all?
>>
>> It is not necesarry to initialize them, but if they are classes or
>> structures they can have constructors anyway. For the given examples
>> here they are most likely trivial (int, float, etc..). But maybe tMV
>> is some class that when it is constructed reads data from a database
>> for whatever reason, then it is not trivial.
>>
>> Just becasue you don't initialize a variable doesn't mean it doesn't
>> have to be constructed.
>>
>> --
>> Jim Langston
>> tazmas...@rocketmail.com- Hide quoted text -
>>
>> - Show quoted text -
>
> Thanks for your reply
>
> In this example tMV is actually not a trivial class and I just give an
> initialize example and with 0.
> The problem is these three classes will constructed each time
> ExecuteRunState() is periodically entered.
> And I intend to put these three classes initialization into CTest
> class constructor.
> In this way, I also have to update UML class diagram to add these
> three attributes.

Okay, then the question is, can you use tMV without initialiing it each
time? Does it contain data that has to be reset each time? Or can it be
used without initialization? If it has to be reset each time, then you will
need to construct it each time (easiest method). If you will be able to use
it without initialization, then you can either make it part of the class
itself or, what I would probalby do, make it static.

void CTest::ExecuteRunState()
{
static tMV measurement = 0;
static tMVq quality = 0;
static tMVt timeStamp = 0;
//Here those three variables will gain the newest values.
pData->GetNewestValue(&measurement, &quality, &timeStamp);
CalFreq(&measurement);
}

The problem with static, which is the same as making it part of the class,
is it's only going to be initialized once. It will retain it's state
between calls to ExecuteRunState. If GetNewestValue sets the class to a
usuable state reguardless if it's initialized or not, then that might work
for you. Of course, I would only do this if the construction time of tMV,
tMVq and tMVt was large enough to actually slow down my program. The only
way to find this out is by testing. Without testing it's premature
optimization.

Of course, with my example of the class initialized by a database, it's
pretty much known that it's going to slow down the operation becasue of
waiting for the connection to the database server, reading, etc...

Personally, I would prefer them to be static over class variables since they
are only used in one function, but others may have other opionions.

--
Jim Langston

On Mar 23, 8:53*am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> tjum...@gmail.com wrote:
> > On Mar 21, 10:06 pm, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> >> Andy Champ wrote:
> >>> Jim Langston wrote:
> >>>> tjum...@gmail.com wrote:
> >>>>> I modify my code into following sample code.
> >>>>> CTest is a class only constructed once when the device power on.
> >>>>> CTest::ExecuteRunState is a function entered periodically.
> >>>>> Do you think whether it is necessary to put the local variables
> >>>>> into class private members?
> >>>>> Otherwise, each time entering the ExecuteRunState(), those local
> >>>>> variables will be decleared and initionalized one time. It's a
> >>>>> waste of cpu resource.
>
> >>>>> class CTest
> >>>>> {
> >>>>> public:
> >>>>> CTest();
> >>>>> ~CTest();
>
> >>>>> private:
> >>>>> void CTest(const CTest & m_CTest);
> >>>>> void ExecuteRunState(); //This function will entered
> >>>>> periodically };
>
> >>>>> void CTest::ExecuteRunState()
> >>>>> {
>
> >>>>> tMV measurement = 0;
> >>>>> tMVq quality = 0;
> >>>>> tMVt timeStamp = 0;
>
> >>>>> //Here those three variables will gain the newest values.
> >>>>> pData->GetNewestValue(&measurement, &quality, &timeStamp);
> >>>>> CalFreq(&measurement);
> >>>>> }
>
> >>>> I don't think it's really necessary and is probably premature
> >>>> optimization to do so. Global variables are generally frowned upon.
> >>>> If the variables are only used inside the funciton ExecuteRunState,
> >>>> then that's where they should be declared. Of course this presumes
> >>>> that tMV, tMVq and tMVt have rather trivial constructors.
>
> >>> Given the concern on performance, and that GetNewestValue obviously
> >>> writes to them, why initialise them at all?
>
> >> It is not necesarry to initialize them, but if they are classes or
> >> structures they can have constructors anyway. For the given examples
> >> here they are most likely trivial (int, float, etc..). But maybe tMV
> >> is some class that when it is constructed reads data from a database
> >> for whatever reason, then it is not trivial.
>
> >> Just becasue you don't initialize a variable doesn't mean it doesn't
> >> have to be constructed.
>
> >> --
> >> Jim Langston
> >> tazmas...@rocketmail.com- Hide quoted text -
>
> >> - Show quoted text -
>
> > Thanks for your reply
>
> > In this example tMV is actually not a trivial class and I just give an
> > initialize example and with 0.
> > The problem is these three classes will constructed each time
> > ExecuteRunState() is periodically entered.
> > And I intend to put these three classes initialization into CTest
> > class constructor.
> > In this way, I also have to update UML class diagram to add these
> > three attributes.
>
> Okay, then the question is, can you use tMV without initialiing it each
> time? *Does it contain data that has to be reset each time? *Or can it be
> used without initialization? *If it has to be reset each time, then you will
> need to construct it each time (easiest method). *If you will be able to use
> it without initialization, then you can either make it part of the class
> itself or, what I would probalby do, make it static.
>
> void CTest::ExecuteRunState()
> {
> * static tMV measurement = 0;
> * static tMVq quality = 0;
> * static tMVt timeStamp = 0;
> * //Here those three variables will gain the newest values.
> * pData->GetNewestValue(&measurement, &quality, &timeStamp);
> * CalFreq(&measurement);
>
> }
>
> The problem with static, which is the same as making it part of the class,
> is it's only going to be initialized once. *It will retain it's state
> between calls to ExecuteRunState. *If GetNewestValue sets the class to a
> usuable state reguardless if it's initialized or not, then that might work
> for you. *Of course, I would only do this if the construction time of tMV,
> tMVq and tMVt was large enough to actually slow down my program. *The only
> way to find this out is by testing. *Without testing it's premature
> optimization.
>
> Of course, with my example of the class initialized by a database, it's
> pretty much known that it's going to slow down the operation becasue of
> waiting for the connection to the database server, reading, etc...
>
> Personally, I would prefer them to be static over class variables since they
> are only used in one function, but others may have other opionions.
>
> --
> Jim Langston
> tazmas...@rocketmail.com- Hide quoted text -
>
> - Show quoted text -

Thanks a lot!
I'm also prefer your solution of to be static.
It sounds very good.
I will test this code when my code go to Test Phase.