This is the encoded schema, in the format defined by `struct Node` in schema.capnp. Yes, it's used for reflection.
It's weird that they aren't omitted in lite mode. I can't remember if that was an intentional decision. That said, I think we should deprecate lite mode anyway, and instead recommend link-time GC. I think it's too hard to choose the right feature boundary for all use cases, and breaking things down into fine-grained feature flags creates too much combinatorial complexity. -Kenton On Sat, Mar 21, 2020 at 10:00 AM Vitali Lovich <[email protected]> wrote: > And to answer my own question, these symbols get stripped if you remember > to use -ffunction-sections & -fdata-sections when building and > -Wl,--gc-sections when linking if you don't use them. Still not sure I > understand the purpose is of putting the path to the file & the symbolic > constant name into the .cpp in the first place. > > On Sat, Mar 21, 2020 at 6:10 AM Vitali Lovich <[email protected]> wrote: > >> Bah. Still waking up. Was looking for hex instead of decimal. The text is >> in the b_e1f50d377b95ad12 variable & exported through the bp_ capnp::word >> pointer. >> >> I'm still not really clear on the purpose this table is serving. Is it >> just for reflection? Is there an expectation that the compiler will strip >> these as dead symbols if I'm not using them? >> >> On Sat, Mar 21, 2020 at 5:52 AM Vitali Lovich <[email protected]> wrote: >> >>> I'm trying to figure out where these strings are coming from but I can't >>> quite make it out. >>> >>> I have the following test.capnp file: >>> @0x95058ce93b4e8e0a; >>> const name :Text = "Foo"; >>> >>> > capnp compile -oc++ test.capnp >>> > g++ -DCAPNP_LITE -c -std=c++17 -o test.capnp.o test.capnp.c++ -I <path >>> to capnp headers> >>> > strings -o test.capnp.o | grep name >>> test.capnp:name >>> >>> If the test.capnp is in another folder that folder name appears as well >>> (e.g. if I do capnp compile -oc++ foo/bar/test.capnp I get >>> foo/bar/test.capnp:name in the compiled object file). >>> >>> I'm building as far as I can tell in LITE mode but I can't quite figure >>> out where these strings are coming from. They're not plain ASCII strings in >>> the generated code, nor can I find any obvious hex representation of this >>> string in the c++. Is there a way to strip these strings? What's their >>> purpose? >>> >>> Thanks, >>> Vitali >>> >> -- > You received this message because you are subscribed to the Google Groups > "Cap'n Proto" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/capnproto/CAF8PYMj0ZKqHPENR2DcYycU7LsCQSuX1me2jvR3UeevXVv25Ew%40mail.gmail.com > <https://groups.google.com/d/msgid/capnproto/CAF8PYMj0ZKqHPENR2DcYycU7LsCQSuX1me2jvR3UeevXVv25Ew%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAJouXQnfbRHqWKWiP5-UfaggrnFHR9ZT65-rgrfrfnRbzAyatg%40mail.gmail.com.
