next »

[JWki]

Have been wanting Reflection for C++ for ages. It would make a surprisingly large set of tasks much easier. Serialisation being the prime example. But well... current state is they're aiming for C++20. If they also get modules, concepts, string_view finally into C++ and compilers catch up soon, I'd be happy.

Yeah I'm like 90 percent sure I won't like the standard reflection though. Also I think it's only static in the proposal?
Also I think I just accidentally reported someone to the mods so if a mod sees this, it was an accident sorry

[oahda]

I've been figuring out the dependencies of my engine-editor, and written down the steps needed to get it working on Mac, what to package along with the system and what to download separately (from the command line, of course!). Figured out the folder structure and so on.

Then today I started work on a command line tool to generate the file structure for a new project, with the necessary files, premake/cmake instructions and so on. So far, so good!



Also learned after getting on this "new" computer with the latest macOS that SDL 2 has a bug on Sierra that makes the title bars darker than on other windows, heh.

[JWki]

Nice. Got something similiar on my todo list.
I've been writing what felt like a million lines of code to serialize my reflection data - serves me right for choosing a format that you cannot simply memcpy around - and now I have to write the equivalent deserialization code. Yay.

Also trying to further figure out what API I need and what else I need to output in the generation pass. What I generate so far is data layout and class relationships only (the minimum amount of information) that can be used in a generic fashion but for nice serialization as well as gameplay code it'd be nice to be able to get type information from an actual instance and that requires generating the C++ boilerplate. ATM I'm mostly trying to figure out where exactly to store the reflection data because in my first pass implementation, relationships between types are expressed via pointers and I'm 99 percent sure that's not going to hold up, so I probably need a better lookup strategy so I can express type relationships using proper type IDs and make the metadata classes value types.

Maybe I'll just write graphics code today.

[JWki]

Spent the day completely rewriting my reflection system from scratch including the AST parser, keeping the nice interface for runtime use but optimizing the storage format for serialization.

Now this code will work in an application that links the generic reflection runtime library:



That will create a type library from a binary file stored on disk and tadaa, the application has access to all the type information stored in that file. The output of that snippet is this:



Doesn't seem fancy but it's quite the achievement for me. That information is already usable in an editor for example.
The API only exposes the minimal set of information so far - type sizes, inheritance chains, fields (but no methods), and enums, but it's now robust enough that I can add in more features without breaking stuff I think.

[oahda]

This is so neat. Gonna look and see if I can get some use out of Reflang.

[JWki]

This is so neat. Gonna look and see if I can get some use out of Reflang.

Yeah certainly, it's a bit more feature complete than my tool atm obviously. I have slightly different requirements (not having to have access to the actual types in the same codebase just for layout information for example) and I'm a sufferer of NIH syndrome so I roll my own but reflang is one of the things I look at for reference. I can link you to two other similar tools that are both a bit more mature than reflang I think if you want to, when I get back to a pc.

[oahda]

Sure, do link!

[JWki]

https://github.com/AustinBrunkhorst/CPP-Reflection

https://github.com/Celtoys/clReflect

These two were of some help so far, and they look good from a users perspective.

[JWki]

Whee not even ashamed for spam posting:

[qMopey]

So for serialization have you made some kind of thingy that's like:

class->SetMember( "m_counter", 3 );
class->SetMember( "m_script", "flighty.lua" );
class->SetMember( "m_moveSpeedScale", 1.2f );

For the editor?

[JWki]

So for serialization have you made some kind of thingy that's like:

class->SetMember( "m_counter", 3 );
class->SetMember( "m_script", "flighty.lua" );
class->SetMember( "m_moveSpeedScale", 1.2f );

For the editor?

That's going to be next.

EDIT: Actually, what's going to be next is splitting the tool into three tools: One that generates a binary database of all the type information, one that can merge multiple databases into one, and one that takes in a database and generates C++ code to use the database in a typesafe manner. This is what clReflect does more or less, and I realized it's probably the best approach when you want a project to have access to another project's type information (for example when linking a .dll and wanting to reflect its types as well as your own types).

[oahda]

Maybe I'll end up using yours instead if you make it open source.

Thing I haven't quite come to terms with: does this actually require Clang/LLVM be installed or does the C++ parsing library work anyway?

[JWki]

Maybe I'll end up using yours instead if you make it open source.

