I would like to write a preprocessor macro which takes a type name as an argument.
For example (assuming the appropriate preceeding code)

#define MACRO(T) obj< T > somefuntion() { more stuff here }

where the macro argument is to be used as a template argument.  This works fine
for simple cases...

MACRO(int)

MACRO(other<int>)

but fails for

MACRO(twoarg<int,float>)

because the comma in the template confuses the preprocessor.  I can hide the comma
by enclosing the macro argument in parens, but then the parens remain when the
argument is used and results in an invalid template parameter.

This seems to me to be an area where the preprocessor spec has lagged behind the
langauge spec.  The ARM does not seem to require the preprocessor to comprehend the
template syntax, but this seems to be required here.  I understand that practically
some compilers are borrowing cpp from c, but I expected the language definition to
ask for more.  Have I misunderstood something here?

As a practical workaround, I can typedef a simpler name for twoarg<int,float> and
use that.  Unfortunately, nested typedefs within classes are not supported by
AT&T 3.0.1, but xlC handles it just fine.  If there is a better approach, I'd like
to hear about it.

Thanks,

   Martin Giles

***********************************************************************
* Martin D. Giles                        madagil@adams.eecs.umich.edu *
* Assistant Professor                                  (313) 936-1413 *
* Solid State Electronics Laboratory                    FAX  747-1781 *
* Department of Electrical Engineering and Computer Science           *
* University of Michigan, Ann Arbor, MI 48109-2122                    *
***********************************************************************

 I had this problem with the C preprocessor too. Somebody suggested I use a COMA
 keyword instead of a real coma. It works but it's not quite satisfying.
 By the way, if templates were using parenthesis, it would'nt be a problem
 what is inside parenthesis is not checked by preprocessor. Is it an extension
 of my compiler or a standard feature ? I think it's the later but I din't checked.
 However, this behavior can't be extended to < and > cause of operators.

 There are other problems I had with the old C preprocessor and C++.
 Many compiler writers are integrating preprocessor code inside their compiler
 -i.e to have a one pass C++ compiler - this is very well, but I still woud
 appreciate to get a compiler option that produce direct preprocessor output !
 without syntax checking, or even worse : direct translation of C++ code to C code.
 This kind of function C++ to C is fine, but not when you want to see the expanded
 code of a macro.

 I feel no compiler writer cares much about updating preprocessor. It seems that
 some people got the strange idea that C++ extensions like inlining or const made
 the preprocessor obsolete (why then Pascal added one in some  release ?).
 Not so, there is still many things you need the preprocessor to do.

 C were an excellent language modelling environnement because of its preprocessor,
 you could construct a new language syntax in a few hours with C preprocessor,
 for example I have friend that use to write assemblers for new processors
 using C preprocessor macro facilities. Much faster to write than with Yacc and Lex.

 C preprocessor still works with C++, but is not powerfull enough to use more than
 a small subset of the language with it.

 I feel C++ deserve a decent evolution of preprocessor.
 Minimum extensions should be :
  - configuration of macro arguments separator
   (more powerfull and easy to do than syntax checking arguments)
  - overloading macros (like C++ functions, seems to be a matter of coherence)


 Desirable extensions (my opinion) should be :
  - more than one line macros (may be something like #begindef ... #enddef)
   trailing "/" are a bother.
  - true run time vars (extensions of non macro #define) with operators.
    and allowing #define inside #define macros. These are usefull for writing
    parenthesing macros.

It's not a matter of *adding* rules and exceptions to preprocessor, but of *removing* problems.

I direct this to comp.std.c++ because I can find no direct answer
in the ARM for my problem.
I have the following declarations:

 typedef     bool_t (*xdrproc_t)(XDR *, void *);
 extern bool_t xdr_array(XDR *, void *, xdrproc_t);
 extern bool_t xdr_int(XDR *, int *);

And I want to say:

 if (xdr_array(x, myArray, xdr_int)) ...

Now my (Sun) Cfront says xdr_int dont match xdrproc_t.
I can fix this by using an explicit cast. But this code
occurs in code generated automatically by rpcgen++.
The problem must be solved by fixing the rpcgen to generate
the necesary cast.
But using this cast I lose more type safety than necesary.
The ARM  says very little about matching of function types.

So my question is:

If any pointer is compatible to void* then why isn't
a function type taking a void* compatible with any function taking a pointer.
(Constness excluded)
Or could a function type taking a base class pointer be compatible
with a function taking a pointer to a derived class.

If I could i would probably solve the above problem with templates.
But RPC is such a C hack, that it doesn't lend itself to sending
objects to other processes or to do remote methods.
CORBA should be the answer, but us Europeans seem to be ignored
by OMG and HyperDesk they don't answer letters and faxes.
Do they still exist? Hey guys speak up!
Perhaps somebody can give some information on the precise state
of affairs with CORBA, perhaps even create a newsgroup.

Hans Marggraff
        o__
       _.>/ _
      (@) \(@)