<div dir="ltr">Yes, precisely. I am not fully versed in the details (Axel, Philippe, please correct any inaccuracies), but essentially you can request an object to be written to/ read from disk and ROOT will look up the corresponding class and compute the appropriate disk format (for which it needs to distinguish between double/Double32_t for any members). ROOT use a C++ Interpreter/JIT (custom one for a very long time, transitioning to LLVM/Clang) for interactivity and introspection, so it has the ASTs for all classes in the system available.<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 26, 2016 at 12:36 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Can you elaborate on how this typedef information is used for I/O? Do you mean that it is used by some clang plugin that examines the AST, or something else?</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Jul 25, 2016 at 6:55 PM, Keno Fischer via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi Everyone,<div><br>We're trying to integrate the CERN ROOT framework with Julia, both<br>of which use LLVM/Clang for C++ interoperability. As such, we're hoping<br>to harmonize the versions of clang used in both projects. One major<br>obstacle to this currently is a patch that the ROOT folks are carrying<br>to support their I/O system which uses the structure of C++ classes to<br>determine the on-disk format. The patch as is isn't really in a form<br>that could be submitted upstream, but we're hoping to solicit some advice<br>to come up with a solution that would be acceptable to clang, and not<br>require any local code patches.</div><div><br>With that in mind, let us describe the problem:</div><div><br>As mentioned, ROOT uses the structure of C++ classes to determine it's<br>IO format. The one wrinkle to that is that sometimes the I/O storage<br>format and the in-memory format are not exactly the same. In particular,<br>ROOT has a</div><div><br>typedef double Double32_t;<br><br></div><div>where if this typedef appears in a struct that is serialized to disk,<br>it indicates that it should be stored with 32bit precision on disk, but<br>with 64bit precision in memory.</div><div><br>That's *only* for I/O information; for anything regarding symbols we<br>need these two to share their instantiation data.</div><div><br>I.e. we want to distinguish the types of D<double>::m and<br>D<Double32_t>::m (and also D<vector<Double32_t>>::m and D<vector<double>>::m) in</div><div><br>template <class T><br>struct D {<br>using type = std::remove_reference<D>;<br>T m;<br>static int s;<br>};<br><br></div><div>But &D<double>::s must the the same as D<Double32_t>::s; more importantly:</div><div><br>void f(D<double>);<br><br></div><div>must be called by f(D<Double32_t>{}). That is (IIRC) in contrast of what<br>the C++ committee discussed for strong typedefs. </div></div>
<br></div></div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div>