-
June 30th, 2006, 01:52 PM
#1
[RESOLVED] Storing socket classes in a std::vector
Hello!
I'm working on a small library that I'm planing to use in some future projects. I'm trying to write a couple of classes and functions that I believe could be very usefull in the future. One the things I'm writing is a wrapper for a berkley socket, but I've encountered some problems here. I've decided that there only can be one class per socket which means that the copy constructor and assignment operator in the socket class both destroys the right hand side when it has been copied (just like std::auto_ptr). This means that these functions doesn't take a constant references as they normaly would.
This hasn't caused me any major problems untill now. I've also decided that it should be possible to store the sockets that m_accept generates in a std container like list or vector. Problem is that push_back takes a constant reference to a object, my copy constructor and assignment operator doesn't. This generates a nasty error.
Code:
class socket_base
{
public:
...
socket_base(socket_base& rhs);
...
socket_base& operator=(socket_base& rhs);
...
If I would change the code above and add const the first compile error would go away but then it would complain because I'm trying to change a const object (rhs, reseting it). I think that I can use const_cast<T>() to get rid of that problem, but that doesn't seem to be a good solution...
So, what should I do? I wan't to store objects that has to be unique (no copies) in a std container, hmm, is this even possible?
Thanks in advance
/boolman
-
June 30th, 2006, 01:55 PM
#2
Re: Storing socket classes in a std::vector
As far as I know, it is strongly advised not to store objects with the copying semantics of std::auto_ptr in standard containers.
-
June 30th, 2006, 02:00 PM
#3
Re: Storing socket classes in a std::vector
I do not think that it is possible. One of the requirements for an object
to be placed in a standard container is that is is assignable and
copy constructable. In fact, the standard makes a point of stating
that std::auto_ptr can not be used in a container.
You could store pointers to your objects instead, although this is not
nearly as convenient.
-
June 30th, 2006, 02:14 PM
#4
Re: Storing socket classes in a std::vector
Thanks for the fast replies, I appreciate it. I suspected that it wouldn't be possible but I wasn't sure so I thought it was best to ask someone else. I have to find some other way to store the sockets then. Thanks again for the help.
/boolman
-
June 30th, 2006, 05:30 PM
#5
Re: Storing socket classes in a std::vector
Why not:
Code:
std::vector< boost::shared_ptr<socket_base> > my_sockets;
(boost::shared_ptr<> is a ref-counting non-intrusive smart point in boost. www.boost.org)
Hope this helps
-
June 30th, 2006, 07:08 PM
#6
Re: Storing socket classes in a std::vector
I've decided that there only can be one class per socket which means that the copy constructor and assignment operator in the socket class both destroys the right hand side when it has been copied (just like std::auto_ptr). This means that these functions doesn't take a constant references as they normaly would.
Why don't you make the copy constructor and the assignment operator private then? I'm pretty sure that would make copying and assigning your class impossible from client code.
The Strawdog's out in the street
-
July 1st, 2006, 04:33 AM
#7
Re: Storing socket classes in a std::vector
marten_range: Thanks for the tip. But there's two downsides with that solution as far as I can se it. The first is that the library will be depending on boost to compile, the second is that iterators to the std container will be a little confusing since accessing an iterator will give a ptr. Other than that it's a good idea which I will consider, thanks.
msg555: I could do that, but it wouldn't really change anything. My main problem is that I need a smart way to store sockets, mainly on the server side where the listener will be accepting new connections. But I can also see that it would be usefull on the client side as well if one would wan't connections to different servers.
-
July 1st, 2006, 10:41 AM
#8
Re: Storing socket classes in a std::vector
The first is that the library will be depending on boost to compile
While this will be true for some time, it is also true that shared_ptr is now part of TR1.
-
July 1st, 2006, 11:52 AM
#9
Re: Storing socket classes in a std::vector
Originally Posted by boolman
marten_range: Thanks for the tip. But there's two downsides with that solution as far as I can se it. The first is that the library will be depending on boost to compile, the second is that iterators to the std container will be a little confusing since accessing an iterator will give a ptr. Other than that it's a good idea which I will consider, thanks.
boost is in many ways a great library and I think that I gained alot of productivity after discovering boost.
A shared pointer: boost::shared_ptr
A better type-safe printf: boost::format
Performance bad due to excessive dynamic allocation: boost::pool
Tired of writing predicate classes for std::algorithms: boost::bind
Need to parse micro-syntax: boost::spirit
And so on.
The second point I don't understand at all (the one about iterators returning a ptr).
But if it's critical to you not to use external libraries and not having access to a tr1 compiler then I would consider rolling your own smart pointer. That is much prefered IMO than having naked pointers in a container.
If you would like to roll your own smart pointer then take a look at the interface of boost::shared_ptr<> those guys have put some serious thought into that interface.
Hope this help
-
July 2nd, 2006, 05:27 AM
#10
Re: Storing socket classes in a std::vector
It isn't critical that my library doesn't depend on external libraries, but it would be a good thing according to me. I believe that less dependencies makes it easier to compile, that might be wrong.
My second argument against boost (more against storing pointers) was poorly described, so I'll try again; It's my opinion that storing a pointer or an object that's supposed to act as a pointer in a std container produces a strange syntax when iterators are used. This is because I see an iterator as a pointer to a certain element in the container this means that I find it a bit confusing when accessing an element with the pointer-like iterator gives another pointer (or object that acts as a pointer). But then again, that's just what I'm thinking.
I guess that I have to look a little closer at boost. I'm pretty sure that I should use boost::shared_ptr<> instead of writing my own replica. It looks like a smart class.
Thanks again.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|