Hi, How can you use CRTP? I tried it this way, but after `cq_->Next` you can't static_cast to a templated class. Or am I missing something?
Anyway, I had the same problem, and using inheritance with a CallData base class, and an abstract method "Process", I have pretty much no boilerplate. The base class main logic is in a "Process" method, which calls the abstract methods(Process, and some others) The only boilerplate is the need to call the "Proceed" method of the base class in each derived class ctor(because we can't call a pure virtual from a ctor). With this, HandleRpcs basically contains only 2 lines: - cq_->Next(&tag, &ok) - static_cast<CallBase*>(tag)->Proceed(); On Monday, October 15, 2018 at 11:05:54 AM UTC+2, Stephan Menzel wrote: > > Am Freitag, 12. Oktober 2018 22:53:15 UTC+2 schrieb Arpit Baldeva: >> >> Feel free to take a look at this thread - >> https://groups.google.com/d/topic/grpc-io/T9u2TejYVTc/discussion >> >> I attached a C++ implementation of the RouteGuide Async server there. >> That code avoids lot of boiler plate and integrates nicely with any >> threading architecture you want. The code was written more than 1 year ago. >> I have a variation of that (mostly for hooking up our custom application) >> but the fundamentals are the same (meaning that sample code works in >> production). >> >> > Thanks for posting, I had found this already and took a great deal of info > from it. > Gotta say though, as much as I like the neat sync interface of gRPC, the > async variant comes as a bit of a disappointment to me. Specifically the > Next() function. The way I see it, the system already knows the type of > call coming in, as it obviously instantiates the correct call object > fitting to the RequestMyMethod() call. Why it chooses to discard that type > information entirely and hand out a void * without any hint is beyond me. > Some kind of gRPC inherent mechanism to know the type seems imperative to > me. Perhaps an easy to use base class for the calls? If you excuse my > criticism, looking at the code now, I can barely see the advantage of using > gRPC at all. I have multiple other interfaces in my system that use pure > protobuf request and response objects and send them over all kinds of > interfaces. For the network services I have used sync gRPC on top because > it gave me a nice interface and the method resolution. Without these > advantages, I might as well go for a plain old beast or asio async socket > and send protobuf objects back and forth. > > Still, thanks for your help tackling this! > > Stephan > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c434fa5b-76c0-4e1b-a495-9da8f694513a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
