Invoking of Inspector function,

[Saravanan Palanisamy]

Hello,

I started working with C++ Actor framework very recently for one of my projects.  I came across type inspector example. I could not understand when and where is the serialization is happening in the example by invoking inspector function?

[Dominik Charousset]

Hi,

> I started working with C++ Actor framework very recently for one of my projects. I came across type inspector example. I could not understand when and where is the serialization is happening in the example by invoking inspector function?

do you mean the examples under examples/custom_type?

Generally, CAF uses the inspect-API for string conversion of user-defined types, serializing messages into a byte buffer for sending them over the network, or deserializing received messages from received bytes. The serialization usually takes place in CAF’s networking component. In-process communication in a single actor system does not trigger any serialization.

Hope that helps,
Dominik

[Alexander Gagarin]

Hi, Dominik!

In-process communication in a single actor system does not trigger any serialization.

But still, all types that are put into messages required to be inspectable/serializable, right? I suppose this is due to stringification inspector always trying to at least validate convertion of every passed message to string.

For example, I found that if I whitelist some of my types as unsafe and remove (make inaccessible) serialization code for them, then stringification inspector still tries to inspect 'em and fails with super-magic compile error that originates from header (!) files =)

[Dominik Charousset]

> In-process communication in a single actor system does not trigger any serialization.
>
> But still, all types that are put into messages required to be inspectable/serializable, right? I suppose this is due to stringification inspector always trying to at least validate convertion of every passed message to string.
>
> For example, I found that if I whitelist some of my types as unsafe and remove (make inaccessible) serialization code for them, then stringification inspector still tries to inspect 'em and fails with super-magic compile error that originates from header (!) files =)

Uh, you shouldn’t get compiler errors. The stringification inspector should fall back to producing “<unprintable>” strings for everything not offering inspect() or to_string(). Do you have a minimal example that reproduces a compiler error? That’d be great!

Dominik

[Alexander Gagarin]

Uh, you shouldn’t get compiler errors. The stringification inspector should fall back to producing “<unprintable>” strings for everything not offering inspect() or to_string(). Do you have a minimal example that reproduces a compiler error? That’d be great!

I double checked the code and have to say that I wasn't correct.

The type I had troubles with is `boost::uuid`. And I actually didn't whitelist it, just removed headers with it's custom serialization code.

Then, as far as I understand, stringification inspector treats UUID as 'container' (because it provides `begin/end`), tries to unwind it and fails at line 263 of 'data_processor.hpp' on this sentence:

`

xs.clear();

`

because `boost::uuid` don't have `clear()` method.