Put variables into member variables or function variables?

Discussion in 'C++' started by tjumail@gmail.com, Mar 21, 2008.

  1. Guest

    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);
    }
     
    , Mar 21, 2008
    #1
    1. Advertising

  2. Jim Langston Guest

    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, Mar 21, 2008
    #2
    1. Advertising

  3. Andy Champ Guest

    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, Mar 21, 2008
    #3
  4. Jim Langston Guest

    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
     
    Jim Langston, Mar 21, 2008
    #4
  5. Guest

    On Mar 21, 10:06 pm, "Jim Langston" <> wrote:
    > 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
    > - 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.
     
    , Mar 21, 2008
    #5
  6. Guest

    On Mar 21, 6:28 pm, 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?
    >
    > Andy- Hide quoted text -
    >
    > - Show quoted text -


    It's regulated by our company programming GL that every variable
    should be initialized after decleared.
     
    , Mar 21, 2008
    #6
  7. Andy Champ Guest

    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, Mar 21, 2008
    #7
  8. Default User Guest

    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
     
    Default User, Mar 21, 2008
    #8
  9. Jim Langston Guest

    wrote:
    > On Mar 21, 10:06 pm, "Jim Langston" <> wrote:
    >> 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
    >> - 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
     
    Jim Langston, Mar 23, 2008
    #9
  10. Guest

    On Mar 23, 8:53 am, "Jim Langston" <> wrote:
    > wrote:
    > > On Mar 21, 10:06 pm, "Jim Langston" <> wrote:
    > >> 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
    > >> - 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
    > - 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.
     
    , Mar 23, 2008
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Newsgroup - Ann
    Replies:
    5
    Views:
    610
    John Carson
    Jul 30, 2003
  2. slide_o_mix
    Replies:
    0
    Views:
    424
    slide_o_mix
    Oct 15, 2003
  3. Alex
    Replies:
    0
    Views:
    393
  4. 0to60
    Replies:
    4
    Views:
    518
    jeffc
    Nov 21, 2003
  5. Immortal Nephi

    Put data member into array

    Immortal Nephi, Dec 14, 2009, in forum: C++
    Replies:
    6
    Views:
    679
    Victor Bazarov
    Dec 15, 2009
Loading...

Share This Page