Vectors in C++

[atee]

I have been reading on Vectors in C++ and understand that vectors are a STL container that allow you to store pretty much anything in them. When used correctly they can be very powerful containers.

http://www.cplusplus.com/forum/articles/7459/


What I do not understand is the statement:

They provide an added benefit that they will automatically remove the memory they use when they go out of scope.

What do you mean by the statement "when they go out of scope"?

For example, considering the code below, when do we say that the 2diemnsional array (handled through a vector) goes out of scope?

#include <vector>
using std::vector;

#define HEIGHT 5
#define WIDTH 3

int main() {
  vector<vector<double> > array2D;

  // Set up sizes. (HEIGHT x WIDTH)
  array2D.resize(HEIGHT);
  for (int i = 0; i < HEIGHT; ++i)
    array2D[i].resize(WIDTH);

  // Put some values in
  array2D[1][2] = 6.0;
  array2D[3][1] = 5.5;

  return 0;
}

[laserlight]

For example, considering the code below, when do we say that the 2diemnsional array (handled through a vector) goes out of scope?

When control leaves the main function, i.e., after the return 0; statement. Basically, your vector is a variable local to the main function.

[atee]

IS the evctor a global variable and remains active throughout the program?

[laserlight]

IS the evctor a global variable and remains active throughout the program?

Yes, that is possible, but of course you should avoid global variables.

The idea here is that the lifetime of the resource is tied to the lifetime of an object. When the object is destroyed, the resource (in this case memory) is released. If the object has automatic storage duration, then its lifetime ends when the block in which the object was created ceases to exist, i.e., the variable goes out of scope. In the case of a global variable, what is important is that it is has static storage duration, hence its lifetime is that of the program, thus it is destroyed when the program ends.

[zizz]

They provide an added benefit that they will automatically remove the memory they use when they go out of scope.

Something is out of scope when it cannot be reached. Say you have this section of code.

int i1;
{
    int i2;
   (1)
}
(2)

If you want to do something at (1) you can reach both i1 and i2. At (2) you can only reach i1 and i2 will be out of scope.

When a variable goes out of scope (like i2 at (2)) its memory is automatically removed (and returned to the runtime system for recycling). This is true for variables of any type including vectors.

So the statement you are referring to is somewhat confusing since it's based on the assumption that a vector variable would be somehow different. It isn't.

[atee]

Yes, that is possible, but of course you should avoid global variables.

Thanks a lot. Please correct me if wrong: The definition of a global variable is the one which remains active throughout the program. An arary declared with evctor remians active throughout the program


You said above:

When control leaves the main function, i.e., after the return 0; statement. Basically, your vector is a variable local to the main function.

Does that mean the variable / array (in my example) is local to the main function alone and not any other function within the program?

[GCDEF]

No. There are lots of good explanations if you look for them. Global variables remain active for the life of a program, but that isn't what makes them global.

[laserlight]

When a variable goes out of scope (like i2 at (2)) its memory is automatically removed (and returned to the runtime system for recycling). This is true for variables of any type including vectors.

So the statement you are referring to is somewhat confusing since it's based on the assumption that a vector variable would be somehow different. It isn't.

If the variable is a pointer that points to an object with dynamically allocated memory (or is of a class type with such a pointer member, etc), then that dynamically allocated memory will not be automatically deallocated. In this sense, it is indeed different for a vector as a typical implementation of std::vector would use a member pointer that points to dynamically allocated memory.

So, the author's point is that because std::vector implements the RAII idiom, the dynamically allocated memory will be automatically deallocated after all, hence the sentence that follows the statement that atee quoted reads: "This means that objects stored within a vector do not need to be de-allocated (but pointers to objects do)."

The definition of a global variable is the one which remains active throughout the program.

Not quite. A global variable is a variable with global scope (or namespace scope in general, since such variables are similiarly problematic). An object with static storage duration is one whose lifetime is that of the program. Global variables have static storage duration, but so do variables -- including local variables -- that are declared static.

An arary declared with evctor remians active throughout the program

No. You seem to be confusing concepts of container, scope and lifetime here.

Does that mean the variable / array (in my example) is local to the main function alone and not any other function within the program?

Yes. The variable has block scope, where the block is the entire body of the function.

[atee]

Yes. The variable has block scope, where the block is the entire body of the function.

Then, what is the difference between declaring a variable as a local variable in the function and declaring it as a vector/container?

Even, a local variable has block scope - block being the entitr body of the function, right?

[laserlight]

Then, what is the difference between declaring a variable as a local variable in the function and declaring it as a vector/container?

It does not make sense to talk about a difference as they are orthogonal concepts. Consider:

#include <vector>

int main()
{
    std::vector<int> x;
}

x is a variable local to the main function. It is a vector<int>, and hence a container.

Even, a local variable has block scope

That is pretty much what "local variable" means.

block being the entitr body of the function, right?

A block, or compound statement, is a sequence of statements enclosed in curly braces. So, it could be the body of a function, but not always.

[zizz]

