Const Static variables set at run time and a design question.

Discussion in 'C++' started by Jim, Sep 29, 2009.

  1. Jim

    Jim Guest

    Hi,
    I've a set of data which has two spectra associated with each
    position. For each spectra you convert from an array position to a
    real value using an array offset, a delta and a velocity offset.
    These are common to all spectra of the same type and don't change
    through the program's run. Unfortunately I don't know them until I
    load the file, unless I hard code them and I don't want to do that.
    Only solution I can think of is to have a user-defined object called
    conversion which has const members set in the constructor and const
    accessor methods and have a static object in each type of the specific
    spectra classes which inherit from the spectra base class. Does this
    seem correct?

    Thanks,
    Jim
     
    Jim, Sep 29, 2009
    #1
    1. Advertising

  2. Hi,

    Jim wrote:
    > I've a set of data which has two spectra associated with each
    > position. For each spectra you convert from an array position to a
    > real value using an array offset, a delta and a velocity offset.
    > These are common to all spectra of the same type and don't change
    > through the program's run. Unfortunately I don't know them until I
    > load the file, unless I hard code them and I don't want to do that.


    so they are NOT const static because they change while the application runs.

    > Only solution I can think of is to have a user-defined object called
    > conversion which has const members set in the constructor and const
    > accessor methods and have a static object in each type of the specific
    > spectra classes which inherit from the spectra base class. Does this
    > seem correct?


    Something like that is possible. But I would keep conversion as simple
    as possible:

    struct conversion
    { double offset;
    double whatever;
    };

    class SpectraBase
    {
    public virtual const conversion& GetConversion() const = 0;
    ...
    };


    Marcel
     
    Marcel Müller, Sep 29, 2009
    #2
    1. Advertising

  3. Jim wrote:
    > I've a set of data which has two spectra associated with each
    > position. For each spectra you convert from an array position to a
    > real value using an array offset, a delta and a velocity offset.
    > These are common to all spectra of the same type and don't change
    > through the program's run. Unfortunately I don't know them until I
    > load the file, unless I hard code them and I don't want to do that.
    > Only solution I can think of is to have a user-defined object called
    > conversion which has const members set in the constructor and const
    > accessor methods and have a static object in each type of the specific
    > spectra classes which inherit from the spectra base class. Does this
    > seem correct?


    It doesn't seem /in/correct. Do you see any issue with the solution?
    If you have to have a const member, the constructor is the only place to
    initialize it. You *could* make it 'mutable' and have a special member
    function that would change it, but IME 'mutable' is dangerous because it
    breeds temptation to change the member more often than needed.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Sep 29, 2009
    #3
  4. Jim

    Jim Guest

    On Sep 29, 2:44 pm, Victor Bazarov <> wrote:
    > Jim wrote:
    > > I've a set of data which has two spectra associated with each
    > > position. For each spectra you convert from an array position to a
    > > real  value using an array offset,  a delta and a velocity offset.
    > > These are common to all spectra of the same type and don't change
    > > through the program's run. Unfortunately I don't know them until I
    > > load the file, unless I hard code them and I don't want to do that.
    > > Only solution I can think of is to have a user-defined object called
    > > conversion which has const members set in the constructor and const
    > > accessor methods and have a static object in each type of the specific
    > > spectra classes which inherit from the spectra base class. Does this
    > > seem correct?

    >
    > It doesn't seem /in/correct.  Do you see any issue with the solution?
    > If you have to have a const member, the constructor is the only place to
    > initialize it.  You *could* make it 'mutable' and have a special member
    > function that would change it, but IME 'mutable' is dangerous because it
    > breeds temptation to change the member more often than needed.
    >
    > V
    > --
    > Please remove capital 'A's when replying by e-mail
    > I do not respond to top-posted replies, please don't ask


    Seems an interesting problem, I'd have thought there would be lots of
    occasions where there are values common to all objects of a class
    which need to remain const, but aren't known until run time. Storing
    three values common to each one of 40,000 spectra seems wasteful. I
    was really wondering if there was an equivalent to the following code
    but at a class level. It's probably a design issue? In the example m_n
    is const, but not known until the object is constructed.

    class A
    {
    const int m_n;
    public:
    A();
    int get() const;
    };
    A::A( int n ) : m_n( n )
    {
    }
     
    Jim, Sep 29, 2009
    #4
  5. Jim wrote:
    > On Sep 29, 2:44 pm, Victor Bazarov <> wrote:
    >> Jim wrote:
    >>> I've a set of data which has two spectra associated with each
    >>> position. For each spectra you convert from an array position to a
    >>> real value using an array offset, a delta and a velocity offset.
    >>> These are common to all spectra of the same type and don't change
    >>> through the program's run. Unfortunately I don't know them until I
    >>> load the file, unless I hard code them and I don't want to do that.
    >>> Only solution I can think of is to have a user-defined object called
    >>> conversion which has const members set in the constructor and const
    >>> accessor methods and have a static object in each type of the specific
    >>> spectra classes which inherit from the spectra base class. Does this
    >>> seem correct?

    >> It doesn't seem /in/correct. Do you see any issue with the solution?
    >> If you have to have a const member, the constructor is the only place to
    >> initialize it. You *could* make it 'mutable' and have a special member
    >> function that would change it, but IME 'mutable' is dangerous because it
    >> breeds temptation to change the member more often than needed.
    >>
    >> V
    >> --
    >> Please remove capital 'A's when replying by e-mail
    >> I do not respond to top-posted replies, please don't ask

    >
    > Seems an interesting problem, I'd have thought there would be lots of
    > occasions where there are values common to all objects of a class
    > which need to remain const, but aren't known until run time. Storing
    > three values common to each one of 40,000 spectra seems wasteful.


    Really? 40 thousand pairs of what, 4-byte numbers? That's 320K.
    Wasteful? Maybe. But do you really need to concern yourself with
    "wasting" 320K in a modern computer with at least 1 gig of RAM?

    > I
    > was really wondering if there was an equivalent to the following code
    > but at a class level. It's probably a design issue? In the example m_n
    > is const, but not known until the object is constructed.
    >
    > class A
    > {
    > const int m_n;
    > public:
    > A();
    > int get() const;
    > };
    > A::A( int n ) : m_n( n )
    > {
    > }


    Uh... I don't understand what is holding you from using a pointer to an
    object of type 'A' as a static member of another class?

    class Spectrum123
    {
    static A* m_pA;

    Spectrum123(std::istream &is); // acquisition from a file
    };

    Spectrum123::Spectrum123(std::istream &is)
    {
    ... // do what's needed to get the spectrum read

    if (!m_pA)
    {
    int someValue = ... // calculate from the spectrum
    m_pA = new A(someValue);
    }
    }

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Sep 29, 2009
    #5
  6. Jim

    James Kanze Guest

    On Sep 29, 12:55 pm, Jim <> wrote:

    > I've a set of data which has two spectra associated with each
    > position. For each spectra you convert from an array position
    > to a real value using an array offset, a delta and a
    > velocity offset. These are common to all spectra of the same
    > type and don't change through the program's run. Unfortunately
    > I don't know them until I load the file, unless I hard code
    > them and I don't want to do that. Only solution I can think
    > of is to have a user-defined object called conversion which
    > has const members set in the constructor and const accessor
    > methods and have a static object in each type of the specific
    > spectra classes which inherit from the spectra base class.
    > Does this seem correct?


    If the data can be made available before entering main, there's
    no problem; something like:
    int configuration = getIntFromEnvironment( "CONFIGVARNAME" ) ;
    works fine. If you have to read the value from a file (whose
    name is passed in argv, for example), then it's more difficult.
    Perhaps something along the lines of:
    ConfigurationData const* configData ;
    would do the trick, with configData being set each time after
    reading the values.

    --
    James Kanze
     
    James Kanze, Sep 30, 2009
    #6
    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. Rakesh Sinha
    Replies:
    4
    Views:
    1,853
    Rakesh Sinha
    Jan 13, 2005
  2. Dave
    Replies:
    10
    Views:
    35,303
    Ron Natalie
    May 22, 2005
  3. Santa
    Replies:
    1
    Views:
    1,090
    Mark A. Odell
    Jul 17, 2003
  4. Javier
    Replies:
    2
    Views:
    567
    James Kanze
    Sep 4, 2007
  5. er
    Replies:
    3
    Views:
    385
Loading...

Share This Page