pasing an array pointer and storing as a class member

[stephen b]

(apologies for cross posting from the moderated group..i'm sure you
understand)

Hello, I'm passing an array into a Constructor and hoping to use it
as
a pointer and store it as a class member for future use. So far, I'm
just causing crashes, psuedo code below:
double block[8192];
foo = MyClass(block);

////

MyClass {

public:

MyClass (double *blk) {// constructor
inBlk = blk;

}

Process {
// this method will be called periodically and
// iterate over array pointed to by inBlk
// ..which causes a crash
}

private:
double *inBlk;

}

I imagine I'm doing something stupid that I just can't see at the
moment. How might one solve this? Perhaps ideally I should create
the array within MyClass but I don't really want to right now.
Thanks
for any help,
Stephen.

 

[Kenneth Porter]

I imagine I'm doing something stupid that I just can't see at the
moment. How might one solve this? Perhaps ideally I should create
the array within MyClass but I don't really want to right now.

The code looks ok, although you don't show what Process does. Is the array
on the stack or global? (Ie. is it still in scope when you mess with it?)
What's wrong with declaring it in the class? Does something else need raw
access to it? Why not use a std::vector<double>?

 

[Ron AF Greve]

Hi,

You are aware that the array is on the stack and shouldn't be accessed when
returning from the function (for instance by doing something like 'return
foo;' )?

Show the real code so we don't have to guess


Regards, Ron AF Greve

http://www.InformationSuperHighway.eu

 

[stephen b]

Show the real code so we don't have to guess

Okay here is the full code.. well I stripped out a lot of stuff that
doesn't matter and removed destructors for brevity. Hopefully I
didn't miss anything else out. FilterSynth (or Synth) objects are
created at runtime (musical notes) and last for upto 5-6 seconds.

I am using arrays instead of vector<double> because I found the
initialisation of many vector<double>s caused brief CPU spikes each
time an object is created. Arrays seemed less troublesome which is
important for real-time DSP stuff. I declare the arrays in
FilterSynth instead of Filter as other objects will need access to
them although I could always provide a pointer for access I guess..
Thanks for taking time.

class FIlterSynth : public Synth
{
public:

FilterSynth() {
filt = Filter(filtIn, filtOut);
}

virtual UInt32 NextBlock(UInt32 inNumFrames) {
// this function is called by another class.
Filter.Process(inNumFrames);
}

private:
double filtIn[8192];
double filtOut[8192];
Filter filt;

};


class Filter : public UGen
{
public:

Filter(double *inBlk, double *outBlk) {
in = inBlk;
out = outBlk;
}

void Process(UInt32 inNumFrames) {

for (UInt32 i=0; i<inNumFrames; ++i) {
// some pseudo filter code..
y0 = *(in)++ + b1 * y1 + b2 * y2;
*(out)++ = a0 * y0 + a1 * y1 + a2 * y2;
}

private:
double *in, *out;
};

curiously if I do:
Filter.Process(filtIn, FiltOut, inNumFrames);
to call:
void Process(double *in, double *out, UInt32 inNumFrames) {//etc };
and omitt
private: double *in, *out;
then all is fine.

Stephen

 

[arun.darra]

Show the real code so we don't have to guess

Okay here is the full code.. well I stripped out a lot of stuff that
doesn't matter and removed destructors for brevity. Hopefully I
didn't miss anything else out. FilterSynth (or Synth) objects are
created at runtime (musical notes) and last for upto 5-6 seconds.

I am using arrays instead of vector<double> because I found the
initialisation of many vector<double>s caused brief CPU spikes each
time an object is created. Arrays seemed less troublesome which is
important for real-time DSP stuff. I declare the arrays in
FilterSynth instead of Filter as other objects will need access to
them although I could always provide a pointer for access I guess..
Thanks for taking time.

class FIlterSynth : public Synth
{
public:

FilterSynth() {
filt = Filter(filtIn, filtOut);
}

virtual UInt32 NextBlock(UInt32 inNumFrames) {
// this function is called by another class.
Filter.Process(inNumFrames);
}

private:
double filtIn[8192];
double filtOut[8192];
Filter filt;

};

class Filter : public UGen
{
public:

Filter(double *inBlk, double *outBlk) {
in = inBlk;
out = outBlk;
}

void Process(UInt32 inNumFrames) {

for (UInt32 i=0; i<inNumFrames; ++i) {
// some pseudo filter code..
y0 = *(in)++ + b1 * y1 + b2 * y2;
*(out)++ = a0 * y0 + a1 * y1 + a2 * y2;
}

private:
double *in, *out;

};

curiously if I do:
Filter.Process(filtIn, FiltOut, inNumFrames);
to call:
void Process(double *in, double *out, UInt32 inNumFrames) {//etc };
and omitt
private: double *in, *out;
then all is fine.

Stephen

there are 2 thing that i feel are wrong in ur code:

First:
filt = Filter(filtIn, filtOut);

if u want to have a class member variable (not pointer) pls use member
wise initialization


Second i dont know how are u using

Filter.Process(inNumFrames);

class-name.function-name();

could u pls change this to

filt.Process(inNumFrames);

 

[stephen b]

there are 2 thing that i feel are wrong in ur code:

First:
filt = Filter(filtIn, filtOut);

if u want to have a class member variable (not pointer) pls use member
wise initialization

i'm not sure what you mean by member wise initialization in this
context?

Second i dont know how are u using

Filter.Process(inNumFrames);

class-name.function-name();

could u pls change this to

filt.Process(inNumFrames);

okay well spotted that was a typo.. really I am doing
filt.Process(inNumFrames);

Stephen.

 

[Guest]

i'm not sure what you mean by member wise initialization in this
context?

Instead of having a constructor like this:

FilterSynth() {
filt = Filter(filtIn, filtOut);
}

you should use an initialisation-list to initialise filt, like this:

FilterSynth() : filt(filtIn, filtOut)
}
}

 

[BobR]

stephen b wrote in message...

I am using arrays instead of vector<double> because I found the
initialisation of many vector<double>s caused brief CPU spikes each
time an object is created.

I'm curious. How did you initialize the vectors?

Arrays seemed less troublesome which is
important for real-time DSP stuff.

I think it's the opposite. :-}

I declare the arrays in
FilterSynth instead of Filter as other objects will need access to
them although I could always provide a pointer for access I guess..
Thanks for taking time.

class FIlterSynth : public Synth { public:
FilterSynth() {
filt = Filter(filtIn, filtOut);
}

If this is your class constructor, the names should match: 'FIlterSynth' vs.
'FilterSynth'.

virtual UInt32 NextBlock(UInt32 inNumFrames) {
// this function is called by another class.
Filter.Process(inNumFrames);
}

private:
double filtIn[8192];
double filtOut[8192];
Filter filt;
};

class Filter : public UGen { public:

Filter(double *inBlk, double *outBlk) {
in = inBlk;
out = outBlk;
}

This is why I'm asking about your vector inits, you should use class
initialization lists:

Filter( double *inBlk, double *outBlk )
: in( inBlk ), out( outBlk ){} // note the colon

void Process(UInt32 inNumFrames) {

for (UInt32 i=0; i<inNumFrames; ++i) {
// some pseudo filter code..
y0 = *(in)++ + b1 * y1 + b2 * y2;
*(out)++ = a0 * y0 + a1 * y1 + a2 * y2;
}

private:
double *in, *out;
};

curiously if I do:
Filter.Process(filtIn, FiltOut, inNumFrames);
to call:
void Process(double *in, double *out, UInt32 inNumFrames) {//etc };
and omitt
private: double *in, *out;
then all is fine.
Stephen

Could it be because you are dereferenceing un-initialized data (the arrays)?
Let's test something. In your FilterSynth() constructor:

FilterSynth(){
for( int i(0); i < 10; ++i ){
std::cout<< filtIn[ i ] <<'\n';
} // for(i)
} // Ctor

What's your output from that? (I got garbage (UB)).


Also, please indent your code for posting (using spaces, not tabs).

 

[stephen b]

stephen b wrote in message...


I'm curious. How did you initialize the vectors?


I think it's the opposite. :-}

really? right, I think I initialised my vectors like this:
vector<double> vec (8192, 0.); so I guess maybe filling the array
with zeros was causing some overhead. I also found arrays to be
slightly more efficient in use although it's probably negligible even
though I'll be using 20 or so per synth.

Could it be because you are dereferenceing un-initialized data (the arrays)?
Let's test something. In your FilterSynth() constructor:

FilterSynth(){
for( int i(0); i < 10; ++i ){
std::cout<< filtIn[ i ] <<'\n';
} // for(i)
} // Ctor

What's your output from that? (I got garbage (UB)).

well with the filter example I fill the array with zeros first but
otherwise just garbage.

Stephen.

 

[stephen b]

void Process(UInt32 inNumFrames) {

for (UInt32 i=0; i<inNumFrames; ++i) {
// some pseudo filter code..
y0 = *(in)++ + b1 * y1 + b2 * y2;
*(out)++ = a0 * y0 + a1 * y1 + a2 * y2;
}

private:
double *in, *out;

forgot to clarify: the reason my code is crashing is because I'm
incrementing the pointers into the arrays and calling Process
potentially hundreds of times a second. so I need to reset the
pointers to the start of the array.. if such a thing is possible? I'm
quite surprised I didn't notice that. or I could just continue
passing the pointers via the Process function.

Stephen

 

[dprody]

use [] operator

> void Process(UInt32 inNumFrames) {
>
> for (UInt32 i=0; i<inNumFrames; ++i) {
> // some pseudo filter code..
> y0 = *(in)++ + b1 * y1 + b2 * y2;
> *(out)++ = a0 * y0 + a1 * y1 + a2 * y2;
> }
>
> private:
> double *in, *out;

why are you not just using the [] operators on the arrays instead of the fancy (but confusing and ultimatly harmful) pointer arithmatic.

y0 = in + b1 * y1 + b2 * y2;

in should never change. the way you are doing it you are loosing track of the beginning of your array unless you subtract the number of loops off your pointer at the end.

Much simpler to use the [] operator and never change the value of your internal poiters after they have been initialized

 

[John Bode]

Show the real code so we don't have to guess

Okay here is the full code.. well I stripped out a lot of stuff that
doesn't matter and removed destructors for brevity. Hopefully I
didn't miss anything else out. FilterSynth (or Synth) objects are
created at runtime (musical notes) and last for upto 5-6 seconds.

I am using arrays instead of vector<double> because I found the
initialisation of many vector<double>s caused brief CPU spikes each
time an object is created. Arrays seemed less troublesome which is
important for real-time DSP stuff. I declare the arrays in
FilterSynth instead of Filter as other objects will need access to
them although I could always provide a pointer for access I guess..
Thanks for taking time.

class FIlterSynth : public Synth
{
public:

FilterSynth() {
filt = Filter(filtIn, filtOut);
}

virtual UInt32 NextBlock(UInt32 inNumFrames) {
// this function is called by another class.
Filter.Process(inNumFrames);
}

private:
double filtIn[8192];
double filtOut[8192];
Filter filt;

};

class Filter : public UGen
{
public:

Filter(double *inBlk, double *outBlk) {
in = inBlk;
out = outBlk;
}

void Process(UInt32 inNumFrames) {

for (UInt32 i=0; i<inNumFrames; ++i) {
// some pseudo filter code..
y0 = *(in)++ + b1 * y1 + b2 * y2;

^^

*(out)++ = a0 * y0 + a1 * y1 + a2 * y2;

^^^
Here's your problem. You're changing where in and out point to over
the course of the method, so that you lose track of the beginning of
each array; on the next call to Process, in and out are pointing
somewhere not meaningful, hence the crashing. Leave the values of in
and out alone, and use i as an array subscript:

y0 = in + b1 * y1 + b2 * y2;
out = a0 * y0 + a1 * y1 + a2 * y2;

You'll want to do some sanity checking to make sure that inNumFrames
never exceeds the size of your arrays.

It would probably be a good idea to make in and out const members, so
that you can't accidentally modify the pointer values.


class Filter : public UGen
{
public:

Filter(const double * const inBlk, const double * const
outBlk) :
in(inBlk),
out(outBlk)
{
}

void Process(UInt32 inNumFrames) {/* as above */}

private:
const double * const in; // neither the pointer nor the
thing
const double * const out; // pointed to can be modified
};

};

curiously if I do:
Filter.Process(filtIn, FiltOut, inNumFrames);
to call:
void Process(double *in, double *out, UInt32 inNumFrames) {//etc };
and omitt
private: double *in, *out;
then all is fine.

Or you could do that. Whichever makes more sense to you.

 

[BobR]

stephen b wrote in message...

I'm curious. How did you initialize the vectors?


I think it's the opposite. :-}

really? right, I think I initialised my vectors like this:
vector<double> vec (8192, 0.); so I guess maybe filling the array
with zeros was causing some overhead. I also found arrays to be
slightly more efficient in use although it's probably negligible even
though I'll be using 20 or so per synth.

Could it be because you are dereferenceing un-initialized data (the arrays)?
Let's test something. In your FilterSynth() constructor:

FilterSynth(){
for( int i(0); i < 10; ++i ){
std::cout<< filtIn[ i ] <<'\n';
} // for(i)
} // Ctor

What's your output from that? (I got garbage (UB)).

well with the filter example I fill the array with zeros first but
otherwise just garbage.
Stephen.

By the time you initialize your raw arrays, there should be very little
difference with std::vectors. (you don't need the '0.0' in init, it is the
default.)

Try your tests with this and see how it goes:
This compiles on my system, but of course, you'll need to modify it to use
your base classes, etc.. Just for a suggestion.

class Filter{ public:
// Filter( double *inBlk, double *outBlk ){
// in = inBlk; out = outBlk; }
Filter( std::vector<double> const &inBlk,
std::vector<double> &outBlk )
: in( inBlk.begin() ), out( outBlk.begin() ){}
// void Process(UInt32 inNumFrames) {
void Process( int inNumFrames ){
double y0(0); // for test compile
for( int i(0); i < inNumFrames; ++i){
y0 = *(in)++;
*(out)++ = y0;
} // for(i)
} // Process(int)
private:
// double *in, *out;
std::vector<double>::const_iterator in;
std::vector<double>::iterator out;
};

// If 'in' and 'out' are only used in 'Process', you may want
// a normal constructor and use the following for 'Process':
// void Process( std::vector<double> const &inBlk,
// std::vector<double> &outBlk ){ .... }
// .... and change the call below. Then you wouldn't need the
// iterators in the class (just in the function).

class FilterSynth{ public:
FilterSynth() : filtIn(8192), filtOut(8192), filt( filtIn, filtOut ){}
virtual ~FilterSynth(){} // not needed if base Dtor is virtual.
// virtual UInt32 NextBlock( UInt32 inNumFrames ){
virtual int NextBlock( int inNumFrames ){
// this function is called by another class.
filt.Process( inNumFrames );
return 0;
}
private:
std::vector<double> filtIn;
std::vector<double> filtOut;
Filter filt;
};

This is a little 'loose', but I don't know exactly the problem you are
working.
Hope that helps some.

 

[Andre Kostur]

stephen b wrote in message...
I am using arrays instead of vector<double> because I found the
initialisation of many vector<double>s caused brief CPU spikes
each time an object is created.

I'm curious. How did you initialize the vectors?

Arrays seemed less troublesome which is
important for real-time DSP stuff.

I think it's the opposite. :-}

really? right, I think I initialised my vectors like this:
vector<double> vec (8192, 0.); so I guess maybe filling the array
with zeros was causing some overhead. I also found arrays to be
slightly more efficient in use although it's probably negligible even
though I'll be using 20 or so per synth.

Could it be because you are dereferenceing un-initialized data (the arrays)?
Let's test something. In your FilterSynth() constructor:

FilterSynth(){
for( int i(0); i < 10; ++i ){
std::cout<< filtIn[ i ] <<'\n';
} // for(i)
} // Ctor

What's your output from that? (I got garbage (UB)).

well with the filter example I fill the array with zeros first but
otherwise just garbage.
Stephen.

By the time you initialize your raw arrays, there should be very
little difference with std::vectors. (you don't need the '0.0' in
init, it is the default.)

Keep in mind that std::vector has to do (Well, is very likely to do)
dynamic memory to store its contents. Arrays do not. You might try
std::tr1:array instead...

 

[BobR]

Andre Kostur wrote in message...

Keep in mind that std::vector has to do (Well, is very likely to do)
dynamic memory to store its contents. Arrays do not. You might try
std::tr1:array instead...

A valid argument. But, sticking 2+ meg in the stack might be a source of his
problem (stack overflow/corruption?).
And if you 'new' the arrays, well, I think std::vector is a good choice.

[ I don't know how C++ sets up the stack, but in assembler, it was precious
realestate. My logic is small things on stack, big things in dynamic(heap).
Feel free to inform/correct me on this point. :-}]