From: jklowden@speakeasy.net
On Thu, 16 May 2013 09:59:59 -0700 (PDT)
"Peter C. Chapin" wrote:
> On Thu, 16 May 2013, James K. Lowden wrote:
>
> > Many people wrongly assume that's because C++ is compiled. It's
> > not. It's because of *how* it's compiled. It's because the C++
> > compiler discards the metadata, or makes it available only in
> > nonstandard ways to the debugger, rather than to the language
> > itself.
>
> It sounds like you are asking for a standard facility for doing
> reflection in C++.
Yes, except that "reflection" means different things to different
people. One day, I would like to see the standard library support
automatic serialization of user-defined types. Today, I'm only
lobbying for such changes to the language as would be required to make
that possible.
> The language does have a few bits and pieces of that feature now (I'm
> thinking of RTTI, for example)
Yes.
> but that's clearly a shadow of what full reflection support would be
> like.
Depending on "clearly" and "shadow", maybe. I submit it's already
being done for debuggers. What we're missing is language support for
access to that same information.
There are some difficulties. From what I know of the GNU debug
symbol format, the problem of program metadata hasn't seen the hands of
a data analyst. I wouldn't want to see that become the standard. At
best it's input to a first draft.
> I wonder, though, about the runtime costs such a capability would
> impose and if it could be implemented in such a way as to have zero
> cost for the many programs that don't need it.
It's a fair question, and I have a ready answer. :-)
First, like RTTI, it could be optional. Not even every program *I*
write needs reflection.
Second, it's much less intrusive than RTTI. RTTI changes how a
program behaves. Program metadata are purely passive. Now, that
doesn't mean you can treat it like debug symbols and shear them off
with strip(1), because they might be referenced. But it's hard to see
how providing syntactic access to the metadata would affect execution
efficiency.
Well, actually there's some reason: If we say the program will make
pointer extents accessible, there is some small overhead. For example,
the size of a static character array isn't recorded in the executable
today. It's known to the compiler, and the compiler uses that
information while determining the layout of the program text, but then
discards it. Similarly on the stack for automatics. The "don't
pay for what you don't use" folks will be all over that like white on
paper. See point #1. ;-)
Third, it's hard to make a case for highly efficient metadata. We're
supporting I/O after all. Metadata could reside at the end of
the executable and not even be paged in unless referenced.
Perhaps it would possible to intelligently emit only referenced
metadata. I don't know, and we don't need to know that at this stage.
The questions today are feasibility and utility and, as ever,
efficiency. To feasibility and efficiency I believe I've provided
reasonable arguments or, if not, am prepared to keep trying.
As to the general utility, that's certainly a matter of opinion, fodder
for the usenet and beyond. To me it's clear I/O matters: all
algorithms have input and output, and all applications, sooner or
later, exchange data with external sources, be they files or databases
or other network connections. If I/O didn't matter, Larry Ellison
wouldn't be a household name, and XML wouldn't be the bane of every
programmer's existence.
A general serialization library for C++, even one that wasn't 100%
machine-independent for void*, would be a huge boon to C++
programmers. For that ever to become a reality, we need changes to the
language.
--jkl
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
