If you insist on having the items in the combo box even after they were used you could try using their itemdata to indicate if they have been used or not.
-By default itemdatas are zero
-When your user hits the button, check the itemdata (CComboBox::GetItemData[^]) of the currently selected item, if any, if it is not zero, warn the user and don't continue, if it is zero, then use the item
-when using the item, set its itemdata (CComboBoxSetItemData[^] to 1 for example
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers don't kill programs, users kill programs <
> "It doesn't work, fix it" does not qualify as a bug report. <
You have to elaborate a bit better what you're going to achieve. In the term you spoke, the question is a nonsense.
In a "socket" world there must always be someone who connect to someone else who "listen". the first is a client , the second is a server.
Also "transfer between two or more" is a mis-concept.
That's not only a matter of grammar: networks are graphs, and graphs are made by nodes and arcs, and arcs are between two nodes. There cannot be segments with "two or more" ends.
What you're searching is not a "strange programming technic" but is an architecture made by client and server components placed on all the computers (the peers) that -after opening some sockets between some pair of them- exchanges some messages to let them understand what data is on what computer and let them transfer the "missing" data so that -after a number of iterations- all data are on all machines.
All this, is a "protocol" you have to design.
It's not a matter of TCP or UDP (they are just transport protocols) but of Checkpoints, Representation and Messages. In other ward "application level protocols".
The coding of the sockets is the last thing to be done, not the first.
where T is the type you're templating on. Usually what you do is have a copy constructor that takes the same parameters and then you implement operator= in terms of it (which can improve exception saftety as well if you do it right):
template <std::size_t N> my_class &operator=( T (&t)[N] )
my_class temp( t );
std::swap( temp. *this );
The important thing is getting the size of the array into the function.
Another way of doing this, which is common in the STL, is to specify a range of interators, in this case you could use a range of T pointers:
my_class &operator=( const T *begin, const T * const end )
I'd strongly recommend you grab a copy of "Exceptional C++" by Herb Sutter - it's got loads of guidance on how to write assignment operators.
The general concensus is don't inherit from an STL collection - they're not designed for it.
The two ways I'd recommend going about extending an STL collection is either bundle it up in another class (which you've done) OR just write free functions to do the extended functionality. From your example it looks like you want a geometric vector and not a collection of doodads that might or might not have some geometric relationship.
Incidentally if you want to continue using containment the way you have make the std::vector private. You really don't want a class exposing data through it's public interface, it's really hard to test and some idiot will maul it for you - even if that idiot turns out to be you several months down the line when you've forgotten what you did.
it might work, but in general you should avoid inheriting directly from STL containers, if you can. the reason is that these containers do not have virtual destructors, and that may expose you to memory leaks.