After a decent amount of thought on the postings to my proposal
I've decided to let my proposal evolve.  Thus even though typedmacro
and mixmacro are decent ideas, I will abandon that thread of simply
extending the preprocessor and now propose a full blown new language
feature; the @macro.  I will answer the questions about inline and
templates as related to my previous ideas before going into the @macro
since it is not much of a jump from mixmacros.

     In my view and work, templates are already too overloaded in
terms of their syntax and versatility.  Template functionality is
nearly completely reproducable using #define and token pasting so any
extension of templates would make them more difficult to use and would
be equivalent to extending the preprocessor.  Any extension of
template meta-programming would make for even more intractable code
then has evolved to date.  Inline code also suffers from design issues
that expose code formulations and is still only a request of the
compiler.  These are rather terse explanations since I do not want to
dwell on them in this posting.

     @macro would be the keyword signifier to the preprocessor for the
definition of a new code replacement construct which would obey all
the scoping rules of variables thus elevating it to the level of a
fully object-oriented concept.  The argument list to this macro
would allow for typed varaibles, untyped variables, and multi-line
text insertion.  This methodology would promote a form of code reuse
and extension which is not expressable in current functional, generic,
or object-oriented models.  Here then are a few examples to more
realistically define it's functionality.

///Global definition
#@macro forEach(mover,limiter,[ActionText])
 while(mover!=limiter){  ActionText  mover++; }
#endmacro
///In function
int v1=1;   @forEach( v1, 10, [printf("%d \n",v1);] );
///namespaced
int v2=1, v3=10; std::@forEach( v2,v3,[printf("%d / %d\n",v2,v3);] );


///Functional definition and use
int main(void)
{
 bool checker;
 int  someint;
 #@macro checkFor(bool ret,int value)
  ///code to check container/list/heap/... for value
  ///change the name/type of the container once in this area macro
  ret=Container.contains(value);
 #endmacro
 ...
 @checkFor(checker,someint);
 ...
 return 0;
}

here the macro is defined exclusively inside the function so that it
acts like a pseudo-function bounded to the local scope such that the
macro is automatically invalidated/forgotten outside the function.


///Object-level definition
///the @macro should be automatically static in scope but should give
///warnings if "this" is used as the compiler will note usage errors
class Decoder
{
  private: @macro redirect(int a,b);
           void loadChars();
           void loadInts();
           int bufferlength;
  public:  bool load(String&,int);
  public:  @macro find(bool ret,int place,type,typeinst);
};

#@macro Decoder::redirect(int version,typed)
  if(version==1){ this->loadChars(); }
  if(version==2){ this->load##typed(); }
#endmacro

#@macro Decoder::find(bool ret,int place,type,typeinst)
 if(buffer##type==NULL){ ret=false; }
 else
 {
  for(place=0; place<bufferlength; place++)
  {  if(buffer##type[place]==typeinst){ ret=true; break; }  }
 }
#endmacro

'find' can then be called in other functions using Decoder::@find(..)
but will easily cause errors dependant on the knowledge of it's
internal workings which can be kept private in the .cpp file or
publicly in the header file since there is no conflict until the code
replacement occurs.


     @macros would promote preprocessor directives to object-oriented
coding concepts with full scoping rules.  The proposed formulation
would lead to more malleable code with no possibilty of breaking
legacy code even while it supports the scripting and generic language
efforts of many developers.  With decent restirctions, ie no recursive
@macro calls or @macros defined within @macros, the @macro extension
could provide C++0x with very powerful new abilites.  Even better, if
others come into future legacy code and hate the @macro, they can
rather easily transform most of them into normal functions and normal
function calls.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]