Not quite... Rather, it is another template argument when you create the vector. The beauty of templates (ignoring really cool template metaprogramming) is that you can create user customizable code that is standard (term used loosely, but it still holds in the strict sense as well).
*edit *
Look at SGI's documentation (my favorite source for STL docs) here: http://www.sgi.com/tech/stl/stl_index_cat.html
The section at the bottom is... Drum roll, please.... Allocators.
Last edited by Zach L.; 12-15-2004 at 07:53 PM.
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
>> is STL still STL if it has been 'enhanced' by the programmer
>> STL was designed to be enhancable by the programmer
that's not true at all! the STL *is* designed to be EXTENSIBLE, meaning you can and should derive classes from it whenever you need to. but that's not the same as tinkering with internal code (a very bad idea (tm)).
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Changing allocators, however, isn't tinkering with the internal code of the STL implementation.
(I realize you weren't implying that, Sebastiani, I just thought I'd clarify that point.)
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
Holy pandemonium batman! I leave for one day of exams and things just go nuts.
Good to know, thanks for clearing that up. (Way back when)Code:>> I'm not sure that clear has to be called. It doesn't. If you have objectinstances in a container, the destructors for those objects will be called when clear() is called or when the container's destructor is called.
From back on the first page. I think that's what my initial problem was along the lines of, but I've removed the vector that was causing the problem and reworked it now.Code:Illustration of serious memory/resource leak with vectors:
I like that, and it makes it a bit more clear as to what's being used as what. I think I'll take the time to re-structure a touch.Code:Personal Opinion Follows: If you are going to use methods with structs then you should rename it to class and just declare the public part.
As for everything else...whew, right over my head, but sounds like there're some serious issues you guys are in need of solving, so I'll leave you to it
Thanks for all your suggestions and help. Now, carry on.
Advantages to using STL: rapid development, extensive features, thoroughly tested
Advantages to using your own (if done correctly): performance gain, a class completely customized for what you need
Truthfully, unless you are doing something that deals with raw RAM or virtual memory then I see no reason to be toying with making your own.
You've got to be careful with this, too. You should not derive from most STL classes, they were not meant to be base classes (like string, vector, etc.). You can and should extend their functionalities by using non-default template parameters like allocators, comparison functions, etc.Originally Posted by Sebastiani
This is still to do with vectors, so I'll just post here to avoid starting up a new thread.
if I declare a vector of a class, I.e.:
When MyClass::GoDoIt() has been called, and I'm in the body of that function, is it possible to be able to tell which element of the vector actually called that function (was it Things[1], Things[4]...)? Also, is there a way to tell how many other elements exist?...Code:class MyClass { public: void GoDoIt(void) { //In here is where my //question refers to. } }; std::vector<MyClass> Things;
Without the need to pass those values in as parameters into the function.
So, pretty much, does an element "know" which number, of how many, it is?
If you make your function call like this:is it possible to be able to tell which element of the vector actually called that function
Then you know which element of the MyClass vector of classes called the function.Code:Things[4].GoDoIt( );
While operating inside the body of your function definition.. any changes you make will have a global effect over the entire vector of classes.
Also, is there a way to tell how many other elements exist?Code:Things.size( );
Last edited by The Brain; 12-17-2004 at 04:51 PM.
- "Problem Solving C++, The Object of Programming" -Walter Savitch
- "Data Structures and Other Objects using C++" -Walter Savitch
- "Assembly Language for Intel-Based Computers" -Kip Irvine
- "Programming Windows, 5th edition" -Charles Petzold
- "Visual C++ MFC Programming by Example" -John E. Swanke
- "Network Programming Windows" -Jones/Ohlund
- "Sams Teach Yourself Game Programming in 24 Hours" -Michael Morrison
- "Mathmatics for 3D Game Programming & Computer Graphics" -Eric Lengyel
>>So, pretty much, does an element "know" which number, of how many, it is?
From within the body of the function being called, there are 2 ways I can think of, and neither one is pretty: One is, tell it which element it is, by passing an extra parameter. The other is, if it has access to the vector that it's contained in, you can:
As you can see in my code, I used Things.size() to find out how many elements there are in Things.Code:for(int index = 0; index < Things.size(); ++index) { if(&(Things[index]) == this) break; } //Now index is the index in the vector that the object is at.
Just Google It. √
(\ /)
( . .)
c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.
Ok there is nothing magical about a vector. It works in a similar manner to a regular array. Does an int in an integer array know which index it is? Of course not. Do you really need for the object to know which index it is?
Side note: iterators are more suitable in the above code.
I know, but it would have been harder to understand and would have ran contrary to:
Although you and I know better, it would seem to the average newbie that iterators are VERY different from anything involving arrays.Ok there is nothing magical about a vector. It works in a similar manner to a regular array.
Just Google It. √
(\ /)
( . .)
c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.
I was hoping that they would be some sort of "super-array" that writes my program for me...guess not.
Yeah, and it makes sense now, I'll just stick to passing the variables as arguements. It's not really that much extra work anyways.
Thanks guys
>> You should not derive from most STL classes, they were not meant to be base classes (like string, vector, etc.).
and why not?
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
They don't have virtual destructors, for one. This means that any such object deleted through a base pointer will invoke undefined behaviour. (So feel free to derive privately from them.)
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Yes, I should definitely have said "publicly derive from". It is really a general rule, not an absolute one (in fact Codeplug debated against such a "rule" with me a long time ago). If you know that you won't be using the class polymorphicly, and you have a good reason to do so, then it probably isn't so bad. However, usually the reason for doing so is to extend the functionality of the class, which can be done in other, better, ways.
[EDIT] - Ha! Codeplug remembers that conversation.
Last edited by jlou; 12-18-2004 at 04:46 PM.
