Inserting STL containers "recursively"
It''s possible to insert a container inside another one and resize the first?
For example, you have a vector v1. Then you insert in v1 a new vector v2. Can you resize v2 (add or remove elements)?
Test it and see what happen.
I can''t really se why you shouldn''t, but it could be slow since when v2 is growing v1 might start to move the elements around to make sure they fit into memory. Inserting a vector in a list is probably faster, since lists don''t need all elements stored in a sequence in memory.
Snale
+--My humble and superior homepage
I can''t really se why you shouldn''t, but it could be slow since when v2 is growing v1 might start to move the elements around to make sure they fit into memory. Inserting a vector in a list is probably faster, since lists don''t need all elements stored in a sequence in memory.
Snale
+--My humble and superior homepage
Snale+--My humble and superior homepage
May 09, 2001 04:19 PM
I have a class, OBJModel, that contains a vector. That''s, an OBJModel contains a collection of material libraries. But each OBJMaterialLibrary contains a vector. An OBJMaterialLibrary can have multiple materials. What I don''t know is if it''s possible to do this.
I think it''s not so strange.
May be OBJModel should contain a list rather a vector as Snale suggests. What do you think?
I think it''s not so strange.
May be OBJModel should contain a list rather a vector as Snale suggests. What do you think?
It all depends on what you are using it for. Vectors have fastest access while list have fastest insertion. List also does not support random access. All stl containers hold data by value so copying can be slow. It all depends on the problem realy.
The primary reason for using a list is that when adding lets say 3 vectors to your container this might happen in a vector:
adding first
adding second
three doesn''t fit behind the others so it moves everything to a position where it can have everything lined up nicely. This means faster access but takes a lot of time if your vectors are large.
A list uses a linked list and it doesn''t matter where the elements are in memory, it won''t affect performance at all. So the list won''t move things around as you add elements.
I ain''t sure about this though, lists could move things around to but I can''t find a reason to why it should behave like that.
Perhaps the best thing to do would be to use a list in OBJmodel like this: list yourList;
seems like that would save a lot of memory.
Snale
+--My humble and superior homepage
adding first
adding second
three doesn''t fit behind the others so it moves everything to a position where it can have everything lined up nicely. This means faster access but takes a lot of time if your vectors are large.
A list uses a linked list and it doesn''t matter where the elements are in memory, it won''t affect performance at all. So the list won''t move things around as you add elements.
I ain''t sure about this though, lists could move things around to but I can''t find a reason to why it should behave like that.
Perhaps the best thing to do would be to use a list in OBJmodel like this: list
seems like that would save a lot of memory.
Snale
+--My humble and superior homepage
Snale+--My humble and superior homepage
One of these days I''m going to get around to submitting an overview of STL so we can just start referencing it whenever a question like this comes up. In the meantime, this is a brief description of the efficiencies of STL containers found at:
http://www.cs.rpi.edu/projects/STL/htdocs/node52.html
Sequence Containers are objects that store collections of other objects in a strictly linear arrangement.
vector, which provides array-like random access to a sequence of varying length, with constant time insertions and deletions at the end
deque, which provides random access to a sequence of varying length, with constant time insertions and deletions at both ends
list, which provides linear time access to a sequence of varying length, with constant time insertions and deletions anywhere
Associative Containers provide for fast retrieval of objects from the collection based on keys. The size of the collection can vary at runtime. The collection is maintained in order, based on a comparison function object of type Compare (a default template parameter according to the STL standard, but a non-default template parameter in the current implementation).
set, which supports unique keys (contains at most one of each key value) and provides for fast retrieval of the keys themselves.
multiset, which supports duplicate keys (possibly contains multiple copies of the same key value) and provides for fast retrieval of the keys themselves.
map, which supports unique keys (contains at most one of each key value) and provides for fast retrieval of another type T based on the keys
multimap, which supports duplicate keys (possibly contains multiple copies of the same key value) and provides for fast retrieval of another type T based on the keys
All supported operations on associative containers have logarithmic time bounds (or in some cases amortized constant bounds).
http://www.cs.rpi.edu/projects/STL/htdocs/node52.html
Sequence Containers are objects that store collections of other objects in a strictly linear arrangement.
vector
deque
list
Associative Containers provide for fast retrieval of objects from the collection based on keys. The size of the collection can vary at runtime. The collection is maintained in order, based on a comparison function object of type Compare (a default template parameter according to the STL standard, but a non-default template parameter in the current implementation).
set
multiset
map
multimap
All supported operations on associative containers have logarithmic time bounds (or in some cases amortized constant bounds).
since your vectors are encapsulated by a class you are not inserting a vector in a vector, you are inserting an object in a vector.
However, it seems like you do this:
class OBJModel {
//code
vector v;
//code
}
class OBJMaterialList {
//code
vector v;
//code
}
This would be better
class OBJModel {
//code
vector v;
//code
}
class OBJMaterialList {
//code
vector v;
//code
}
I suppose the material Libraries are shared between models and this saves memory and is faster since the vector don''t have to return a whole object when you are accesing it.
Snale
+--My humble and superior homepage
However, it seems like you do this:
class OBJModel {
//code
vector
//code
}
class OBJMaterialList {
//code
vector
//code
}
This would be better
class OBJModel {
//code
vector
//code
}
class OBJMaterialList {
//code
vector
//code
}
I suppose the material Libraries are shared between models and this saves memory and is faster since the vector don''t have to return a whole object when you are accesing it.
Snale
+--My humble and superior homepage
Snale+--My humble and superior homepage
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement