Alternatives for redefining a typedef?

From: Imre (jrms_at_pager.hu)
Date: 01/23/05 

Date: 23 Jan 2005 05:35:56 -0800

I'm planning to create a macro-based property system (reflection,
automatic serializing for properties, that kind of stuff). The system
would involve writing some PROPERTY(propName) macros between a
BEGIN_CLASS(ThisClass) and an END_CLASS() macro. The PROPERTY macros
should somehow know ThisClass, and that's where it start to get tricky.

A #define ThisClass would of course help, but I'd rather make it part
of the BEGIN_CLASS macro, and #defines can't be inside a macro body.

A typedef inside BEGIN_CLASS is almost good, except that a single
source file may contain multiple class definitions, and the second
BEGIN_CLASS would redefine ThisClass, causing a compile error. I also
can't put the whole thing (the typedef and the PROPERTY macros) inside
a namespace, cause PROPERTY should define some member functions of a
class declared outside of that namespace.

Now if there would be anything that can be defined outside of
functions, and be redefined later, and also be used as a template
argument, then I think the problem could be solved with template
specializations. BEGIN_CLASS would redefine that something, then create
a new specialization of a template for the new 'value', and put a
typedef for ThisClass inside that specialization. PROPERTY macros could
then easily use that typedef.

What I really need is something that can be used as a template
argument, and can be made invariant for a specific part of the code,
then changed for another part.

Unfortunately, I can't think of anything that would fit the bill. Any
ideas? Maybe any other ideas for simulating typedef redefinition (other
than #define / #undef)?

(And yes, you're right, it's not really that big an issue, it's more
curiosity on my side than a real problem.)

    Imre

Relevant Pages

  • Re: Is there a convention mandating macros to be all-uppper-case?
    ... typedef std::wstring tstring; ... to keep namespaces intact. ... Macros are even worse, because they make the substitution completely blindly, without any consideration to their real meaning. ... At least with typedef, you can be sure it's not going to disrupt types in other namespaces, member functions in other classes, etc. ...
    (microsoft.public.vc.language)
  • Re: Why we should (not?) have closures after all
    ... A typedef facility will allow programmers to use ... expressiveness, further decreasing maintenance costs. ... C macros are particularly limited, but a real macro facility is ... how to prevent programmers from doing bad things. ...
    (comp.lang.java.programmer)
  • Re: Use a suffix or a type cast?
    ... I have heard that a suffix is not a good solution and type casts are ... We already had a typedef: ... But much easier than faffing with macros to try and achieve that was: ...
    (comp.lang.c)
  • Re: Operational and functional differences - #define vs typedef ?
    ... Most syntax checking and parsing occurs *after* macros are ... A typedef creates an alias for a type. ... type declarations is such that a macro isn't always going to work. ...
    (comp.lang.c)
  • Re: Templates and Macros
    ... including AutoText, AutoCorrect, keyboard assignments, toolbars, macros, ... Here is some general info on moving from Word Perfect to Word: ... As for converting documents from Word Perfect to _use_ in Word... ... this new document as a Word template. ...
    (microsoft.public.word.docmanagement)
Loading