I came on here to mention offsetof, though I see that you've found that. Instead of trying to get fancier, I would start out by implementing your original idea. Maybe it'll be a little annoying to type class names over and over, but it'll get something working that you can refactor:
Thats what I'm doing at the moment. Refactoring is quite a pain since the amount of components for my 2D + 3D stuff is quite high, though I think I'll even merge some components here and there... anyway, it works out quite well that way for now, and got me rid of ~1500 LOC, mostly in gui/editor-related stuff, which is about 10% of my 2D-plugins. I'm glad I have a 2D project to test first & refactor based on that though, because there is just way more stuff going on in the 3D departement, so it would take way longer to get things even to work, not talking about refactoring...
I also wanted to mention, for anyone who might stumble up to this, that you don't have to perform offsetof twice for nested classes, you can just say
Thats actually interesting, I'm not sure if its not even a bit complicated for what I'm trying to do, since I'll never have such things as multiple interheritance etc... Everything that I expose via those "interfaces" is going to be POD, too, at least for the moment. I'll keep it in mind though, I might even want to use this to improve the type system of my visual scripting system, while I'm at it, I think it would fit there quite well.
Actually, if you're using any of the latest Visual Studio versions, there should be a local database file with your project that contains metadata about your project. Usually, this database is used for intellisense, but you can connect to the database externally and perform SQL queries against it. With this, you can query information about your project, classes, and its members. Extending this, you could write a PowerShell script to automatically generate reflection information from all of your classes. Then you could add this to your build process, and... well, I'm getting ahead of myself, here. smile.png
Uh, I really wouldn't want to rely too heavily on Visual Studio for stuff like that. The plugins should work independately, which could be achieved by generating this reflection information to a personal file format... but I quess thats a bit overkill, though its neat to see whats possible I also kind of like the idea that it would work fully automatically, without having to write a single line of code for each component.
You might want to look at doing this in a more C++ like manner without the potentially difficult to deal with side effects of pointers into protected/private data. The way I went recently was to implement a system like this using std::function. Basically using accessors I could bind up access in nice little objects which worked with my serialization. So, for instance, in your given example, I wouldn't expose x, y, z separately I'd simply bind the accessor to the vector as:
Hm, definately interesting, haven't looked at it that way before. There is at least no problem with private data here, because components are required to have all their data public for the systems to work with them. They are in fact just "POD"-data containers with a few helper functions brought in by the base classes. So there wouldn't be any substantial problem with direct memory exposure, at least none I can think of. I actually do have a few attributes that use a "dirty"-flag when they are changed, this would actually be a good point for an accessor. I don't really like the std::function-systax, but I quess I can hide that behind some overloaded methods. I'll still go with seperate attributes, mainly because they need to be named in the editor interface, which could range from x/y/z to yaw/pitch/roll, to almost everything one can think of. Thanks for the suggestion, I'll definately try it out and compare it to the direct-memory-access, which one works easier/better I'll take.
There is no guarantee that a pointer-to-member is the same size as a regular pointer, which will lead to some interesting results if you cast between them.
Alright, so I can forget that then. Don't know how else I'd get that to work for multiple types
The problem is that &Sprite::vPos::z is not a pointer-to-member of class Sprite, but rather a pointer-to-member of math::Vector2f, which is entirely unrelated to Sprite.
One solution to your problem would be to implement a generic (but typesafe!) pointer-to-member, something using inheritance and type erasure should do the trick.
Hm alright, thats another option. I'm tempted to try it out, lets see what happens.
Thanks all so far, I'll get back when I got any more problems.
Recently i have found interesting article where the author is using "pointer to a member" (with magic template meta-programming) to get that offset.
I think it is somewhat related to what you are asking, but i am still trying to grasp this myself how all this works so i am not 100% sure if it fits your needs.
Actually, pointer to member seems quite right, as you can see I've already been trying to use it in my example above, but didn't quite get it totally. Since I have both the class and member type, I can actually store the pointer-to-member as a void* alongside the declaration data, and cast it back when I want to use it... at least I hope this works the way I think about it, I'll at least give it a try.
EDIT: Unfortunately, pointer-to-member seems to also have a problem with the child-POD-struct:
class Sprite :
float Sprite::* pZ = &Sprite::z; // works
float Sprite::* pX = &Sprite::vPos::z; // doesn't even compile... I don't even know how that should work
I don't know... is there even a solution to this? offsetof would work, though I like pointer-to-member better... I don't want to replace the vector with pure floats eighter... any ideas?