Re: c++ reflection (was (no subject))

I think you misunderstand my complaint.

First, I'm not suggeting using ugly macros. Using ugly macros is what we
have to do because the compiler doesn't give us the information we needs as
a standard part of the language. We've even had type_info for 20 years,
which would be a pretty decent place to put this information, but it's
almost totally useless the way it currently gives you no useful information!

I'm suggesting we delay C++0a by another year and fix this problem. (Not
gonna happen, but that's what I'm suggesting) If we did, ugly macros would
be a thing of the past.

Second, I'm not saying that stepping into generated code is so bad. What I'm
saying is that you *can't* step into the code that generates the code in the
first place. (A bootstrappy kind of micro-code-generator used for this
purpose I released as an illustrative sample a few years ago finally ended
up here: http://www.enchantedage.com/node/56 )

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Sat, Jun 19, 2010 at 3:16 PM, Tom Plunket <[email protected]> wrote:

> Jon Watte wrote:
> >> Have you thought about declaring your reflectable structures outside of
> >> c++, then letting your build process create the c++ structure for you as
> >> well as any meta-information you like to have in the runtime ?
> >
> > I think I explicitly said "without code generation" somewhere above in
> this
> > thread.
> > I've used extensive IDL and other code generation systems. They have
> their
> > strengths, but also their weaknesses, which have been pretty exhaustively
> > listed elsewhere.
> > The problem I'm kvetching about here is that the compiler really has all
> the
> > information needed -- it HAS to have it -- but the language and runtime
> > exposes no way to get at that information, which unnecessarily hamstrings
> > the set of solutions possible while staying within the language.
> > Staying within the language is a good idea, because it makes everything
> from
> > dependency checking to source-level debugging easier. Ever tried to debug
> > from your source code into the IDL-generated code, only to realize that
> the
> > bug might be in the IDL generator itself, and you can't really "step
> into"
> > or "set breakpoint" in that? That's one of the problems of
> pre-generation.
>
> What is easier to debug, generated code that is compiled that you can
> step through, or expanded macros?
>
> My vote is for the generated code.
>
> Yes, the compiler has the information, and it's irritating that the
> language was designed 40 years ago without the consideration that this
> sort of data would be useful to make available to the program itself,
> but to compare a possibly buggy IDL compiler to possibly buggy macros,
> I don't see how you can compare them in the way that you do.  If the
> IDL compiler is intrinsic to your build setup (and does not require a
> built version of itself to be able to be built itself), then how is
> fixing bugs in that any different from fixing bugs in the macro
> madness?  They both require inspection of intermediate files, and only
> the IDL-based intermediate file can have nice formatting...
>
> -tom!
>
> --
>  _______________________________________________
> Sweng-Gamedev mailing list
> [email protected]
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com