If the variable is a pointer that points to an object with dynamically allocated memory (or is of a class type with such a pointer member, etc), then that dynamically allocated memory will not be automatically deallocated. In this sense, it is indeed different for a vector as a typical implementation of std::vector would use a member pointer that points to dynamically allocated memory.

So, the author's point is that because std::vector implements the RAII idiom, the dynamically allocated memory will be automatically deallocated after all, hence the sentence that follows the statement that atee quoted reads: "This means that objects stored within a vector do not need to be de-allocated (but pointers to objects do)."

First a specific vector implementation is assumed that is not specified by the C++ standard.

Then this possible implementation is presented as a big deal with great explanatory powers as to how C++ works.

This is confusing and fundamentally wrong. An implementation never decides how C++ works. This is determined by the C++ standard alone.

Say you have these variables,

int* i;
std::vector<int*> v;

The variables i and v are different types so they are different (one is a single integer pointer and the other is a whole dynamic array of integer pointers). But these variables will behave exactly the same when they go out of scope and this is determined by the C++ standard alone and not by how the std::vector may be implemented.

So my point is that confusing implementation issues with the C++ language itself is, indeed, confusing.

[laserlight]

A specific vector implementation is assumed that's not specified by the standard.

Then this possible implementation is presented as a big deal with great explanatory powers as to how C++ works.

You might want to read the article. All the author did was to state an advantage of using std::vector over dynamic arrays that involve manual memory management.

I was the one who noted that "a typical implementation of std::vector would use a member pointer that points to dynamically allocated memory". This is not an assumption but rather a statement of fact.

But these variables will behave exactly the same when they go out of scope and this is determined by the C++ standard and not by how the std::vector may be implemented.

No, they won't "behave exactly the same". They will behave exactly as they are supposed to behave, respectively.

[zizz]

I was the one who noted that "a typical implementation of std::vector would use a member pointer that points to dynamically allocated memory". This is not an assumption but rather a statement of fact.

When a vector goes out of scope the memory is reclaimed but this is not an "added benefit". It's the same with any standard type. And the content stored in a vector will undergo exactly the same treatment as any other variable. There's no difference. This is why the statement by "the author" is confusing.

According to the standard a vector handles storage automatically. How this automatic storage is implemented has nothing to do with dynamic allocation. If you want a vector to be dynamically allocated you'll have to use new as usual in C++.

You are introducing implementation issues in the explanation of C++ and that makes it confusing.

No, they won't "behave exactly the same". They will behave exactly as they are supposed to behave, respectively.

And how are they supposed to behave? According to the C++ standard as I said, or in some other way?

C++ is defined by the standard. Hinting at other possibilities makes it confusing.

[laserlight]

When a vector goes out of scope the memory is reclaimed but this is not an "added benefit".

It depends on what you are considering. In the article referenced, the author was considering what it takes to handle dynamic arrays, and stating in his/her preamble that he/she would "go over both of the 2 major methods (Vector vs Pointer)". Thus, it is reasonable to talk about an "added benefit", i.e., in addition to having a dynamic array via std::vector, manual memory management is eliminated. Obviously, if you are considering objects in general, then there is no "added benefit".

It's the same with any standard type.

No, it is the same for all objects with automatic storage duration. A std::vector with static storage duration local to a function will not have its memory reclaimed merely due to going out of scope. Perhaps you meant to say that at the end of the lifetime of a vector, i.e., when it is destroyed, its associated memory will be reclaimed (for an appropriate definition of "reclaimed").

And the content stored in a vector will undergo exactly the same treatment as any other variable. There's no difference.

In the context of dynamic arrays, there is a difference. If you have a pointer to the first element of a dynamically allocated array, then just because the pointer's lifetime ends does not mean that the dynamically allocated memory will be reclaimed. This is in contrast to std::vector, where with RAII the storage will be reclaimed.

You can argue about how indeed the pointer will be destroyed just like any other variable, and indeed you will be right on that point, but you will have missed the pedagogical forest for the trees.

According to the standard a vector handles storage automatically. How this automatic storage is implemented has nothing to do with dynamic allocation. If you want a vector to be dynamically allocated you'll have to use new as usual in C++.

That is true, but that's also besides the point. A beginner does not have to know about custom allocators and such in order to understand why using a container with RAII is better than doing manual memory management.

You are introducing implementation issues in the explanation of C++ and that makes it confusing.

I do not agree with your claim that the author introduced implementation issues. I was the one to mention that a typical std::vector implementation will involve a member pointer somewhere, but this was directed towards your statement and was not intended to serve as an explanation to a beginner.

And how are they supposed to behave? According to the C++ standard as I said, or in some other way?

You said that they will "behave exactly the same when they go out of scope", but that is not what the C++ standard states. I'm being pedantic because of the word "exactly", but don't you see that you are being pedantic when it is unnecessary?

[zizz]

but you will have missed the pedagogical forest for the trees.

I don't think I have.

My point was that any C++ language pedagogy should be based on the C++ standard, nothing else.

It was "the author" who strayed first and you who added to the confusion.

Now at last you've realized your mishap and is trying to recover your standing. Thus the nitpickish reply. But I wellcome that as a token of progress, good luck!