Thread: stl list dynamic allocation

I need to create a list of dynamically allocated sublists; the number of sublists will be determined at runtime. I wrote some simple examples to experiment with the code. This is version1:

Code:

#include <iostream>
#include <list>
using namespace std;

int main(int argc, char **argv) {
	list<list<int>*> master;
	list<list<int>*>::iterator mIter;
	list<int>::iterator sIter;
	for(int i = 0; i < atoi(argv[1]); i++) {
		list<int>* lp = new list<int>;
		lp->push_back(i);
		lp->push_back(i+1);
		master.push_back(lp);
	}
	for(mIter = master.begin(); mIter != master.end(); mIter++) {
		for(sIter = (*mIter)->begin(); sIter != (*mIter)->end(); sIter++) {
			cout << (*sIter) << " ";
		}
		cout << endl;
	}
	cout << "finished\n";
}

It works but the pointers are cumbersome & confusing. I think it also needs changes to delete the sublists to avoid memory leaks. Then I changed it to version2:

Code:

#include <iostream>
#include <list>
using namespace std;

int main(int argc, char **argv) {
	list<list<int> > master;
	list<list<int> >::iterator mIter;
	list<int>::iterator sIter;
	for(int i = 0; i < atoi(argv[1]); i++) {
		list<int> numlist;
		numlist.push_back(i);
		numlist.push_back(i+1);
		master.push_back(numlist);
	}
	for(mIter = master.begin(); mIter != master.end(); mIter++) {
		for(sIter = (*mIter).begin(); sIter != (*mIter).end(); sIter++) {
			cout << (*sIter) << " ";
		}
		cout << endl;
	}
	cout << "finished\n";
}

This also seems to work & I think looks much nicer. But I'm a little worried about WHY it works. Why am I able to dynamically allocate the sublists without using new ? Is this the preferable way to do it? Anything special I must do to avoid losing the sublist contents if I pass the sublists to another function? Is there a better way to do this?

In the actual application, the master list will be cleared each time the function is called. I won't be moving lists around. As the function runs, sub-lists will be created and added to the master list, and elements will be added to the sub-lists, one at a time. Overall, the master list will probably never contain more than 10 sub-lists, and each sub-list will contain up to 40 elements but generally much fewer than that. The elements of the sublists are instances of a simple class representing xy coordinates, so they're little more than a pair of ints. None of the data has any value after the function returns.

Based on this, is version2 the way to go?

Things to note:

• typedef for readability
• Adding empty list to master, then modifying it within master to avoid copy
• Use of const types when elements are not being modified
• Always use "++it" instead of "it++"
• Avoid calling functions within a loop condition if the result is always the same: "atoi(argv[1])"

Version 2 is just as good and more convenient as long as you avoid copying.

gg

typedef for readability
Good point.

Adding empty list to master, then modifying it within master to avoid copy
Yes, my function will do this.

Avoid calling functions within a loop condition if the result is always the same: "atoi(argv[1])"
Yes, I would "never" do this. I was just being quick & sloppy in the example.

Use of const types when elements are not being modified
Is this just a matter of style or is there some significance that I'm not seeing here?

Always use "++it" instead of "it++"
Why?

Originally Posted by R.Stiltskin

Always use "++it" instead of "it++"
Why?

Because it++ creates a temporary it that it returns, then increments it; but ++it just increments it and returns it. So using ++it eliminates the temporary object.

>> Use of const types when elements are not being modified
It's more than just style, it helps the compiler help you catch errors and could potentially have some performance benefit.

>> Always use "++it" instead of "it++"
If you're not using the return value of the increment (or decrement) then using the first version could potentially avoid some overhead. it++ has to save a copy of the original state of the iterator, then increment, then return the copy. ++it just increments and returns. I doubt it ever makes a huge difference, but since all else is equal it is best to use the more efficient choice.

Forgot to "return 0;" at end main...

gg

Originally Posted by Codeplug

Forgot to "return 0;" at end main...

gg

Yeah -- as I said before, it was quick & sloppy.

Thanks, all of you, for your suggestions & explanations.

I just noticed that in Codeplug's example (post #3), in the first for loop, if I replace

Code:

        // get reference to empty list just added
        IntList &l = master.back();

with

Code:

        // get reference to empty list just added
        const IntList &l = master.back();

I get this compiler error:
stl_test4.cpp: In function `int main()':
stl_test4.cpp:21: error: passing `const IntList' as `this' argument of `void
std::list<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = int, _Alloc =
std::allocator<int>]' discards qualifiers
stl_test4.cpp:22: error: passing `const IntList' as `this' argument of `void
std::list<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = int, _Alloc =
std::allocator<int>]' discards qualifiers

I don't understand what this error message is saying, or why there is an error. Why can't this reference be const?

By making it const, you're saying that you won't be modifying "l". But push_back() does modify it.

>> It's more than just style, it helps the compiler help you catch errors...
See!

Understanding the errors from your compiler is something else....

gg

Originally Posted by Codeplug

Understanding the errors from your compiler is something else....
gg

's'matter, you don't like gcc?

I misunderstood. I was thinking of const in the sense that the reference would be used only for one particular object, never re-assigned to another object. Is there such a concept, analogous to const pointers vs pointers to const objects? (As you can see, I'm on shaky ground when it comes to c++ references.)

>> that the reference would be used only for one particular object
That's actually how references behave by default. const or no const, "l" will always reference the one instance.

gg