Is there a convenient way to peek at the size a message will take up on the
wire? My thinking is to create a custom output stream that I
`capnp::writeMessage` to that just sums everything but I feel like this
could be done more efficiently within capn'n'proto, just couldn't find
anything like t
NVM. Apparently I'm blind when reading the documentation/looking at the
dir() of the message. `.copy()` is the thing.
On Monday, April 27, 2020 at 1:44:45 PM UTC-7, Vitali Lovich wrote:
>
> Let's say I have some capnp schema.capnp file:
>
> ```
> struct Foo {
>bar :group {
>someValue
Let's say I have some capnp schema.capnp file:
```
struct Foo {
bar :group {
someValue @0 :Int64;
}
}
```
In python I do something like:
```
import capnp
import schema_capnp
fp = open("some_capture.bin")
obj = schema_capnp.Foo.read(fp)
copied_bar = copy(obj.bar) <--- Here
```
I'm
What's the proper way to get the ID associated with a struct at runtime?
Will accessing this pull in the entire dynamic schema? I'm hoping I can
just get the ID with minimal overhead.
Thanks!
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To
I don't see this explicitly called out in https://capnproto.org/cxx.html but
I just wanted to double-check that something like this:
capnp::MallocMessageBuilder builder;
auto msg = builder.initRoot();
auto nested = msg.initSomeStruct();
for (int i = 0; i < 10; i++) {
nested.setField(i);
I was wondering if it's possible to derive one constant from another?
Something like:
struct Foo {
a @0 :Float32;
b @1 :Float32;
};
const oneWay :Foo = ( a = 1.0, b = 2.0 )
const orAnother :Foo = ( a = .oneWay.b, b = .oneWay.a )
And of course expanding this wondering if basic math operation
Is there any support for strong type aliasing? I see it on the roadmap but
I'm guessing no progress has been done on that front?
The specific use-case I'm dealing with is time & wanting to ensure the
correct units and epoch can be used (e.g. define a function taking a
monotonic_clock::timepoint
Hi,
New to cap'n'proto, but coming from deep familiarity with protobuf/thrift.
I was wondering if cap'n'proto needed the decomposure like protobuf into
parallel lists to reduce the wire overhead?
The use-case is something like (hopefully getting the syntax correct
writing it blind):
struct Ve
