Hello..
I have a sockclass and I want to store pointers to sockclass in a c++ list... Now what would be the right way to do this?
Is this okay?Code:list <sockclass *> sockets; sockclass *sock = new sockclass(); sockets.push_back(sock);
Hello..
I have a sockclass and I want to store pointers to sockclass in a c++ list... Now what would be the right way to do this?
Is this okay?Code:list <sockclass *> sockets; sockclass *sock = new sockclass(); sockets.push_back(sock);
Yes that is ok, just dont forget to delete them manually when you want to destroy the list.
STL Util a small headers-only library with various utility functions. Mainly for fun but feedback is welcome.
Yes, because it does what you intend.
But no, unless you are absolute sure those pointers will be deleted correctly when sockets goes out of scope, when you explicitely discard of sockets, or when you discard one of those pointers. As is, it wil be hard for you to delete them at the correct times. Although, depending on what you are going to do with sockets, I may be wrong.
In general the idea is to use smart pointers to take care of your sockclass*.
Here, http://www.informit.com/articles/art...p?p=31529&rl=1 for what it seems a nice tutorial in developing your own smart pointers.
Also Boost::shared_ptr if you plan to install it (or have already).
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Sounds interesting, I never really thought of 'smart pointers'.
Would this simple auto_ptr clean after himself, if I use it as a smart pointer for c++ list?
auto_ptrs will clean up after themselves, yes, but DO NOT store auto_ptrs in standard containers. The copying semantics of auto_ptrs are not compatible with what is required by the standard containers. Use smart pointers that do have normal copying semantics.Would this simple auto_ptr clean after himself, if I use it as a smart pointer for c++ list?
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Sorry, but what does 'normal copying semantics' mean?
STL containers allocate and reallocate and destroy and recreate their contents.
When autoptrs are copied to antoher loaction and the like your pointed data might get deleted along the way???
Would you guys recomment boost? I've never been using it before.
Yes, boost is useful. It sort of functions as a testbed of ideas for libraries that may be included in the C++ standard library.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Does boost have implementation of its own list, vector (like stl) or you just use it as an addon with stl?
It can be used in tandem with the C++ standard library, since most of it was designed to build on the standard library.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
It means if you have code like this:Originally Posted by l2u
If it has normal copy semantics, A and B should be, to the user of the class, interchangeable. That is, the program can't tell them apart.Code:MyClass A; MyClass B; // other stuff here A = B;
That would NOT be true of auto_ptr, because A = B; will cause A to point where B used to, and B to point to NULL.
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.
>> Does boost have implementation of its own list, vector (like stl) or you just use it as an addon with stl?
It is all meant as an addition to your own standard library implementation that comes with your compiler (or that you get from somewhere else). They do have containers that are different than the STL list, vector, etc. Those are called ptr_vector, ptr_list, and others that handle the memory management for you and might be slightly better options than a vector or list of shared_ptrs.
shared_ptr has already been "standardized" in something called TR1. So you can be pretty confident that if you use it now it will still be available as you switch compilers and platforms in the future.