Sign in to follow this  

c++ macro

This topic is 3737 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am trying to find crazy ideas that relates to c++ macro. My goal is to build a set of macros to define classes in a way that would enable me to easily list information at compile time and/or run time. The way I picture it : // SomeClass.h BEGIN_CLASS (SomeClass) : INHERITS (SomeBaseClass) PARAMETER_DECLARATION (private, float, SomeVariable1) PARAMETER_DECLARATION (public, float, SomeVariable2) METHOD_DECLARATION (public, float, SomeMethod, (float Param1, float Param2)) END_CLASS () // SomeClass.cpp BEGIN_METHOD_DEFINITION (float, SomeClass, SomeMethod, (float Param1, float Param2)) ... normal code here ... END_METHOD_DEFINITION () Im not sure if you guys will see what I mean, I know doing that destroys the nice and standard looks of C++ but the idea is to define theses macros in order to automaticly build lists in classes so that when im building an editor for theses classes, I could get access to whats in it to edit it. an exemple: CLASS_PARAMETER p = FIRST_PARAMETER (SomeClass); while (p) { char * name = PARAMETER_NAME (p); // ... do stuff with "name" p = NEXT_PARAMETER (p); } This thread is about suggestions on how you would do that kind of stuff

Share this post


Link to post
Share on other sites
Quote:
Original post by Shnoutz
This thread is about suggestions on how you would do that kind of stuff

You're trying to destroy the language to make it fit a tool? How will your tool deal with the rest of the body of C++ you will need to deal with?

--smw

Share this post


Link to post
Share on other sites
Quote:
Original post by Bregma
Quote:
Original post by Shnoutz
This thread is about suggestions on how you would do that kind of stuff

You're trying to destroy the language to make it fit a tool? How will your tool deal with the rest of the body of C++ you will need to deal with?

--smw


Exactly, destroying the language is my goal :D

No seriously, I first tought of making a "pre-precompiler" in order to build my classes. The idea is to describe the classes only one time.

For example I want to avoid to do stuff like this manually :

// SomeClass.h
class SomeClass
{
public:
float a;
};

// SomeClass.cpp
ClassDescriptor CD;
CD.addParameter ("public", "float", "a");

Id rather have a code that is a bit less standard but would automatically generate the ClassDescriptor. In the previous example, in a way, I described the class twice.

Share this post


Link to post
Share on other sites
Quote:
Id rather have a code that is a bit less standard but would automatically generate the ClassDescriptor. In the previous example, in a way, I described the class twice.


You're saving time by inventing a new language, that'll become maintainance nightmare.

This type of IDL definitions are used, but usually for serialization. The problem comes from the fact that you'll have really hard time accounting for all the tiny and annoying details that come from such definitions, as soon as you design real classes (not the text-book case ones).

Then you'll discover that you need completely automated memory management, since passing parameters around isn't as trivial.

Next problem will be interacting with standard classes. How will you wrap std::vector? If you don't, how will you access it and edit it from your editor?

What about 3rd party classes? SDL, DX, OGL, and their structures?

If none of these are a concern to you, then do whatever you want, since your application is trivial enough to not touch those problems and it won't matter.

GPG series (I don't remember which one) has a nice presentation of dynamic properties as applicable to real-world applications. They allow you to expose arbitrary parts of your application for the very purpose of run-time editing, but also provide serialization and other useful utilities.

Share this post


Link to post
Share on other sites
If you only want to do this to write a data description DSL within C++... there are better ways.

I describe the format of my game assets via XML, and use a preprocessing tool to generate code (I use C#, but you can easily do this for C++) for me as a pre-build step. This is much cleaner than hacking up a DSL via macros in C++, and it's a lot more maintainable. Augmenting the asset description format to include things like debug-only metadata, annotations for reminding me which values are sane, and automatic GUI-generation code was a snap.

Share this post


Link to post
Share on other sites
Serialization and exposing class variables for edition is my main concern. Im talking about a system that is not build yet so I am not very concern (yet)about problems that may arise from using custom types like std:vector.

I know you guys got some macro tricks, I do have some of my own.. give me a few ideas please. I dont want to build a c++ parser :(

Share this post


Link to post
Share on other sites

<asset name="GeometryCollection">
<flags name="Content">
<flag name="HasNormals"/>
<flag name="HasTangentSpace"/>
<flag name="HasAnimationSupport"/>
</flags>
<field type="int8" name="ColorChannels">
<range lower="0" upper="2"/>
</field>
<field type"int8" name="TextureChannels">
<range lower="0" upper="8"/>
</field>
<array name="IndexData">
<field type="int16" name="Index">
</array>
<array name="VertexData">
<field type="float" name="PositionX"/>
<field type="float" name="PositionY"/>
<field type="float" name="PositionZ"/>
<field if="{HasNormals}" type="float" name="NormalX"/>
<field if="{HasNormals}" type="float" name="NormalY"/>
<field if="{HasNormals}" type="float" name="NormalZ"/>
...lots more junk...
</array>
</asset>

or perhaps

<asset name="Weapon">
<field type="string" name="Name"/>
<field type"int8" name="Damage">
<comment text="Good values are 20 +/- 5 for normal weapons."/>
</field>
<array name="OnEquipEffects">
<field type="ref(SpellEffect)" name="Effect"/>
</array>
...et cetera...
</asset>


I don't allow the definition of methods in this way, as asset's are "dumb data" containers that are consumed by higher level subsystems. I do generate a number of methods, though , to support the system. Serialization and factory-related stuff, code to traverse inter-asset referencing (so loading a Weapon asset could optionally automatically resolve all the SpellEffect asset references and load those too), stuff to support asset hot-reloading during runtime, versioning support (in the future...) and assemblies with metadata for consumption by my editor (screenshot of an early test here) for automatically generating the required GUI.

Share this post


Link to post
Share on other sites

This topic is 3737 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this