• Advertisement

Archived

This topic is now archived and is closed to further replies.

OT: should I?

This topic is 5712 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Everybody uses STL nowadays. I''m not very familiar with it, but after reading the C++ FAQ and some STL tutorials I realize that in some situations STL can save some development time. I have a question: can I use STL''s vector for example as a containter for my vertex arrays and pass it directly to glVertexPointer? It is guaranteed to be continuous memory?? Are there any problems using STL with OpenGL? I''ve read a lot of threads on this subject(usenet), but almost every time a flame started. Please don''t start the flame here and sorry for an OT question. Regards, -Lev

Share this post


Link to post
Share on other sites
Advertisement
>> can I use STL''s vector for example as a containter for my vertex arrays and pass it directly to glVertexPointer?

Not directly. That is two different data types. There are no garantees that the memory will be continuous, but I guess in most implementations it will be so anyway, but that is bad coding to make use of implementation specific details.

>> Are there any problems using STL with OpenGL?

As long as you don''t try to pass STL structures to OpenGL (as you suggest above) everything should be fine. Personally, I use STL in all my OpenGL apps.

Share this post


Link to post
Share on other sites
Its fine to pass the vector just as you would an array by using &vectorname[0] , since the C++ standard guarantees that vector implementations are constrained always to place data in contiguous memory (its basically a smart array). This is not the case for other data structures, so you should not go around passing the pointer to the first element of a std::list, for instance.

Share this post


Link to post
Share on other sites
>> since the C++ standard guarantees that vector implementations are constrained always to place data in contiguous memory

I can''t find this claim anywhere in the STL docs I have at hand. So I don''t think you are right. Can you provide a reference to somewhere authorative that says this?

Share this post


Link to post
Share on other sites
I got it from the Effective STL book, but after some research, it turns out you''re right; its not part of the standard yet (although its on the "defect" list and it likely will be added). everyone implements it this way; it would be bizarre not to, but you can always check your implementation.

see:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#69

Share this post


Link to post
Share on other sites
Well, yeah as my original post said I would expect most implementations to do so, but since the spec doesn''t state it there might be implementations out there doing it some different way. But if this (continuous vectors) is intended to be added soon to the spec because every implementation does so anyway then okay - I have learnt something new today.

This reminds me, is there any places on the web where the official standard for C++ is available? I have only read the standard indirectly via Stroustrups book and via SGI''s STL guide.

Share this post


Link to post
Share on other sites
hmmm, that sounds weird.

Since memory is dynamically allocated with vectors, what if the next area in memory (where the next vector element would go if you push_back) has something in it? When you create a vector, you dont specify what its maximum size will be so that enough continuous memory can be put aside for it. That would make vectors the same as normal arrays.

By assuming that every element in a vector is adjacent to eachother in memory, you are assuming that when the vector was created, enough continuous memory has been put aside for every element that will be in it, but with vectors, you dont specify a max size (whole point of using vectors, you dont know how much memory you will need)

Share this post


Link to post
Share on other sites
FearedPixel, this is because a vector may be reallocated when you extend it. In fact, the standard says that calling push_back invalidates all iterators to the vector. The reason for this is that the system might have to allocate a new continuous block of memory and copy the old data into this new area. So do not store pointers to array elements across push_back() calls or any other iterator invalidating methods!

Share this post


Link to post
Share on other sites
So it basically works like realloc, doesn''t it.

Since I have my own container classes I''ll leave them as they are but next time I''ll need containter classes I''ll try STL. I''m a bit sceptical since I don''t like automatic memory management that I haven''t written myself, but I guess its just an old habit that comes from the days of procedural programming.

Anyway thanks for replies!

Regards,
-Lev

Share this post


Link to post
Share on other sites
>> So it basically works like realloc, doesn''t it.

Yes.

>>I''m a bit sceptical since I don''t like automatic memory management that I haven''t written myself

First, many implementations do realloc every time you push. They allocate more elements than needed just in case (typically 8 at a time).

Furthermore, you can always use your own allocators with STL if you want to avoid using the built-in C++ ones. The second optional template arg for most STL structs is this allocator.

Share this post


Link to post
Share on other sites
The default allocator generally grows the capacity by a factor of 2 when size exceeds capacity to amortize the cost of allocation over several push_back calls (this is different from the default behavior of the java collections classes which increase size linearly). Again, however, its implementation specific. If you want some other form of behavior, you need to supply your own allocator.

Share this post


Link to post
Share on other sites
I would suggest that everyone here needs to read about containers and how they work. If you use insert and some other methods on vectors, your vector will NOT allocate sequential elements in memory.

http://www.sgi.com/tech/stl/Vector.html

Its important to remember that vector is based on a random access container. Also memory may be allocated sequentially, but elements many not be sequential in memory - use insert and see what I mean.

If you dont use some methods then you may be able to access them sequentially, but it is NOT in the standard, so it should never be assumed that this will remain true in any circumstance on any platform. And if you are making classes that allow container inserts then obviously never access the memory like an array pointer.

I would also suggest that the ''top tip'' is very dangerous assumption and should properly describe the possible problems.

I think the reason people assume all this to be true, is that very few people obviously use the whole container feature set. Please remember that containers can do many many different things, and they are built for many possible implementations - hence the name, ''standard template library''.

I hope this helps.


Share this post


Link to post
Share on other sites
I''ve been using STL for more than a year and I like it. It''s fast and easy to remember since most of the container functions are named the same. I''ve also used some exotic features but normally I don''t bother with them. There are some bugs in vc++6 stl that I found but nothing major. There are some tricks that speed up the stl like allocating space for vector before filling it, etc. I prepend std:: namespace to stl containers instead of opening namespace up by ''using namespace std''(I think). Go ahead and try stl and see how you like it. I''m using dinkum''s stl included with vc++6.

Share this post


Link to post
Share on other sites

  • Advertisement