new, delete, STL

[Karl Heinz Buchegger]

BTW, copying and pasting your code directly gives the output of(I did not
change a damn thing either).

Object being created
Object being created
Object being created
Object being removed
Object being removed
Object being removed

That's because a compiler is allowed to optimize away some
temporaries. Thats why Mike's compiler creates only 1 temporary
while your compiler sets up for 2 temporaries. You might want
to try to compile your code in 'release mode' (with full optimization)
and see if your compiler gets rid of an additional temporary also.

 

[Jon Slaughter]

That's because a compiler is allowed to optimize away some
temporaries. Thats why Mike's compiler creates only 1 temporary
while your compiler sets up for 2 temporaries. You might want
to try to compile your code in 'release mode' (with full optimization)
and see if your compiler gets rid of an additional temporary also.

tried that and same results... any other great suggestions?

 

[Jon Slaughter]

Everyone would have saved 'a lot more time' if you just would swallow down
your pride and *read* a book about C++.

What you are dealing with here is all pretty basic C++.

omg... wtf is up with this book shit? I thought this group was to get help?
maybe I am wrong? just a communion of arrogant assholes? fact is I have
read many books on C++ before and I used to program fairly fluently in it,
but this was over 10 years ago and I am trying to get back into it. I did
look on sgi's stl introduction page before I came here and the documentation
is pretty sorry.

Besides, you are pretty arrogant yourself because you say I need to swallow
my pride and read a book... thats kinda stupid. I came in here asking for
questions because I thought this was a place to get help(it used to be years
ago I suppose before it was taken over by the likes of you)... my fault for
assuming.

I got an idea!! how bout you go read a book asshole?

 

[Torsten Mueller]

tried that and same results... any other great suggestions?

I'd like to mention the word "copy constructor".

T.M.

 

[Jon Slaughter]

The explanation is probably very simple. std::vector is basicly
mimicking array semantics for memory storage, looks like a duck, sounds
like a duck.. walks like a duck, anyway..

yes, I assumed that because I have written my own vector and set container
classes before that are similar to the basic features of STL's but I have
yet to find any good documentation that describes that exact behavior of the
library in detail.

http://www.sgi.com/tech/stl/stl_introduction.html is pretty poor IMO and
thats all that I can seem to find.

When vector runs out of capacity, it is grown.. when vector is grown
new objects are being created, and existing ones are *copied* to the
new storage that is being allocated. It is not defined as far as I can
remember how large the capacity of a vector is initially, and I don't
remember liking to read Dinkumware's (whose implementation you are
currently using) code very much (sorry DW).

Well, I'm not so concerned with the inner workings of the vector library
except that it is not bloated. The copy procedure was just something that I
was not familiar with.. maybe I missed it when I was reading over the
basics. The whole point for me using the vector lib is mainly for automatic
memory allocation and deallocation for the expansion of the array and
possibly for future reasons that I am not aware of(as the automatic memory
allocation is not that big a deal to implement but all the algorithms that
go along with the class are(cause I rather not implement them myself)).

The small vectors rarely can both, efficient in runtime and memory
footprint. If they are runtime efficient then it means they need some
larger constant as initial capacity, which wastes memory and
vice-versa. In this context, how would you implement your Standard
Library's vector class? ;-)

I suppose this depends on the application. I am using a nested set of
classes each wrapping an STL vector and at most the will probably contain 15
elements each.

I don't think there is a direct relation between memory and speed(in this
case). In my case there is no reason to allocate any inital extra capacity
because the array is almost static for the majority of run time. i.e.,
there is a basicaly a setup procedure that will initalize the vector and
during the main loop of the program one will usually not mess with the
vector(well, its more complicated than that since I have several vectors...
most will not be modified most of the time(if that makes sense)).

So all in all, this comes down to design tradeoffs by your Standard
Library vendor.. if you make the vector larger, with more objects, you
might observe more efficiency taking place immediately.

depends on what you are using the vector for. Like I said, I the majority
of my vectors are basicaly static entities for the majory of the program and
have very little influence on performance. I am using STL's vector because
it is easy than writing my own and to be consistent with other parts of the
program that use STL and also for possible future design reasons.

Btw. Just out of morbid curiosity, if your vector overflows.. which is
better, to double the size, or grow only 50%, or if something else,
what? I know the Dinkumware's (old) answer to this because this was
covered, I think in this same group some years ago, I recall P.Becker
(?) mentioned some rationale to explain the behaviour. I'm drifting
off-topic for your concerns but just popped to mind..

Well, I would say it depends on context. In my specific case I have about 5
vectors that I am using and 3 of them will be static for most of the time,
one will be used like crazy(inserting, removing, manipulating,etc...) and
the other is about midway. I'm using STL's vector for all of them. I
suppose that as long as its optimized for the "like crazy" case then I'll be
fine. I just tend to have a problem wasting memory and performance for
absolutely no reason except lazyness.

