Object not retaining modified values

I have a class (DataBuffer) that has functions that return objects of DataBuffer but when I'm calling other class functions from within the function that returns the object of DataBuffer, the internal values are not being set after the function returns.

So, basically (if you made it through that first sentence), I have a function of DataBuffer that is calling a different function within DataBuffer to set some values but when it returns, the values aren't the same.

To the code!
DataBuffer.h

Code:

---

class DataException;

class DataBuffer
{
public:
  DataBuffer ();
  DataBuffer (const DataBuffer &rhs);
  DataBuffer (unsigned int width, unsigned int height, float fillValue=0.0)
      throw (DataException);

  void setDimensions (unsigned int width, unsigned int height, float fillValue=0.0)
      throw (DataException);

  DataBuffer func ();

protected:
  float **allocate (unsigned int width, unsigned int height)
      throw (DataException);
  unsigned int width;
  unsigned int height;
  float **buffer;
}

---

DataBuffer.cpp

Code:

---

DataBuffer::DataBuffer ()
  : width (0),
    height (0),
    buffer (NULL)
{
}

DataBuffer::DataBuffer (const DataBuffer &rhs)
  : width (rhs.width),
    height (rhs.height),
    buffer (rhs.buffer)
{
}

DataBuffer::DataBuffer (unsigned int width, unsigned int height, float *fillValue)
  throw (DataException)
{
  try
  {
      buffer = allocate (width, height);
  }
  catch (DataException &e)
  {
      e.addToStack ("DataBuffer::DataBuffer (unsigned int, unsigned int, float);

      throw e;
  }

  for (unsinged int i=0 ; i<height ; ++i)
  {
      for (unsigned int j=0 ; j<width ; ++j)
      {
        buffer[i][j] = fillValue;
      }
  }
}

void DataBuffer::setDimensions (unsigned int width, unsigned int height, float fillValue)
  throw (DataException)
{
  if ((width !=0) && (height != 0))
  {
      this->width = width;
      this->height = height;

      try
      {
        buffer = allocate (width, height);
      }
      catch (DataException &e)
      {
        e.addToStack ("DataBuffer::setDimensions()");

        throw e;
      }

      for (unsigned int i=0 ; i<height ; ++i)
      {
        for (unsigned int j=0 ; j<width ; ++j)
        {
            buffer[i][j] = fillValue;
        }
      }
  }
  else
  {
      throw DataException ("One of the dimensions is set to zero (0)", "DataBuffer::setDimensions()");
  }
}

float** DataBuffer::allocate (unsigned int width, unsigned int height)
  throw (DataException)
{
  float **result;

  ...

  return result;
}

DataBuffer DataBuffer::func ()
{
  DataBuffer result;

  try
  {
      result.setDimensions (this->width, this->height);
  }
  catch (DataException &e)
  {
      e.addToStack ("DataBuffer::func()");

      throw e;
  }

  ...

  return result;
}

---

My problem is that after calling setDimensions()in func()the values in result don't match what I passed in.:ehh:

When I step into setDimensions() in the debugger (gdb) the values all get set properly but when it exits, the values in result are changed from what they were before setDimensions() but they aren't what was set in the function.:confused:

I can't see anything wrong with what I'm doing but there is obviously something incorrect that I am missing :blush:. I would be greatly appreciated if someone could help me figure out what I'm doing wrong.

Thanks.

BTW, this is using g++ (GCC) 4.4.5 on Fedora 13

Quote:

---

Originally Posted by mazeing

I have a class (DataBuffer) that has functions that return objects of DataBuffer but when I'm calling other class functions from within the function that returns the object of DataBuffer, the internal values are not being set after the function returns.

---

Please post a complete, compilable, and runnable example (that means no ". . ." as you have now in your func() function). Code you think may not mean anything invariably winds up to be the issue, so don't post ". . .". You are also missing the allocate() function, and a small main() program that demonstrates the error.

Secondly, is there a reason to be using float** instead of container classes (most likely, std::vector<std::vector<float>>)? Then you don't have to do any of this memory allocation (assuming that is what "allocate" does). As a matter of fact, why do you need a DataBuffer class? Why not just use a container of T (vector<T>, deque<T>, list<T>, stack<T>, whatever). Unless you're writing some sort of allocator or have verified you need a specialized memory handling class that the standard classes cannot provide, then you're just reinventing the wheel.

Regards,

Paul McKenzie

Why are you creating a new DataBuffer object inside DataBuffer::func() in the first place?

Quote:

---

Originally Posted by GCDEF

Why are you creating a new DataBuffer object inside DataBuffer::func()?

---

func() modifies the original DataBuffer (which needs to remain unchanged) and returns a new DataBuffer that has the changes from func() in it.

Quote:

---

Originally Posted by mazeing

func() modifies the original DataBuffer (which needs to remain unchanged) and returns a new DataBuffer that has the changes from func() in it.

---

That seems contradictory to me and as a concept, counter intuitive to the user of the class. Does DataBuffer have a copy constuctor. Since return will copy result, the compiler needs to know how to do it.

I would help to show how you're calling func and what you're doing to determine its values are incorrect.

Quote:

---

Originally Posted by Paul McKenzie

Please post a complete, compilable, and runnable example (that means no ". . ." as you have now in your func() function). Code you think may not mean anything invariably winds up to be the issue, so don't post ". . .". You are also missing the allocate() function, and a small main() program that demonstrates the error.

---

The allocate() function is a proprietary function that we use and has worked fine in the past so I'm sure that is not the problem.

Quote:

---

Originally Posted by Paul McKenzie

Secondly, is there a reason to be using float** instead of container classes (most likely, std::vector<std::vector<float>>)? Then you don't have to do any of this memory allocation (assuming that is what "allocate" does). As a matter of fact, why do you need a DataBuffer class? Why not just use a container of T (vector<T>, deque<T>, list<T>, stack<T>, whatever). Unless you're writing some sort of allocator or have verified you need a specialized memory handling class, then you're just reinventing the wheel.

---

We're running in a real-time environment that doesn't efficiently use the STL or templates so I'm having to write very specific memory management capabilities that don't use them. I've also had to skip over the encapsulation that C++ provides to shave milliseconds off the processing. That's why I have the specialized allocate() function and can't use the STL or templates. Not an ideal situation, but it's what I have to work with.

Quote:

---

Originally Posted by GCDEF

Does DataBuffer have a copy constuctor.

---

Yes, I've added the code to my original post.

Quote:

---

Originally Posted by mazeing

The allocate() function is a proprietary function that we use and has worked fine in the past so I'm sure that is not the problem.

---

If I had a dollar for every thread where a poster says "the code works, so no need to post it", and then we discover it has a lot of issues, I would have quite a stash of cash right now.

How are we supposed to compile and run the program with missing functions or without a driver (a main() program) to see how you're interacting with your classes? The quickest way to solve your problem is to run the program and see what is happening. It is increasingly difficult to "eyeball" C++ code, run a computer in our heads, and tell you what is wrong (unless the program is trivial).

Quote:

---

We're running in a real-time environment that doesn't efficiently use the STL or templates

---

Usage of templates have nothing to do with real-time. Templates use no overhead, as they are compile time constructs. A template is just another way to express code -- it has nothing to do with how slow or fast code happens to be.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by mazeing

I've also had to skip over the encapsulation that C++ provides to shave milliseconds off the processing. That's why I have the specialized allocate() function and can't use the STL or templates. Not an ideal situation, but it's what I have to work with.

---

Use of templates can increase compile time, and can increase the memory footprint of the executable. But it cannot slow down runtime on its own, except to the extent that a bigger code footprint can reduce code segment caching. Just FYI.

Quote:

---

Originally Posted by Paul McKenzie

If I had a dollar for every thread where a poster says "the code works, so no need to post it", and then we discover it has a lot of issues, I would have quite a stash of cash right now.

How are we supposed to compile and run the program with missing functions or without a driver (a main() program) to see how you're interacting with your classes? The quickest way to solve your problem is to run the program and see what is happening. It is increasingly difficult to "eyeball" C++ code, run a computer in our heads, and tell you what is wrong (unless the program is trivial).
Usage of templates have nothing to do with real-time. Templates use no overhead, as they are compile time constructs. A template is just another way to express code -- it has nothing to do with how slow or fast code happens to be.

Regards,

Paul McKenzie

---

Sorry to take up your time then because these are the limitations I am stuck with.

Thanks anyway.

Quote:

---

Originally Posted by mazeing

Yes, I've added the code to my original post.

---

Where is the destructor? How is that memory supposed to be cleaned up?

Also, the default copy constructor may not be enough. You are just copying pointer values from one object to another -- what happens when both of these objects go out of scope?

I could see if "buffer" were a smart pointer, so that it is reference-counted (therefore no need for destructor or copy constructor) or just a container, but it is just a raw pointer. There is a lot of information missing from this puzzle.

That is why you need to provide a main() program to show us what is going on.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by mazeing

Sorry to take up your time then because these are the limitations I am stuck with.

---

So what is your question? How the code that you didn't show causes some member variables not to be set?
Do you want me to guess?
Your constructor that takes width and height does NOT store them, leaving some garbage in these fields. That could cause all kinds of side effects later on.

Quote:

---

Originally Posted by VladimirF

...That could cause all kinds of side effects later on.

---

Can VladimirF explain what side effects they are ?

Quote:

---

Originally Posted by Sharpie

Can VladimirF explain what side effects they are ?

---

Access Violation, most likely. How would you use an array of arrays of floats not knowing the dimensions?

Quote:

---

Originally Posted by VladimirF

Access Violation, most likely. How would you use an array of arrays of floats not knowing the dimensions?

---

Ok, I wrong I wrong, my fault only, I don't know about that