Am Dienstag, 16. Oktober 2018 00:40:58 UTC+2 schrieb Christopher Warrington
- MSFT:
>
>
> By imposing these restrictions atop the gRPC++ library, we were able to
> simplify implementation of async services [8]:
>
class GreeterServiceImpl final : public Greeter::Service
> {
> public:
Hello Nathan,
Am Montag, 15. Oktober 2018 17:54:48 UTC+2 schrieb Nathan Prat:
>
> 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?
>
I have a mixture now of virtual inheritance and CRTP.
Basically, one
On Friday, October 12, 2018 at 1:53:15 PM UTC-7, Arpit Baldeva wrote:
> As for boiler plate, yeah, the async grpc version forces lot of it. So the
> implementation above and a custom code generator plugin can go a long way
> into making that process nice. For example, with a custom code
@Stephen , yeah, Async model is hard/non-intuitive to use. Only thing I can
say is that it allows the application to plug in it's own threading
architecture which I found super useful. My application is based off of
fibers and that won't work nicely/easily with the sync threading model. As
for why
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
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
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
Hello Christian
Am Freitag, 12. Oktober 2018 12:12:16 UTC+2 schrieb Christian Rivasseau:
>
>
> Then case to BaseMethod:
>
> bool ok;
> while (true) {
> if (!m_cq->Next(, )) break;
>
> MOOSE_ASSERT(ok);
> static_cast(tag)->proceed();
> }
>
The pure inheritance solution you suggested was not very
In that approach you would need to extend from a base class:
class MyBaseMethod {
virtual void Proceed() = 0;
};
class MyFirstMethod : MyBaseMethod {
void Proceed() overrride {
// do the work of first method.
}
};
class MySecondMethod : MySecondMethod {
void Proceed() overrride {
//
Hi Christian,
thanks for your response.
Am Freitag, 12. Oktober 2018 11:53:21 UTC+2 schrieb Christian Rivasseau:
>
>
> 1: It is indeed very much possible to have multiple methods, you just need
> to arrange for your own CallData object that will
> handle different methods. Depending on your
Hi Stephan,
1: It is indeed very much possible to have multiple methods, you just need
to arrange for your own CallData object that will
handle different methods. Depending on your style you could:
- Have a enum in the CallData constructor that describe which method is
handled, and switch on
11 matches
Mail list logo
