Re: Complexity of new hardware

Will Vale wrote:
> On Sun, 19 Apr 2009 03:03:27 +1200, Jarkko Lempiainen <[email protected]>  
> wrote:
>   
>> All I have is something like:
>> struct foo
>> { PFC_MONO(foo) {PFC_VAR3(x, y, z);}
>>   int x, y, z;
>> };
>>     
>
> That's admirably brief! I assume you're generating code rather than data  
>   

> // foo.h
> struct foo
> {
> COMPOUND(foo)
>
> int x, y, z;
> };
>   

> // foo.cpp - essentially generates const member_t foo::members[] = { ... };
> RTTI(foo, MEMBER(x) MEMBER(y) MEMBER(z))
>   


This is exactly what I want to avoid -- the members are listed twice, in 
two different files! Version mismatch hell. (The Despair engine write-up 
has this same problem).

You can actually use some template trickery to hoist the RTTI() / 
MEMBER() parts into the struct itself.

This allows you to write something like:

  struct foo {
       int x, y, z;
       RTTI(MEMBER(x) MEMBER(y) MEMBER(z))
  };

That's all there's to it. No additional code, cpp files, or anything 
like that needed (except for whatever runtime support you'll want, like 
stream handling, custom type marshaling, etc).

members() gives you a list of the members; info() gives you information 
about the struct itself. I put an implementation (including a program 
you can compile and run) up for discussion at 
http://www.enchantedage.com/cpp-reflection if you want to take a look. 
Here's a main() program that prints the information about the type "foo":

int main() {
  printf("type: %s\n", foo::info().name());
  printf("size: %ld\n", foo::info().size());
  for (size_t i = 0; i != foo::info().memberCount(); ++i) {
    printf("  %s: offset %ld  size %ld  type %s\n",
      foo::info().members()[i].name,
      foo::info().members()[i].offset,
      foo::info().members()[i].type->size(),
      foo::info().members()[i].type->name());
  }
  return 0;
}

And here's the output:

type: foo
size: 12
  x: offset 0  size 4  type i
  y: offset 4  size 4  type i
  z: offset 8  size 4  type i

You probably want to wrap those ::info().members()[i] accessors in some 
nice readable macro, like TYPE_NTH_MEMBER() or suchlike, but I think 
this provides the optimum implementation in the sense that it relies 
only on static init (no dynamic memory allocations) and it doesn't 
require member definition to be separate from declaration (it's all in 
the .h file).
If you want editor information, you can easily push that into the 
MEMBER() macro.

It's still repeating yourself, though.

Sincerely,

jw


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list