8

Coming from a C# world, I'm struggling to make sure I don't introduce memory leaks and errors in a C++ project I've been assigned to. I'm writing code that uses structs to parse information from a buffer of data. Because the number of data structures that appear in the buffer can vary at runtime, an stl vector is used to store the processed data. I came across the following block of code in the existing software, and am struggling to understand why it works:

MyVectorOfObjects.clear();
for (unsigned __int8 i = 0; i < NumberOfObjects; i++)
{
    MyParserObject parserObject;                // Declaring without 'new'?
    parserObject.Decode(buffer, offset, size);  // A method on the struct.
    MyVectorOfObjects.push_back(parserObject);  // Does this keep parserObject in scope?
}

My questions are specifically:

  1. According to this question, wouldn't parserObject go out of scope each iteration since the new keyword isn't used? Evidently this code has been working.

  2. In this case, does placing the object in a vector keep the parserObject in scope?

  3. According to this question, the parserObject is copied. If this is the case, what are the performance implications (e.g. memory consumption, memory allocation, etc.) of this? Also, do the copied parserObjects then assume the same scope as the vector?

Thanks for any help.

Community
  • 1
  • 1
bporter
  • 4,467
  • 2
  • 19
  • 29
  • 3
    This is somewhat basic C++. I recommend grabbing a [good introductory C++ book](http://tinyurl.com/so-cxxbooks) and learning from it. That said, you need to realize one big difference between C++ and C#: In C++, variables contain *values* (unless explicitly declared as references, of course), while in C#, most variables contain *references* (of course, not counting value types). – R. Martinho Fernandes Aug 24 '11 at 18:40
  • With `MyParserObject parserObject;`, it's memory is automatically managed by the program - think of it as a `delete parserObject;` right after the `for`-loop, though this doesn't necessarily happen in practice. – Mateen Ulhaq Aug 24 '11 at 18:47
  • @R.Martinho Thanks for the reference... and the note. – bporter Aug 24 '11 at 18:57

2 Answers2

7

  1. Yes, the instance of parserObject that is declared within the for loop goes out of scope each time the loop iterates.

  2. No, placing the parserObject into the vector doesn't keep that object in scope. The push_back() method will make a copy of that object that is now owned by the vector. You need to make sure your objects can be properly copied (copy-constructor and assignment operator may be necessary). Copies contained in the vector in this example are owned by the vector, and will have object lifetimes that are similar to the vector itself.

  3. The paserObject is copied, and this may have implications on memory usage and performance. If the parserObject is not trivial to copy then this can be an expensive operation. This is wholly dependent upon your implementation of the parserObject.

Chad
  • 18,706
  • 4
  • 46
  • 63
  • Two good answers and I wish I could accept both; being forced to choose, however, this one explicitly answered the questions. Thanks to all for the help. – bporter Aug 24 '11 at 19:07
4
MyVectorOfObjects.push_back(parserObject);  // Does this keep parserObject in scope?

push_back makes a copy of the object and stores it.

So make sure that you've defined copy-constructor (and copy-assignment) properly for the class MyParserObject if it has pointer member(s). Or else default code generated by the compiler would be enough, provided each member of MyParserObject follows the same pattern (i.e they've defined the copy-constructor (and copy-assignment) properly if they've pointer members, or else default-code generated by the compiler would be enough, provided .... and so on.)

Nawaz
  • 353,942
  • 115
  • 666
  • 851
  • So this would mean that each copied parserObject would remain in scope so long as MyVectorOfObjects was in scope? – bporter Aug 24 '11 at 18:45
  • 1
    If you're working with C++0x, then also be sure to define the move-constructor and move-operators. – Mooing Duck Aug 24 '11 at 18:59