Re: Memory deallocation does not work.
Kai-Uwe Bux wrote:
It is dangerous - possible memory leak because vector<Test *> does not
own
the object pointer point to. Use any RAII memory wrapper (see RAII here:
http://www.hackcraft.net/raii ) instead of Test *
vector<auto_ptr<Test> > v;
That is _bad_ and much more dangerous than vector<Test*>: auto_ptr<> does
not satisfy the requirements for use in a container. Formally, you have
undefined behavior. In practice, you may run into trouble as soon as
vector
reallocates.
I have assumed you have write you own::auto_ptr<> with the same behaviour.
You can garantee at least runtime error is not sure, that std::vector<> does
usage of its data sequentally. The auto_ptr idiom (auto_ptr must move data
on copy) is so useful, that you can even replace std::vector<> by
own::vector<> if std::vector<> do not support auto_ptr idiom.
Anyway auto_ptr<Test> is just example of RAII wrapper.
or give each address (stored in vector<Test *>) to other object, which
will keep object.
{
auto_ptr<Test> owner(new Test);
vector<Test *> v;
v.push_back(*owner);
*owner is a Test& not a Test*. Do you mean
v.push_back( owner.operator->() );
Take address, i have meant address of Test for "vector<Test *>"
v.push_back(&*owner);
}
What happens at this "}"? The auto_ptr<Test> owner destroys the pointee.
The
pointer stored in v now is invalid. Any further use is undefined behavior.
At the point "v" is also destroyed. Lifetime of "owner" evidently must be
more than lifetime of "user" ("v").
What exactly are you trying to to? Should you be headed for automatic
memory
management, consider vector< shared_ptr<Test> > or a special container for
pointers that implements some ownership model.
The "shared_ptr<Test>" is very, very, very rare used. I even can not
remember when I used it last time, of course, if you have no suitable
auto_ptr, you must use any other wapper, for example "shared_ptr<Test>".
Try to inplement postfix operator ++, and you will see, that pferix ++ is
better.
"better" in which way?
In all ways. Operation "*p++=0;" has perfomans sence only if it is single
opcode for POD.
For POD also builtin increment p++ and ++p can subst each other and compiler
can generate "*p=0, ++p;" automatically if needed.
For non POD both increments p++ and ++p are implemened by different user
functions, so for non POD just write "*p=0, ++p;".
Should you think of performance, your advice amounts to premature
optimization: chances are that it++ is inlined and optimized to the same
code that ++it would generate.
Maybe, but not required by C++. When you say "it++", you tell to compiler,
that you want a copy of "it" returned after operations, else you change
semantic of post-increment. And process of creation of copy can be hard to
eliminate. Anyway, you must not create copies if you no need it and you must
not assume, that creation of copy can be eliminated if you not use result.
Avoid repeating function call "v.end()" if you are sure, that the
function
will always return the same.
Very likely, this is also premature optimization.
I do not know is "premature" bad or good, but you must not call function
many times, if you want only one value returned. You must not assume, that
unknown function do nothing.
--
Maksim A. Polyanin
"In thi world of fairy tales rolls are liked olso"
/Gnume/