When I did my own vector class I allowed the user to change how much extra
capacity one could allocate when an overflow occured... maybe real advanced
methods would have some optimizing feature on this parameter to find the
best number(ofcourse I doubt there is one but...).

I hope this was any help..

Well, not really... but...

 

[Mike Wahler]

Well, for future reference why don't you just not reply to my messages?

OK, I won't. And thanks for letting me know that my attempts
to help you are a waste of time.

-Mike

 

[Andre Kostur]

omg... wtf is up with this book shit? I thought this group was to get
help? maybe I am wrong? just a communion of arrogant assholes? fact

Hmm.. an aversion to actually exerting yourself to learn something
instead of been spoon-fed everything? Funny that... _I_ prefer to teach
people who are actually wanting to learn, which many, many new/infrequent
posters seem to want to do.

is I have read many books on C++ before and I used to program fairly
fluently in it, but this was over 10 years ago and I am trying to get
back into it. I did look on sgi's stl introduction page before I came
here and the documentation is pretty sorry.

Over 10 years ago, C++ wasn't Standardized. IIRC it was still the ARM
that was the "gospel" on C++. Get some decent books. "The C++
Programming Language" (Stroustrup) and "The C++ Standard Library"
(Josuttis) are good places to start.

Besides, you are pretty arrogant yourself because you say I need to
swallow my pride and read a book... thats kinda stupid. I came in here
asking for questions because I thought this was a place to get help(it
used to be years ago I suppose before it was taken over by the likes
of you)... my fault for assuming.

This is a place to get help on Standard C++. You may get a hint or two
on what may be going wrong on certain platform and/or implementation-
specific things, and then pointed to a more appropriate forum for that
specific question. Such as what appears to be an optimization issue with
whatever compiler you're using. It has been pointed out that the
compiler is free to optimize away certain temporaries. If your compiler
doesn't, that's an issue with your compiler and you'd have to take that
up in a newsgroup dedicated to your compiler. Failing that, with the
compiler vendor.

I got an idea!! how bout you go read a book asshole?

Willing to bet he's probably read more pertinent books on C++ than you
have.....

 

[Jay Nabonne]

depends on what you are using the vector for. Like I said, I the majority
of my vectors are basicaly static entities for the majory of the program and
have very little influence on performance. I am using STL's vector because
it is easy than writing my own and to be consistent with other parts of the
program that use STL and also for possible future design reasons.

Well, I would say it depends on context. In my specific case I have about 5
vectors that I am using and 3 of them will be static for most of the time,
one will be used like crazy(inserting, removing, manipulating,etc...) and
the other is about midway. I'm using S TL's vector for all of them. I
suppose that as long as its optimized for the "like crazy" case then
I'll be fine. I just tend to have a problem wasting memory and
performance for absolutely no reason except lazyness.

When I did my own vector class I allowed the user to change how much
extra capacity one could allocate when an overflow occured... maybe real
advanced methods would have some optimizing feature on this parameter to
find the best number(ofcourse I doubt there is one but...).

You might want to check out the STL list instead of vector. Especially for
the case where you're inserting and removing like crazy. I don't believe
it will exhibit the copy problem, and insertions and removals are speedier
(no need to copy chunks of the vector around to open and close space).

You'll have to balance that with the need for random access. (In other
words, if you always walk your arrays from start to end, a list would be
ok. But if you need to access random elements of it, a vector is faster
for that part.)

- Jay

 

[Default User]

I got an idea!! how bout you go read a book asshole?

You think this is the way to get people to help you?


*plonk*




Brian

 

[Jon Slaughter]

You might want to check out the STL list instead of vector. Especially for
the case where you're inserting and removing like crazy. I don't believe
it will exhibit the copy problem, and insertions and removals are speedier
(no need to copy chunks of the vector around to open and close space).

I did check out the list and thought about using it and actually changed it
back to vector for some reason. The list does have constant amortized
insertion and removal at begining, middle, and end but I think the main
problem was that I think I wanted to treat it as an array and I couldn't
really easily do that with the list. I'm not sure though, I might change it
later. I'm new to STL and don't know all the details about the different
containers and it might turn out that there is not really any performance
issues in my case using either one(but thats main thing I'm afraid of... if
it works find with vectors doing what I need to do then will turn the part I
need into a list and see what happens).

You'll have to balance that with the need for random access. (In other
words, if you always walk your arrays from start to end, a list would be
ok. But if you need to access random elements of it, a vector is faster
for that part.)

yeah, thats why I used the vector in the first place. If my application
performs well with the vector class I might try using a list and give it an
array like structure(which might make the list to bulky in the long run
though).

- Jay

Jon

 

[Jon Slaughter]

You think this is the way to get people to help you?

Help?? is that what you call it? I don't need that kinda "help". If you
think that if you are going to help someone that also gives you the right to
treat them as stupid then you have a strange version of help... a version I
don't want. Took mike like 6 posts to say the exact problem that is only
about 3 lines instead of all the bullshit he did trying to show his ego.

 

[Jon Slaughter]

