Valhalla Legends Archive

Quote from: Moonshine on June 01, 2004, 07:46 PM

Quote from: Eibro[yL] on June 01, 2004, 03:06 PM

Quote from: Moonshine on June 01, 2004, 02:38 PM
If you just use list<node>, how would you create list items dynamically (e.g. new node)?  That seems like the whole point of a list in most cases to me.

By calling nodes constructor. eg. mylist.push_back( node( arg1, arg2 ) ); where mylist is std::list<node>.

QuoteAlso, it wouldn't even matter if the list iterators were node**, because all you need to do is use list<node*>::iterator, and not worry about any syntax at the lower level.

Yes, it would matter. To access elements of node, you'd need to do (*listiter)->member;

Again, these discussions don't really pertain to the original posters question. Oh well.

Hmmk, but that way is definitely a lot less versatile/clear than if you use pointers (in fact I've personally never seen it used).  For one, you're totally limited to only passing constructor parameters (vs. being able to create a new object before insertation, and doing further manipulation before passing it).

And maybe you shouldn't have critiqued my original post (when you were wrong about me wanting to use node * anyways), and made it go off topic.  My post was on-topic; providing advice to fire that the STL is easier to use.

Limited how?
node mynode;
mynode.somefn();
mylist.push_back( mynode );

Maddox orginally critiqued your post, not me.

Quote
Limited how?
node mynode;
mynode.somefn();
mylist.push_back( mynode );

Umm, that'll go out of scope if you do it that way.  Which is quite dangerous, btw

Quote
Maddox orginally critiqued your post, not me.

That may be true, but you also independantly made your own point critiquing my post.  Which means you're just as bad as him, gg  

Quote from: Moonshine on June 02, 2004, 03:23 AM

Quote
Limited how?
node mynode;
mynode.somefn();
mylist.push_back( mynode );

Umm, that'll go out of scope if you do it that way.  Which is quite dangerous, btw

No. You don't understand. There is nothing dangerous about that code. The copy constructor will be invoked to create a new variable on the list. The original will go out of scope.

Okay so it invokes the copy constructor (I didn't even test it, and forgot about that).  However, that's way less efficient than using a pointer; copying the whole object over when you can simply point to it is moronic.  I guess that's why I stay away from that way in the first place, it's needlessly less efficient.

So maybe you shouldn't suggest preferring not using pointers when they're way more efficient in the future.

Quote from: Moonshine on June 02, 2004, 05:09 PM
Okay so it invokes the copy constructor (I didn't even test it, and forgot about that).  However, that's way less efficient than using a pointer; copying the whole object over when you can simply point to it is moronic.  I guess that's why I stay away from that way in the first place, it's needlessly less efficient.

So maybe you shouldn't suggest preferring not using pointers when they're way more efficient in the future.

There are advantages and disadvantages. If the object is big, copying the whole object over is bad. Then you should write your code to create the object in the list first and assign values in it later. That way you are doing everything with the highest efficiency.

However, for a small object, invoking the copy constructor won't be a big issue. Something like a std::string will copy very fast.

Storing the object in the list will also be more memory efficient. Instead of having two allocations per list item, there'll be just a single allocation. That's way more efficient.