<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Reid,<br>
<br>
> Does ROOT need a way to push the type sugar nodes through
template instantiation?<br>
<br>
Yes absolutely. This is the essence of the patch (for the
non-templated case indeed the information was already there).<br>
<br>
We do have users using all sorts of 'nesting' whether it is in the
template parameter or the types of the members.<br>
<br>
<pre wrap="">For example:
template <class T> struct D
{
using type = std::remove_reference<D>;
std::map< UseKeyAdapt<T>, ValueKeyAdapt<T > m1;
std::vector< T> m2;
// Or maybe even
// T<Double32_t> m3;
// T<vector<Double32_t>> m4;
static int s;
};
or
D< vector<Double32_t> >
or any variation thereof (the more nesting and indirection, the harder it is to recover the information with first order help). In all those cases, the user is expecting the underlying floating point to be stored on disk with single precision [Often the user need to carry the calculation in double precision to keep the errors as little as possible but at the end of the calculation, due to those errors, the result in only known with single precision and thus the user can safely reduce the size of the file in half by storing only the single precision]
Thanks,
Philippe.
</pre>
<br>
<div class="moz-cite-prefix">On 7/26/16 12:40 PM, Reid Kleckner
wrote:<br>
</div>
<blockquote
cite="mid:CACs=tyJjKbYmXUZ4K-QCJdHyuaff3sbjA4d2SJDfETetgcvZ_w@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">In simple cases, this information is already
available as type sugar nodes. Consider this AST dump:
<div>
<div><br>
</div>
<div>typedef double Double32_t;</div>
<div>struct Foo { Double32_t f; };</div>
</div>
<div><br>
</div>
<div>
<div>|-TypedefDecl 0xd3af50 <t.cpp:1:1, col:16> col:16
referenced Double32_t 'double'</div>
<div>| `-BuiltinType 0xd09d50 'double'</div>
<div>`-CXXRecordDecl 0xd3afa0 <line:2:1, col:28> col:8
struct Foo definition</div>
<div> |-CXXRecordDecl 0xd3b0c0 <col:1, col:8> col:8
implicit struct Foo</div>
<div> `-FieldDecl 0xd3b190 <col:14, col:25> col:25 f
'Double32_t':'double'</div>
</div>
<div>
<div><br>
</div>
</div>
<div>Template instantiation uses the canonical, desugared types,
though. You can see it from this dump:</div>
<div><br>
</div>
<div>
<div>typedef double Double32_t;</div>
<div>template <typename T> struct Bar { T f; };</div>
<div>template struct Bar<Double32_t>;</div>
</div>
<div><br>
</div>
<div>
<div>`-ClassTemplateSpecializationDecl 0xc3b490 <line:3:1,
col:31> col:17 struct Bar definition</div>
<div> |-TemplateArgument type 'double'</div>
<div> |-CXXRecordDecl 0xc3b688 prev 0xc3b490 <line:2:23,
col:30> col:30 implicit struct Bar</div>
<div> `-FieldDecl 0xc3b758 <col:36, col:38> col:38 f
'double':'double'</div>
</div>
<div><br>
</div>
<div>Does ROOT need a way to push the type sugar nodes through
template instantiation? I seem to recall that there are
reasons why it's hard to do that from an implementation
standpoint, but it would also help us get better diagnostics
when rinsing "std::string" through a template type parameter,
for example.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jul 26, 2016 at 9:58 AM, Keno
Fischer <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:kfischer@college.harvard.edu" target="_blank">kfischer@college.harvard.edu</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">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>
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jul 26, 2016 at
12:36 PM, Reid Kleckner <span dir="ltr"><<a
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org"
target="_blank">cfe-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>