Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Const Static variables set at run time and a design question.

Reply
Thread Tools

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

 
 
Jim
Guest
Posts: n/a
 
      09-29-2009
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
 
Reply With Quote
 
 
 
 
Marcel Müller
Guest
Posts: n/a
 
      09-29-2009
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
 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      09-29-2009
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
 
Reply With Quote
 
Jim
Guest
Posts: n/a
 
      09-29-2009
On Sep 29, 2:44*pm, Victor Bazarov <(E-Mail Removed)> 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 )
{
}
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      09-29-2009
Jim wrote:
> On Sep 29, 2:44 pm, Victor Bazarov <(E-Mail Removed)> 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
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      09-30-2009
On Sep 29, 12:55 pm, Jim <(E-Mail Removed)> 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
 
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
static const T vs static T const er C++ 3 04-22-2008 10:22 PM
const vector<A> vs vector<const A> vs const vector<const A> Javier C++ 2 09-04-2007 08:46 PM
const static Vs. static const Dave C++ 10 05-22-2005 10:32 PM
About static const members appearing in another static const definitions Rakesh Sinha C++ 4 01-13-2005 08:11 AM
Exact difference between 'const char *' and 'char *', also diff between 'const' and 'static' Santa C Programming 1 07-17-2003 02:10 PM



Advertisments