two clients communicate to each other on top of a message layer
in the message body, I need include a field pointing to any data type
From client A, I send the field as a shared_ptr<TYPEA> to the message layer.
I define this field as a shared_ptr<void> in the message layer.
But how can I convert this field back to shared_ptr<TYPEA> in client B?
Or should I define shared_ptr<void> in message layer as something else?
Thanks
If you're using boost::shared_ptr then you can use the various XXX_ptr_cast<>() functions (static_ptr_cast, dynamic_ptr_cast...).
If you're using the MSVC 2010 version I haven't been able to find an implementation of these functions. They may not be part of the standard.
If the shared_ptrs & pointed-to data aren't held in memory common to both clients (e.g. the clients run in different processes, and the data isn't in shared memory), the pointers from one client won't be valid for the other. You'll need to construct a representation of the pointed-to data and transmit that. The receiver constructs its own copy of the data in the messaging layer and passes a shared_ptr to that up to the client.
If all possible data types that you plan on passing between clients inherit from some common base class, you can simply include a flag variable in the base class which indicates which derived type the current instance is. Pass base-class pointers between clients, and then use dynamic_cast to downcast the base pointer to the appropriate derived type.
Related
Coming from mostly C#, I am going through the exercise of understanding how best to manage object ownership in c++, so bear with me.
I have a Bus class which has a method called OpenChannel that returns a Channel object. The Bus keeps a list of channels, because if the Bus is closed, all channels should be closed. If an individual channel is closed, the bus remains open, but the channel should be removed from the Bus open channel list.
The way I planned on handling this was as follows:
std::unique_ptr<Channel> Bus::OpenChannel(int channel_number){
int handle = //call dll to open channel
auto chnl = std::make_unique<Channel>(this, channel_number, handle);
this->open_channels_.push_back(chnl);
}
void Bus::OnChannelClosed(Channel channel){
//remove from open_channels_
}
and then in the channel class, there is a close method
void Channel::Close(){
//make call to dll to close channel
owning_bus_->OnChannelClosed(channel);
}
What I'm wondering is two fold -- first, for the bus being passed to the channel object's constructor, should I just use a regular pointer, or should I use a smart pointer? If a smart pointer, does it make sense to wrap "this" up in one? And two, it doesn't quite sit right with me that the bus has a public OnChannelClosed method that is exposed for any object to call. This could result in the Bus removing the channel due to a call from a non-channel object. I could make the Channel a friend of the Bus class, but my gut feel is there may be a better way.
edit:
based on some responses I figured I'd add more info. "Bus" wraps up a dll which can be initialized and uninitialized (and reinitialized again if required). When it is uninitialized, all open channel handles go invalid per the docs. I am starting to think my library wrapper should have an Initialize, Uninitialize, and "CreateChannel" method which returns a Channel which can then be operated on. Theoretically, I will never be uninitializing the bus while channels are open. But should it happen, I was hoping to gracefully manage that. However, if I'm exposing channel, there is a of course the possibility the channel object being used in another location goes invalid if the bus is uninitialized.
I think that the best way to handle this if possible is not allow the bus to be uninitialized as long as there are open channels. Maybe a shared pointer can be used to manage this? Or maybe channel shouldn't be exposed at all and Bus methods should all take a channel number as an input, and then the calls will be delegated to the correct channel.
With regards to your first question:
What I'm wondering is two fold -- first, for the bus being passed to
the channel object's constructor, should I just use a regular pointer,
or should I use a smart pointer?
Smart pointers are incredibly useful because they remove the need for manual memory tracking. In the example you provided, your Bus class only needs a pointer to a Channel so it can keep track of which Channel instance contains it. In this context, there is no need to use a smart pointer, since all bus instances should be destroyed before the channel that holds them.
And two, it doesn't quite sit right with me that the bus has a public
OnChannelClosed method that is exposed for any object to call.
If all that you're concerned is that no other class other than Bus should be able to invoke the method OnChannelClosed, you can always make Bus a friend class of Channel, and set the method OnChannelClosed as private or protected.
It feels however, that you are trying to manage memory with two different approaches here, though:
1- You want Channel to keep track of all Bus instances, and
2- You want to use smart pointer so you don't need to keep track of memory at all.
One thing I noticed is that Bus::OpenChannel stores a unique_ptr inside a vector, and, (presumably) returns that same unique_ptr as the output of the function. This is not possible. As the name suggests, unique pointers can only be owned by one object. If you need multiple objects to have access to the pointer, you should use a shared_ptr instead.
I send data to and from my server.
I create a message, set the type (enum) and the objects that need to be transferred.
The message is sent as a compressed JSON string.
When I receive it I parse the message, instantiate the object and start to fill it. When I need to instantiate the data transferred I use a map that contains the name of the class as a key and a pointer to the constructor as the value.
All this works fine but now I need to consume the message and do what needs to be done with it (send an answer, write to the DB, etc).
What is the best way to do that ? For now, I check the type of the message and get each of the transferred object. But I don't know what class they are (not explicitly).
Should I dynamic cast everything (cost a lot for not much) ? Should I treat the data with the hope it will always be in the same order. Or should I store the objects as a map (with the name or a enum as the key) and cast it correctly then ?
I know that dynamic casting should not be done if possible. But here I am wondering, is it worth it to have a switch from the beginning and create the correct object and feed it the JSON ? For now the entire message is reconstructed dynamically without any problem and my message manager will handle the treatment, should I change that ?
I agree with Peter.
I'd probably use a "sniffer" function that returned an enum class JType mapping the JSON to the associated type of the message.
Then use that JType enum in a switch/case block to call the appropriate factory function which would return a std::unique_ptr.
Failure to parse would throw an exception, rather than return a unique_ptr with a nullptr.
You'd have one factory for each associated class type.
You'd have a sniffer function that would determine what type the JSON represented, returning an enum.
The happy path would be JType e = sniff(message);, and if (e == JType::Foo) std::unique_ptr<Foo_t> foo = FooFactory(message);
Throwing an exception from the factory would only occur in the exceptional case of the message and the factory disagreeing as to what should be in the message.
No list of base_class objects, but the enum class JType would have a 1:1 mapping to the classes.
Think of the JSON as being the state information "dehydrated", and the factory functions "rehydrate" the state data into new objects. The factory functions could be static class functions as part of the class, or could be freestanding functions.
Hierarchies are for polymorphism, and this isn't that situation.
i wrote a program for a pic32mx575f512h in C++. the processor has 6 uarts and the program routes the uart packets from one to another. the program is written using two generic classes. a receive class and a send class. when the objects for these classes are declared a struct with settings is handed to them to make them unique.
to ease interconnecting these objects the receive class is handed an array of send class pointers. when a message arrives say for uart "one" on any of the other uarts the receive class calls the appropriate send class from the array by using the address as the array index. for example:
send_pointer[received_address]->data_put()...
the code is tested and works well.
now i need to expand the code further to add debugging through usb. the usb stack is taken care of i just need a way to pass data from the receive class to the send class including a function for the usb. where i'm struggling is that the usb send handler is completely different from the the uart send class. i would like to add another member to the array of send pointers but that's not possible. i've tried making an array of function pointers but C++ won't allow storing the member of a class in a function pointer.
is there another way i can do this so i can still use the address as an index of where the message needs to go?
In order to execute methods of a class, you either need an instance, or the method has to be declared as static.
Search the internet for "c++ FAQ pointer to member function".
You may need to redesign you program or use a Factory Design pattern.
My question is probably just a simple question about using the c++ language, but the background/motivation involves networking code, so I'll include it
Background:
I have an application with a bunch of balls moving around according to various rules. There is a server and a client that should be as synchronized as possible about the state of each ball.
I'm using Google's Protocol Buffers to create message objects that allow the client to set up or update each ball. Balls have different states, and each ball might need to be transmitted to the client using a different message class generated by GPB. For example, one type of ball updates its position using a fixed acceleration vector, so the message corresponding to that type of ball would have position,velocity, and acceleration.
I want to store these message objects in a data structure that organizes them by position, so that clients can access only message objects that are nearby. But each message has a different class type, so I don't know how to correctly put them all in a structure.
If I were hand-writing the message classes, I would make them all be subclasses of an abstract Message base object, with an enum type member. Then I would store the messages as unique_ptrs to the abstract class and then do a static cast by the type enum whenever I needed to work with each object individually. Ideally, since I need to serialize the message objects (they each have a serializeToOutputStream(..)) function, I would make this function an abstract member of the base class and have each of the particular message classes override it, so that I could avoid a cast in some situations.
The problem is that I am not hand-writing these classes. They are generated by google's compiler. I'm sure such a situation has arisen before, so I wonder how I should deal with it in an elegant way, if there is one.
Language-Only Version of Question:
I have a fixed set of generated classes A,B,C,D... that all have a few common functions like serializeToStream(). It would be very tedious to alter these classes since their sources are generated by a compiler. I would like to store unique pointers or raw pointers to these objects in a data structure of some kind, like an std::map or std::vector, but I don't know how to do this. If possible it would be great to call some of the functions that they all have without knowing which particular class I was dealing with (such as if I call the serialize function on all of them in a vector).
There is not good way to solve your problem. Only nasty haks. For example you can store pointer to object and pointer to method of some fake type in your map. But then you must cast your classes and pointers of its methods by reinterpret to this fake type. You must remember that all who will read that your code will scold you and may be better to find the approach to create common base.
I will describe the problem as simple as i can.
alright, here goes the problem;
Lets suppose we have a com component class with 3 of constructors where a constructor takes at least two of parameters. As we already know we instantiate the components via QueryInterface rather calling the classes' constructors therefore it seems it is not possible for a com client to set the constructor's parameters.
alright, here goes the question;
What is the best practical approach to allow a com client to instantiate a com component which requires at least two of parameters to be initialized?
Instead of directly returning object instances, your QueryInterface call can return factories. For example, instead of:
// implements IMyClass1 interface
return new MyClass1();
You would do:
// pointer to member that implements IMyClassFactory interface
return &m_myClassFactory;
// this could also be a static class instead of an object instance
The IMyClassFactory interface would have a create method that takes in the constructor arguments and returns the ultimate MyClass1 instance.
If its a pure COM component, the standard way of handling this is to implement Initialize(foo, bar) methods instead of separate constuctors and then call that immediately after COM instantiation. If the object has no sensible default state, then you can make it a member variable (pointer) in a COM object. From that COM object you will have your Initialize(foo, bar) functions. In each of these initialize function the correct version of your object will be instantiated. Every pass through function in your COM wrapper will need to check that your object is not NULL and return an appropriate HRESULT if it is.
One option would be to use a factory object; the creation functions would be all on the (stateless) factory object (on a different interface, of course), and pass back an initialized instance of the real object.
When I write COM servers, I don't usually allow my components to be instantiated by CoCreateInstance. Instead I export some bare functions (these can be described in IDL as well inside a module) from my DLL which accept the constructor parameters and return an interface pointer to the newly created object in an output parameter.
I like both Ates Goral's answer and Steve's and have upvoted both. Normally I would leave it at that, but I feel that this time I have to spell out my full take.
The "best", "right", "purest", "canonical" way to do this is undoubtely the factory pattern, as described by Ates. If you want to create a clean API, that's the road, hands down.
But... most of us are not busy creating public APIs for commercial products. For small internal projects with non-public APIs, I just want to get the job done. Having to implement an extra object just so I can expose a single factory method sounds rather overkill (particularly in C++). In most practical cases, I would just go for an Initialize(foo, bar) method as described by Steve. I would then make sure that every non-trivial method checks to see if the object has been initialized and returns a failure HRESULT if not.