Thing I haven't quite come to terms with: does this actually require Clang/LLVM be installed or does the C++ parsing library work anyway?

It needs to link the libraries but you don't need to install it necessarily. I just ship them in the repository.

Also I probably am going to make it public sooner or later but rather later I guess because it needs a lot of work before it's usable for anyone, so I wouldn't advocate you waiting for it. I'd say at least three months until it's something others could use.

[oahda]

:D



(found this pack of icons for buttons and keys and stuff for a lot of systems and then this helped me get images into the text)

[gimblll]

https://github.com/AustinBrunkhorst/CPP-Reflection

https://github.com/Celtoys/clReflect

These two were of some help so far, and they look good from a users perspective.

I ended up with writing my own reflection library too some years ago and have used that in many games, but would really like to get rid of it. Mostly because I just want to get rid of the maintainance overhead (not much, but there's always something).

Did you try? https://github.com/rttrorg/rttr

That's the only one so far that fits my requirements (no external dependencies or forced tools + simple drop in code + no code/macro crap for existing types), but I haven't had the time to try it seriously. (Wasn't available when I did mine.)

[Frappa Studio]

I am a creative person, I work as graphic designer and advertising / digital creative director for 10 years in an agency. When I decided to create a videogame on my freetime with no coding skills at first, I spent 5 years to learn C++, then HTML, js, and finally C# with unity.

I WANT to say to everyone, as an artist, that coding is THE MOST AWESOME and the MOST CREATIVE thing possible in the universe, you get so much more freedom than simply making images, or music : you can give life to things, then interact with your creation as well as other players.

When I finally succeded in my very first RPG combat system, I felt so HAPPY
so HAPPY, sooooooooo HAPPY

Coding is Hapinness

[qMopey]

So for serialization have you made some kind of thingy that's like:

class->SetMember( "m_counter", 3 );
class->SetMember( "m_script", "flighty.lua" );
class->SetMember( "m_moveSpeedScale", 1.2f );

For the editor?

That's going to be next.

EDIT: Actually, what's going to be next is splitting the tool into three tools: One that generates a binary database of all the type information, one that can merge multiple databases into one, and one that takes in a database and generates C++ code to use the database in a typesafe manner. This is what clReflect does more or less, and I realized it's probably the best approach when you want a project to have access to another project's type information (for example when linking a .dll and wanting to reflect its types as well as your own types).

What is the point of making a database? Can't the entire database be generated while Clang parses? And then immediately transformed in C++ code? I recall looking into this in the past, and I would have just used printf while visiting Clang nodes. So why not do something simpler?

[Richard Kain]

When I finally succeded in my very first RPG combat system, I felt so HAPPY
so HAPPY, sooooooooo HAPPY

Thank you for that personal account. It was very encouraging. I also come from a graphics/art background, so I can relate. I also had to learn programming on my own, and was surprised when I got deep enough into it how much creativity I had to employ when executing problem solving. Now it is one of my more favorite aspects. Learning coding syntax and methodology is like acquiring new tools. How you use the tools, and what you use them to do is up to you. Having the tools simply expands on what you can achieve, but it doesn't define how you achieve it. That's up to you.

[JWki]

So for serialization have you made some kind of thingy that's like:

class->SetMember( "m_counter", 3 );
class->SetMember( "m_script", "flighty.lua" );
class->SetMember( "m_moveSpeedScale", 1.2f );

For the editor?

That's going to be next.

EDIT: Actually, what's going to be next is splitting the tool into three tools: One that generates a binary database of all the type information, one that can merge multiple databases into one, and one that takes in a database and generates C++ code to use the database in a typesafe manner. This is what clReflect does more or less, and I realized it's probably the best approach when you want a project to have access to another project's type information (for example when linking a .dll and wanting to reflect its types as well as your own types).

What is the point of making a database? Can't the entire database be generated while Clang parses? And then immediately transformed in C++ code? I recall looking into this in the past, and I would have just used printf while visiting Clang nodes. So why not do something simpler?

Well you could just give all the headers you want reflected to the tool yes. This way you don't have to reparse a header for every project that needs it only once for the project that actually contains it though.

I should add I don't generate an actual database in the sense of the word it's a pretty simple table based format. Similar to what someone proposed in a talk at digipen not too long ago

[qMopey]

That makes sense, but what is wrong with re-parsing?