SabreMan is winning so far =)

any nice online resources for these templates?

the std::vector is very easy to learn! They "act" like arrays in how you access the data.

For example, to have an array of vertices, in your cpp file you would have (if you define your custom vertex type as Vertex)





Then to allocate the memory for them you would do something like this.


Now you can use Vertices the same way as if you allocated them in an array like Vertex Vertices[MAX_VERTICES];

Vertices[0].color; //etc

Hope this helped!

PS, All you have to do is #include <vector> at the top of your header file. I dont see anything about STL here, so oh well.



[edited by - RhoneRanger on March 8, 2003 3:26:13 PM]

All i''m saying is that he should learn the pros and cons of (for example std::vector) and the "old" way of doing it. A regular array is for example a lot faster than std::vector, it''s WAY easier to debug, and a lot less complicated to profile.
If you want to learn a language, you''re better off learning it, instead of just learning enough to achieve what you want in an easy way that you don''t understand. Your way of thinking is why games of today won''t run anywhere near to smoothly on a system without tons of ticks and a dx8+ gfxcard. If people were actually interested in learning, and took the extra day o two, a lot of the software of today would be of a lot higher quality.
One example, take the standard A* pathfinding algorithm, which in 99% of the cases are implemented using linked lists. Large linked lists leads to memory fragmentation, and could possible eat HUGE amounts of memory. Whereas my implementation uses a matrix, so it always stays at about 100k, and stays in a continous memoryblock. STL aren''t the answer to everything. Sure, the templates are wonderful for a lot of things, but to actually make the computer perform it''s best, you need to know when to use them, and when not to. And without learning the basics first, you won''t be able to.
Oh, and a nice reference to STL: http://www.sgi.com/tech/stl


--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.

quote: Original post by tok_junior
All i'm saying is that he should learn the pros and cons of (for example std::vector) and the "old" way of doing it. A regular array is for example a lot faster than std::vector, it's WAY easier to debug, and a lot less complicated to profile.

how so?
It is faster to initialize an array(i line of code vs a few), but when it comes down to actual performance, how is reading from an array faster?

How is it easier to debug? You see a problem with Vertices[5], you fix it! profile? ummm ok

Please tell me or show me how anything you just said is true. I am not picking please understand, I just want to know.

EDIT: If you manage your vector, and only push_back the memory needed, how can that cause huge memory loss?

[edited by - RhoneRanger on March 8, 2003 3:47:19 PM]

Im not saying it always leads to memoryloss, but it leads to memory fragmentation (which in some cases can be worse
The problem im talking about with debugging, is when you''re tracing through the code, you will end up in the stl-code a number of times before you manage to end up in your own code.
std::vector doesn''t (afaik) store the elements sequentially in memory, it requires a lot of jumping around, the same way a linked list does, which is why it''s faster to read/write a regular array. The huge amounts of memory, and the slowdown i was referring to, comes when you''re adding elements to a vector or linked list, it allocates new memory which isn''t very fast.
Like i said, STL is usually a gift from god, but not always, to be able to tell when to use it and when not to, you have to know how your different alternatives work.

--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.

quote: Original post by tok_junior
std::vector doesn''t (afaik) store the elements sequentially in memory, it requires a lot of jumping around, the same way a linked list does, which is why it''s faster to read/write a regular array. The huge amounts of memory, and the slowdown i was referring to, comes when you''re adding elements to a vector or linked list, it allocates new memory which isn''t very fast.

Firstly, every compliant implementation of std::vector is written with storage being a single contiguous array. No fragmentation of vector data here.

Secondly, adding a new element to a vector does not necessarily involve memory allocation - only if you''ve exceeded the memory already allocated by the vector. But since you''re advocating using a plain old array, you already know the maximum number of elements needed, and therefore there would be no need for a reallocation during any push_back() operation.

If you''d bothered to read all the posts you''d know i''m not saying arrays are better at all times, i''m saying he should learn the basics before starting to use STL.

--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.

just to let you know, im quite enjoying this debate =)

quote: Original post by tok_junior
One example, take the standard A* pathfinding algorithm, which in 99% of the cases are implemented using linked lists. Large linked lists leads to memory fragmentation, and could possible eat HUGE amounts of memory. Whereas my implementation uses a matrix, so it always stays at about 100k, and stays in a continous memoryblock.

actually i would like to see that code if you don''t mind. just a snippet

quote:
STL aren''t the answer to everything.

this is true. and SabreMan and RhoneRanger have admitted to this. but my question is: did you use a 2X2 array? and if you did wouldn''t std::map work as well (from what i''ve heard, that''s the equivalent to a 2D array)?

So far this STL stuff sounds too good to be true - what''s the catch?