inserting class into a vector

If you want to place objects into a std::vector those objects need to have a copy-constructor:

class temp {
public:
    temp() {};    // standard c'tor
    temp( temp& t ) {};    // copy-c'tor
};

This is because objects that are inserted are actually copies of the original objects. So be careful if you have pointers in your class as those may become invalid.

I have worked it out (10 seconds after I posted it) :( but what i need to know is how would I run a function (already created in the temp class) of the object after it has been inserted into the vector

ie.

cout << vec1(1).get_id();

either

cout << vec1[1].get_id();

or (this version checks that you haven't used an index that doesn't exist in the vector - bounds checking is very useful and recommended unless speed is of utmost importance.  If it's that important to you, you might not be using vector anyway)

cout << vec1.at(1).get_id();

*Sigh* STL is designed with performance in mind. A vector is in general hardly any slower than an array would be. Of course it depends on the implementation -- however, complexity is part of the standard, so there is not that much freedom. I've seen it being used in PC games development excessively and very rarely saw the need to replace it with a proprietary structure. It might hold true on other platforms, especially psx/ps2 call for a non-generic approach most of the time due to stringent limitations. On a PC one shouldn't hope to gain any significant speed by favoring an array over a vector.

Erm, the point I was making was that access via vector::at is slightly slower than vector::operator[].  I was also making the point that generally the speed hit is unimportant (but finite) in comparison to the bugs it can help you find.  

I also said that if you were worried at the difference between at() and [], you might be looking at using arrays anyway.  They *are* more efficient (std::vector is normally based on an array), but in the vast majority of cases, the marginal efficiency gain is not worth it.

>>*Sigh* STL is designed with performance in mind.
I know.  For the record, I write physical simulation software that can run for more than a day before completing.  I also use the STL extensively, and at() by default as access to vectors.  *I have nothing against the STL*.

Karls - sorry for this, I hope the marginal light generated made the heat worthwhile  :-)

Did you, by any chance, look at the assembly listing generated by an optimizing compiler, let's say msvc? Could you then explain to me, how an array could possibly be accessed any faster than the std::vector that comes with v6?

p.s.: I write code that can run 150 micro-seconds before completing, just to point out what I'm talking about...

>>Did you, by any chance, look at the assembly listing
>>generated by an optimizing compiler, let's say msvc?
>>Could you then explain to me, how an array could
>>possibly be accessed any faster than the std::vector
>>that comes with v6?

There is a difference, but 99% of the time, the performance difference is so small, it's not worth worrying about.
However, if you have real time code, and every single machine instruction counts, then you might have to consider using array over vector.

IainHere main point was using operator[] over at() function.  Which there is also very little performance difference, and again, usually not worth worrying about.

It's also hard to create a test in which you can actually measure the differnce.

Karls - ignore the remainder, and apologies for the notification.

fl0yd - the purpose of this site is to help people with their problems.  I explained the purpose of my original post above.  Apologies if you are annoyed in any way, and think that I'm trying to steal some points from you or something; I really do not care about points.  Anyway, back to the featured programme:

I had written a very long discussion of the finer points, but what I'm really saying can be summed up simply.

1) arrays are faster then vectors only in highly specialised applications [and here I'm not talking about *access*, as you inferred], but for most people most of the time there is no significant advantage to be gained.
2) .at() access is a bit slower than [] access, but is still recommended whenever it is remotely possible that you could overrun the bounds of the vector.
3) No hard feelings :-)

>>If you want to place objects into a std::vector those
>>objects need to have a copy-constructor:

I don't believe this is the problem.
First of all if you don't have any constructors in your class, the compiler will automatically create a copy constructor for you.

That real problem is that insert is not being past the proper arguments.

Try the following method:
vec1.insert(vec1.begin(), temp_object);