Hmm.. an aversion to actually exerting yourself to learn something
instead of been spoon-fed everything? Funny that... _I_ prefer to teach
people who are actually wanting to learn, which many, many new/infrequent
posters seem to want to do.

spoon feed? you gotta be kidding? I've never seen so much egotism in one
sitting at the computer ever in my life. I've asked 3 questions in this
newgroup refering to STL(because of the shitty documentation) and you say
I'm being spoon fed? grow up! I guess I'm only allowed 1 post a year or
else I'm trying to be spoon fed? whats the exact number?


I GOT AN IDEA!!! IF YOU DON'T WANT TO HELP THEN SHUTUP AND DON'T!!!?!?!?!?!
Got damn that is a very simple fucking principle that seems to exscape some
of the most brilliant minds in the world(i.e. this NG).

It seems to me that the only reason some of you post is because you just
need to get your ego up a little more for some reason.

If you think I should go read a book then the response should be something
like

"STL is a complex and intricate language that is difficult to explain in
detail without writing a book, hence you might save some time and learn more
from reading these good books: XXX, YYY, ZZZ."

instead of

"Go read a book you dumbass cause your an idiot and lazy!"(which is
essentially what several of you are saying(well, one and others just hopped
on to join the fun(like kids))).

Fact is maybe I do need a book... how bout you buy it for me? how bout you
let me borrow all the books you have(cause I know you have a lot)? How bout
you be polite about it and also use a little NG etiquette? To hard to ask?
Have a bad day at the office? Wife left ya? Lost house in Kitrina? Mugged??

I GOT AN IDEA!!! IF YOU DON'T WANT TO HELP THEN SHUTUP AND DON'T!!!?!?!?!?!


Anyways, I've wasted to much time replying... just a waste anyways.

 

[Andre Kostur]

I did check out the list and thought about using it and actually
changed it back to vector for some reason. The list does have
constant amortized insertion and removal at begining, middle, and end

Yep... list's good for that...

but I think the main problem was that I think I wanted to treat it as
an array and I couldn't really easily do that with the list. I'm not

True. No indexing on a list, and it's not stored contiguously (at least,
not necessarily....)

sure though, I might change it later. I'm new to STL and don't know
all the details about the different containers and it might turn out
that there is not really any performance issues in my case using
either one(but thats main thing I'm afraid of... if it works find with
vectors doing what I need to do then will turn the part I need into a
list and see what happens).

I'd recommend picking up a copy of Effective STL by Scott Meyers.

yeah, thats why I used the vector in the first place. If my
application performs well with the vector class I might try using a
list and give it an array like structure(which might make the list to
bulky in the long run though).

If you want random access, you may want to look up std::deque as well....
but it's not good for insertions/deletions in the middle...

 

[Torsten Mueller]

You might want to check out the STL list instead of vector.

No, his problem is absolutely independent from the container type.
It's not even dependent on STL. It's simple C++.

T.M.

 

[Ram]

I'm having a problem allocating some elements of a vector then deleting
them.

Basicaly I have something like this:


class base
{
private:
std::vector<object> V;
//std::vector<*object> V;

public:

void addObject()
{
object *temp = new object;
V.push_back(*temp);

//V.push_back(new object);
}

It seems, you haven't read any good C++ book. Whenever you push
something on a vector, it creates a copy for itself. So the vector
doesn't contain the object which you _just created_ rather a copy of
it. After coming out of this function there's no way you can get hold
of the newly created object. Memory leak..

Instead you can just say

V.push_back(object());

void removeObject(index)
{
delete &V[index];
V.erase(V.begin() + index);

//delete V[index];
//V.erase(V.begin() + index);
}

delete &V[index]; // calls dtor
V.erase(V.begin() + index); // calls dtor again

Each object in the vector gets destroyed automatically when you
erase/clear it.There is no need for explicit delete call for each
element.

delete V[index];

is okay if the vector contains pointers to dynamically created objects
which need to be cleaned up. But note that it frees up the object
pointed by elements in vector and not the vector element itself,
there's no need to do that anyway..

};

the commented line is where I used the pointerized version. In the first
case the object's destructor gets called twice(I suppose because when I call
addObject the local variable goes out of scope(any way to prevent this) and
in the second case it doesn't get called at all ;/

I'd rather not use a vector of pointers though... I thought maybe I could
declare the object *temp as static but this seems to be kinda a hack... I
just need a way to say "don't call the destructor for this local object when
it goes out of scope" or something.

Any ideas?

Create a temporary local object (dynamically created objects are not
local) and push it on the vector. Don't call delete when you need to
remove them, simply erase will do.

HTH
Ram

 

[Karl Heinz Buchegger]

No, his problem is absolutely independent from the container type.
It's not even dependent on STL. It's simple C++.

He. he. A smart pointer could solve his 'problems'. But
then again I fear that he is telling us, that we don't need
to tell him, because he is the greates programmer in the world
and has used smart pointers before we were born and nobody
is going to help him with that information and ....