STL vectors

c = (*v);

The pointer need to be dereferenced.

Ninja Edit: Do as Paradigm Shifter says >_<

operator[] is only defined for objects not pointers to objects.

Solution: Use a reference or create the vector on the stack.

Reference way: vector& theVector = *v;
char c;
c = theVector[0]; // works

Thanks alot guys ;)

I have a question related to this topic. I have noticed this form being used quite a lot with vectors (even simple types).

v= new vector;

Why would you declare a NEW vector for a simple type. I mean, quite frankly, I don't use new even when declaring a vector of one of my classes, if the class is made up of nothing more than simple types. Is it being taught this way in school? I have the Josuttis reference for STL, and in his description of vectors, he does not mention any advantage gained by creating the vector this way. As a matter of fact, since a common use of new is to dynamically allocate an array:

v = new char[someVar];

and the other way to dynamically allocate an array is to use vector instead, it makes even less sense. Does it have something to do with forcing you to program "correctly" by making you do your own garbage collection? You could just do this:

v.~vector();

to clean up, if you felt it was necessary. I'm not trying to be argumentative, but as I said at the beginning of this post, I am noticing this alot, and was just curious as to why people do this. Quite frankly, I use vectors all the time, and if this is a way to speed my programs up, I would immediately start doing it.

Thanks,
B-Dog

there is no gain considering that with the default allocator type container elements are allocated on the heap anyways, the only time you may wont to do this is for it to persist through-out any scope, to avoid the container from destroying its elements when its out of some scope and/or you wont to share that instance.

I can't see why anyone would wont a vector of characters for a string in the first place when you have std::string which is very simillar to a vector of chars.

Quote:

Original post by buster77 You could just do this: v.~vector(); to clean up, if you felt it was necessary.

Don't explicitly call the destructor of an object on the stack. That treads firmly in the realm of undefined behaviour. If you really need to do something like that, just enclose the lifespan of the variable in an additional level of {}'s.

Quote:

Original post by snk_kid I can't see why anyone would wont a vector of characters for a string in the first place when you have std::string which is very simillar to a vector of chars.

I can't remember if std::string guarantees contiguous storage. vector does.

Quote:

Original post by Anonymous Poster The biggest gain in using stl, is that you DO NOT NEED to explicitly allocate memory and then worry about deleting. If you going to use new, then you just defeat that.

I must disagree with you, the BIGGEST gain in using STL is in that you don't have to rewrite, over and over this same pices of code. Things like stack, list, string, double direction list etc. have ben writen, and prabobly very well tested for you.

Quote:

Original post by Fruny Quote: Original post by snk_kid I can't see why anyone would wont a vector of characters for a string in the first place when you have std::string which is very simillar to a vector of chars. I can't remember if std::string guarantees contiguous storage. vector does.

In 14882:1998 it wasn't, and as far as I can tell nothing in TC1 changed that. Of course, I don't know of any std:basic_string<> implementation that doesn't use contiguous storage, so it's sort of a moot point.

However, there are several std::basic_string<> implemenations that do use reference counting, and if you want to avoid that, especially in a multi-threaded environment, you might use a std::vector instead.

Quote:

Original post by Fruny Quote: Original post by snk_kid I can't see why anyone would wont a vector of characters for a string in the first place when you have std::string which is very simillar to a vector of chars. I can't remember if std::string guarantees contiguous storage. vector does.

I recall reading something about that future implementations does not guarantee contigunous storage...

...on the other hand i could have been dreaming [grin]

Quote:

Original post by Estor Quote: Original post by Anonymous Poster The biggest gain in using stl, is that you DO NOT NEED to explicitly allocate memory and then worry about deleting. If you going to use new, then you just defeat that. I must disagree with you, the BIGGEST gain in using STL is in that you don't have to rewrite, over and over this same pices of code. Things like stack, list, string, double direction list etc. have ben writen, and prabobly very well tested for you.

not only that, but it doesn't make sence to have a pointer to a container. a container of pointers is one thing, but i see no reason for ever using a pointer of a container. i can see using references when you want to send containers around to functions and stuff, but...

also, couldn't he just use ->at() ? bah, use a real instance anyway.

Quote:

Original post by SiCrane However, there are several std::basic_string<> implemenations that do use reference counting, and if you want to avoid that, especially in a multi-threaded environment, you might use a std::vector instead.

Good point, I know i PM'ed Fruny already, but anways yeah most good implementation make std::basic_string just a smart handle to a reference-counted representation usually implementes copy-on-write (COW) schematics so basic_string beats a vec of char's for strings hands down in this case but as you pointed out COW doesn't gel well in a multi-threaded environment so you may actually wont a vec of chars instead.