David Vandevoorde wrote:
>
> James Kanze wrote:
> >
> > Valentin Bonnard <bonnardv@pratique.fr> writes:
> [...]
> > |>  < and > don't seem very good delimiters to me, but since (),
> > |>  [] and {} are already used, was there annother choice ?
> > |>  (Perhaps [[ ]] since they can't appear in a valid program ?)
> [...]
> > Note that there are contexts outside of the preprocessor where the
> > choice of angle brackets can lead to confusion (in addition to the
> > case of nested templates, because >> is also a token):
>
> It's a most unfortunate choice of delimiters indeed (in
> particular when it interacts with lookup rules).
>
> Apparently, very early in the standardization process
> someone noted this problem and proposed a better pair
> of delimiters.
>
> Does someone remember what that proposal was?

I don't recall any such proposal. I do remember looking at a bunch of
potential delimiters, including (), [], {}, and <> (seems to me there
might have been a fifth one), and looking at the relative merits of
each. We decided to go with <>, and I'd make the same choice today.
 -- Pete
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

denis@bull.tenet.odessa.ua (Denis Vlasenko) writes:

 |>  > < and > don't seem very good delimiters to me, but since (),
 |>  > [] and {} are already used, was there annother choice?
 |>  > (Perhaps [[ ]] since they can't appear in a valid program ?)
 |>
 |>  I think '<>' are nastiest kind of delimiters. < and > already have
 |>  meaning of 'less than' and 'greater than'. Why () wasn't used instead?
 |>
 |>  template (class T)
 |>  class Class: public T {
 |>    public:
 |>      Class(T)(int);
 |>      ...
 |>  };
 |>  ...
 |>  Class(int) instance(5);
 |>
 |>  Is there any problem with such approach?

It introduces a number of new context dependancies: what is X(Y): a
function call, a conversion operator (cast), a function declaration or a
template instantiation?  It's ambiguous enough as is.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
            -- Conseils en informatique industrielle --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David Vandevoorde <daveed@vandevoorde.com> writes:

|>  Steve Clamage wrote:
|>  >
|>  > David Vandevoorde wrote:
|>  [...]
|>  > > Apparently, very early in the standardization process
|>  > > someone noted this problem and proposed a better pair
|>  > > of delimiters.
|>  > >
|>  > > Does someone remember what that proposal was?
|>  >
|>  > Consider each of the following sentences to be prefixed with
|>  > the qualification "If I remember correctly ...". :-)
|>  >
|>  > The subject of template delimiters was thoroughly discussed at
|>  > the Nov 1992 meeting in Boston. All the problems of treating
|>  > the <...> as brackets were clearly understood at that time.
|>
|>  The problems that existed at the time that is :-P
|>
|>  I suppose nobody had foreseen default template arguments,
|>  member templates and explicit function template arguments.

Given that they were added significantly later...

|>  I certainly do hope the argument-dependent lookup rules
|>  function-like name (which I think interact with this syntax)
|>  had not been foreseen by anyone.
|>
|>  [...]
|>  > You don't have to agree with the evaluation of importances,
|>  > but that's how the voting went. IMHO the syntax is not going
|>  > to be changed at this late date.
|>
|>  Of course. OTOH, the syntax rules are cumbersome enough
|>  that one might imagine a more consistent second syntax as
|>  an extension for those who don't mind using extensions to
|>  avoid writing `a.template f<int>()' instead of `a.f{int}()'.

Well, I don't particularly like the alternative either, but the
objections are more esthetic than technical.  I do like the suggestion
of creating a new delimiter, e.g. |< ... >|, or some such.  Ideally,
this new delimiter would be understood by the preprocessor, so that the
commas in "MyGenericClass|< int , double >|" would not be taken as
separators.  On the other hand, preprocessor use is rare enough that
this really isn't a problem.  Less, in fact, than the fact that if |<
and >| were adopted, we would also need alternate tokens, since the |
character isn't available on all keyboards.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
            -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze wrote:
>
> David Vandevoorde <daveed@vandevoorde.com> writes:
[...]
> |>  Of course. OTOH, the syntax rules are cumbersome enough
> |>  that one might imagine a more consistent second syntax as
> |>  an extension for those who don't mind using extensions to
> |>  avoid writing `a.template f<int>()' instead of `a.f{int}()'.
>
> Well, I don't particularly like the alternative either, but the
> objections are more esthetic than technical.  I do like the suggestion
> of creating a new delimiter, e.g. |< ... >|, or some such.  Ideally,
> this new delimiter would be understood by the preprocessor, so that
> the
> commas in "MyGenericClass|< int , double >|" would not be taken as
> separators.  On the other hand, preprocessor use is rare enough that
> this really isn't a problem.  Less, in fact, than the fact that if |<
> and >| were adopted, we would also need alternate tokens, since the |
> character isn't available on all keyboards.

Actually, I am not so concerned about preprocessor issues.
I'm much more worried about the teachability of basic
syntactic issues. Even the simple `> >' vs. `>>' problem
makes the learning experience for many new C++ less pleasant.
The use of `.template ' and `typename' further heighten the
threshold (the latter issue is admittedly an artifact of the
general C declaration syntax).

It's especially unfortunate because the fundamental template
mechanisms (not the syntax or nitty-gritties) is IMO a stroke
of genius: I find the use of generic programming support in
Modula-3, Eiffel and Ada an order of magnitude more cumbersome
and restrictive that it is in C++.

 Daveed
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Valentin Bonnard <bonnardv@pratique.fr> writes:

|>  Stefan Rupp <struppi@gia.rwth-aachen.de> writes:
|>
|>  > the following preprocessor definition given:
|>  >
|>  > #define someMacro(ONE,TWO) someOtherStuffWith(ONE,TWO)
|>  >
|>  > and the template class declaration
|>  >
|>  > template<class A, class B, class C> class someClass;
|>  >
|>  > the compiler (g++) gets confused when parsing the statement
|>  >
|>  > someMacro(someClass<typeOne,typeTwo,typeThree>,other)
|>  >
|>  > because the preprocessor does not know anything about templates.
|>
|>  because < and > don't need to be be balanced (this is a minor
|>  syntax problem with C++, as smart editor can't be used to find
|>  the begining of a declaration, and IMO can cause some ambiguities).
|>
|>  < and > don't seem very good delimiters to me, but since (),
|>  [] and {} are already used, was there annother choice ?
|>  (Perhaps [[ ]] since they can't appear in a valid program ?)

Or just {}.  Just another case of overloading, probably less problem
than static for users.  Although I think your solution is prettier.  You
could also imagine things like (= ... =).  (I'd prefer a - or a ., but
(- and (. are token sequences that can appear in a legal program.)

Of course, these solutions would all require a modification of the
preprocessor, to require that it recognize them as "parentheses" as
well.

Note that there are contexts outside of the preprocessor where the
choice of angle brackets can lead to confusion (in addition to the case
of nested templates, because >> is also a token):

 template < bool F > class X{} ;

 X< myConst > 0 >     x ;

If the instantiation expression contains a >, you have to use
parentheses, e.g. "X< (myConst > 0) > x ;".

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
            -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze wrote:
>
> Valentin Bonnard <bonnardv@pratique.fr> writes:
[...]
> |>  < and > don't seem very good delimiters to me, but since (),
> |>  [] and {} are already used, was there annother choice ?
> |>  (Perhaps [[ ]] since they can't appear in a valid program ?)
[...]
> Note that there are contexts outside of the preprocessor where the
> choice of angle brackets can lead to confusion (in addition to the
> case of nested templates, because >> is also a token):

It's a most unfortunate choice of delimiters indeed (in
particular when it interacts with lookup rules).

Apparently, very early in the standardization process
someone noted this problem and proposed a better pair
of delimiters.

Does someone remember what that proposal was?

 Daveed
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

David Vandevoorde wrote:
>
> James Kanze wrote:
> >
> > Valentin Bonnard <bonnardv@pratique.fr> writes:
> [...]
> > |>  < and > don't seem very good delimiters to me, but since (),
> > |>  [] and {} are already used, was there annother choice ?
> > |>  (Perhaps [[ ]] since they can't appear in a valid program ?)
> [...]
> > Note that there are contexts outside of the preprocessor where the
> > choice of angle brackets can lead to confusion (in addition to the
> > case of nested templates, because >> is also a token):
>
> It's a most unfortunate choice of delimiters indeed (in
> particular when it interacts with lookup rules).
>
> Apparently, very early in the standardization process
> someone noted this problem and proposed a better pair
> of delimiters.
>
> Does someone remember what that proposal was?

Consider each of the following sentences to be prefixed with
the qualification "If I remember correctly ...". :-)

The subject of template delimiters was thoroughly discussed at
the Nov 1992 meeting in Boston. All the problems of treating
the <...> as brackets were clearly understood at that time.

One alternative would be to use real brackets, like () or []
or {}. Parens () and square brackets [] result in syntactic
ambiguities. Curly braces {} cause no problems and were
suggested to replace angle brackets.

Another alternative would be to invent new compound tokens
to be used as brackets. I think |< and >| were suggested,
and possibly others as well.

(End of questionable-rememberance section.)

In the end, the decision to keep <...> as template brackets
was based primarily on the fact that they were already in use
in code, books, and other material. That fact was judged to
outweigh the negative aspects. That consideration is now
much stronger than it was in 1992.

You don't have to agree with the evaluation of importances,
but that's how the voting went. IMHO the syntax is not going
to be changed at this late date.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Steve Clamage wrote:
>
> David Vandevoorde wrote:
[...]
> > Apparently, very early in the standardization process
> > someone noted this problem and proposed a better pair
> > of delimiters.
> >
> > Does someone remember what that proposal was?
>
> Consider each of the following sentences to be prefixed with
> the qualification "If I remember correctly ...". :-)
>
> The subject of template delimiters was thoroughly discussed at
> the Nov 1992 meeting in Boston. All the problems of treating
> the <...> as brackets were clearly understood at that time.

The problems that existed at the time that is :-P

I suppose nobody had foreseen default template arguments,
member templates and explicit function template arguments.

I certainly do hope the argument-dependent lookup rules
function-like name (which I think interact with this syntax)
had not been foreseen by anyone.

[...]
> You don't have to agree with the evaluation of importances,
> but that's how the voting went. IMHO the syntax is not going
> to be changed at this late date.

Of course. OTOH, the syntax rules are cumbersome enough
that one might imagine a more consistent second syntax as
an extension for those who don't mind using extensions to
avoid writing `a.template f<int>()' instead of `a.f{int}()'.

 Daveed
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

> < and > don't seem very good delimiters to me, but since (),
> [] and {} are already used, was there annother choice?
> (Perhaps [[ ]] since they can't appear in a valid program ?)

I think '<>' are nastiest kind of delimiters. < and > already have
meaning of 'less than' and 'greater than'. Why () wasn't used instead?

template (class T)
class Class: public T {
  public:
    Class(T)(int);
    ...
};
...
Class(int) instance(5);

Is there any problem with such approach?
--
Denis Vlasenko
13-104 K.Marx street, Ilyichevsk, Odessa region, 270901 Ukraine
Phone: (+380-48) 686-8134
Email: denis@bull.tenet.odessa.ua
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hello,

the following preprocessor definition given:

#define someMacro(ONE,TWO) someOtherStuffWith(ONE,TWO)

and the template class declaration

template<class A, class B, class C> class someClass;

the compiler (g++) gets confused when parsing the statement

someMacro(someClass<typeOne,typeTwo,typeThree>,other)

because the preprocessor does not know anything about templates.
The solution in my case is to provide a typedef for the template
class, so the commatas disappear, but does the standard say anything
about this?

Ciao,
     struppi

--
Stefan H. Rupp                         Tel.: +49 241 80-5295 (dienstl.)
Geodaetisches Institut der RWTH Aachen       +49 241 25209   (privat)
Templergraben 55, D-52062 Aachen, Germany              struppi@acm.org
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Stefan Rupp wrote:
>
> the following preprocessor definition given:
>
> #define someMacro(ONE,TWO) someOtherStuffWith(ONE,TWO)
>
> and the template class declaration
>
> template<class A, class B, class C> class someClass;
>
> the compiler (g++) gets confused when parsing the statement
>
> someMacro(someClass<typeOne,typeTwo,typeThree>,other)
>
> because the preprocessor does not know anything about templates.
> The solution in my case is to provide a typedef for the template
> class, so the commatas disappear, but does the standard say anything
> about this?

Preprocessing doesn't know ANYTHING about the C++ language proper.
Preprocessing has its own rules about names and operators.

In particular, the arguments to a macro are separated by
commas, unless you use parentheses to alter the grouping.
Example (not recommended):
  someMacro( (someClass<typeOne,typeTwo,typeThree>), other)

That solves the comma problem, but you get an extra set
of parentheses around the type. You might wind up with
invalid C++ syntax after the macros are expanded. I don't
see a good way around this problem except by using a typedef
for the template type, as you suggested.

Of course, you could not use macros, which might be
the best solution of all.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Stefan Rupp <struppi@gia.rwth-aachen.de> writes:

 >the following preprocessor definition given:
 >
 >#define someMacro(ONE,TWO) someOtherStuffWith(ONE,TWO)
 >
 >and the template class declaration
 >
 >template<class A, class B, class C> class someClass;
 >
 >the compiler (g++) gets confused when parsing the statement
 >
 >someMacro(someClass<typeOne,typeTwo,typeThree>,other)
 >
 >because the preprocessor does not know anything about templates.
 >The solution in my case is to provide a typedef for the template
 >class, so the commatas disappear, but does the standard say anything
 >about this?

The behaviour you observed is required by the draft standard.

As well as the typedef solution that you mentioned, another alternative
is to just not use macros :-)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Stefan Rupp wrote:
>
> the following preprocessor definition given:
>
> #define someMacro(ONE,TWO) someOtherStuffWith(ONE,TWO)
>
> and the template class declaration
>
> template<class A, class B, class C> class someClass;
>
> the compiler (g++) gets confused when parsing the statement
>
> someMacro(someClass<typeOne,typeTwo,typeThree>,other)
>
> because the preprocessor does not know anything about templates.
> The solution in my case is to provide a typedef for the template
> class, so the commatas disappear, but does the standard say anything
> about this?

I think you've found a bug in the current draft working paper. From 16.3
[cpp.replace] paragraph 8:

  Each  subsequent  instance  of  the
  function-like  macro  name  followed  by a ( as the next preprocessing
  token introduces the sequence of preprocessing tokens that is replaced
  by  the  replacement  list  in  the  definition  (an invocation of the
  macro).  The replaced sequence of preprocessing tokens  is  terminated
  by  the  matching  ) preprocessing token, skipping intervening matched
  pairs of left and right parenthesis preprocessing tokens.

It says nothing about matching angle brackets, but it clearly should. In
fact, it should mention braces as well, in my opinion, since one might
wish to use a brace-enclosed initializer list as a macro parameter. And
they might as well specify square brackets as well, since one might
theoretically wish to pass a bracketed subscript consisting of a
comma-operator expression.

--

Ciao,
Paul

(Please remove the extra "crud" from the return address,
which has been altered to foil junk mail senders.)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Stefan Rupp wrote:
[...]
> the compiler (g++) gets confused when parsing the statement
>
> someMacro(someClass<typeOne,typeTwo,typeThree>,other)
>
> because the preprocessor does not know anything about templates.
> The solution in my case is to provide a typedef for the template
> class, so the commatas disappear, but does the standard say anything
> about this?

Yes, it blesses the behavio(u)r you're observing
([cpp.replace]). Only inner pairs of parentheses
are special.

 Daveed
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Paul D. DeRocco wrote:
 >
 > Stefan Rupp wrote:
 > >
 > > the following preprocessor definition given:
 > >
 > > #define someMacro(ONE,TWO) someOtherStuffWith(ONE,TWO)
 > >
 > > and the template class declaration
 > >
 > > template<class A, class B, class C> class someClass;
 > >
 > > the compiler (g++) gets confused when parsing the statement
 > >
 > > someMacro(someClass<typeOne,typeTwo,typeThree>,other)
 > >
 > > because the preprocessor does not know anything about templates.
 > > The solution in my case is to provide a typedef for the template
 > > class, so the commatas disappear, but does the standard say anything
 > > about this?
 >
 > I think you've found a bug in the current draft working paper. From 16.3
 > [cpp.replace] paragraph 8:
 >
 >   Each  subsequent  instance  of  the
 >   function-like  macro  name  followed  by a ( as the next preprocessing
 >   token introduces the sequence of preprocessing tokens that is replaced
 >   by  the  replacement  list  in  the  definition  (an invocation of the
 >   macro).  The replaced sequence of preprocessing tokens  is  terminated
 >   by  the  matching  ) preprocessing token, skipping intervening matched
 >   pairs of left and right parenthesis preprocessing tokens.
 >
 > It says nothing about matching angle brackets, but it clearly should.

Why? That would break this code:

#define f( a1, a2 ) // macro implementation goes here

f( a<b,c>d ); // with this suggested change, this macro invocation now
  // has a single argument instead of two

One thing I've learned after many years of language discussions in the
standardization process is that language changes are never as simple as
they seem.
 -- Pete
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <5nnves$neb@mulga.cs.mu.OZ.AU>
fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

>Stefan Rupp <struppi@gia.rwth-aachen.de> writes:
>
> >the following preprocessor definition given:
> >
> >#define someMacro(ONE,TWO) someOtherStuffWith(ONE,TWO)
> >
> >and the template class declaration
> >
> >template<class A, class B, class C> class someClass;
> >
> >the compiler (g++) gets confused when parsing the statement
> >
> >someMacro(someClass<typeOne,typeTwo,typeThree>,other)
> >
> >because the preprocessor does not know anything about templates.
> >The solution in my case is to provide a typedef for the template
> >class, so the commatas disappear, but does the standard say anything
> >about this?
>
>The behaviour you observed is required by the draft standard.
>
>As well as the typedef solution that you mentioned, another alternative
>is to just not use macros :-)

Or, you may use macros more agressively ;).
Certainly not all problems of concern could be solved by typedefs.
They may be solved via macros :

// partial specialization "typedef"
# define SOME_PARTIAL_SPEC(typeOne) someClass<typeOne,T2,T3>

someMacro(SOME_PARTIAL_SPEC(T1), other_stuff);

Best regards,
--
-Boris *  [fbp@mcst.ru] * Opinions expressed here are mine alone.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Stefan Rupp <struppi@gia.rwth-aachen.de> writes:

> the following preprocessor definition given:
>
> #define someMacro(ONE,TWO) someOtherStuffWith(ONE,TWO)
>
> and the template class declaration
>
> template<class A, class B, class C> class someClass;
>
> the compiler (g++) gets confused when parsing the statement
>
> someMacro(someClass<typeOne,typeTwo,typeThree>,other)
>
> because the preprocessor does not know anything about templates.

because < and > don't need to be be balanced (this is a minor
syntax problem with C++, as smart editor can't be used to find
the begining of a declaration, and IMO can cause some ambiguities).

< and > don't seem very good delimiters to me, but since (),
[] and {} are already used, was there annother choice ?
(Perhaps [[ ]] since they can't appear in a valid program ?)

> The solution in my case is to provide a typedef for the template
> class, so the commatas disappear, but does the standard say anything
> about this?

This is a classic problem; use COMMA:

#define COMMA ,

someMacro(someClass<typeOne COMMA typeTwo COMMA typeThree>,other)

This is ugly. Other solution: don't use the preprocessor.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Fergus Henderson wrote:
> <snip>
> I must disagree, it is not at all clear that the preprocessor should
> match angle brackets.  On the contrary, if anything is clear, it is that
> the preprocessor _can't_ disambiguate between the two uses of "<"
> (as "less than" and as template angle brackets), because doing that would
> require semantic analysis. <snip>

This would be more accurately phrased:

... if anything is clear, it is that rquiring the preprocessor to
disambiguate between the two uses of "<" (as "less than" and as template
angle brackets) would be extremely controversial as the required
semantic analysis would greatly increase the complexity of the
preprocesssor and introduce the potential for backwards compatiblity
problems.

While preprocessors typically have had only a minimal knowledge of the
static semantics of a language, there is nothing intrinsic to the
concept that forbids more sophisticated implementations. However, I
suspect that a significant fraction of users of the C preprocessor
generate code that at intermediate stages is not obviously valid and
would not be compatible with a more sophisticated preprocessor
implementation.

--

William B. Clodius  Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323     Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Paul D. DeRocco" <pderocco@ix.netcom.crud.com> writes:

>Stefan Rupp wrote:
...
>> the compiler (g++) gets confused when parsing the statement
>>
>> someMacro(someClass<typeOne,typeTwo,typeThree>,other)
>>
>> because the preprocessor does not know anything about templates.
...
>I think you've found a bug in the current draft working paper. [...]
>It says nothing about matching angle brackets, but it clearly should.

I must disagree, it is not at all clear that the preprocessor should
match angle brackets.  On the contrary, if anything is clear, it is that
the preprocessor _can't_ disambiguate between the two uses of "<"
(as "less than" and as template angle brackets), because doing that would
require semantic analysis.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

William Clodius wrote:
>
> Fergus Henderson wrote:
> > <snip>
> > I must disagree, it is not at all clear that the preprocessor should
> > match angle brackets.  On the contrary, if anything is clear, it is that
> > the preprocessor _can't_ disambiguate between the two uses of "<"
> > (as "less than" and as template angle brackets), because doing that would
> > require semantic analysis. <snip>
>
> This would be more accurately phrased:
>
> ... if anything is clear, it is that rquiring the preprocessor to
> disambiguate between the two uses of "<" (as "less than" and as template
> angle brackets) would be extremely controversial as the required
> semantic analysis would greatly increase the complexity of the
> preprocesssor and introduce the potential for backwards compatiblity
> problems.
>
> While preprocessors typically have had only a minimal knowledge of the
> static semantics of a language, there is nothing intrinsic to the
> concept that forbids more sophisticated implementations. However, I
> suspect that a significant fraction of users of the C preprocessor
> generate code that at intermediate stages is not obviously valid and
> would not be compatible with a more sophisticated preprocessor
> implementation.

The standard specifies that semantic analysis occurs in lexical analysis
phase 7, and that phases 1-6 must be complete by that time (modulo an
as-if proviso). A pre-processor that expands macros (phase 4) cannot do
so in a manner that is sensitive to the semantics and remain conforming.
Your 'more sophisticated' implementation would require a re-design of
the phase structure, and re-thinking of all the decisions that have been
affected by it. That is a lot of re-thinking. I doubt that the benefits
would be worth it.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

William Clodius wrote:
>
> Fergus Henderson wrote:
> > <snip>
> > I must disagree, it is not at all clear that the preprocessor should
> > match angle brackets.  On the contrary, if anything is clear, it is that
> > the preprocessor _can't_ disambiguate between the two uses of "<"
> > (as "less than" and as template angle brackets), because doing that would
> > require semantic analysis. <snip>
>
> This would be more accurately phrased:
>
> ... if anything is clear, it is that rquiring the preprocessor to
> disambiguate between the two uses of "<" (as "less than" and as template
> angle brackets) would be extremely controversial as the required
> semantic analysis would greatly increase the complexity of the
> preprocesssor and introduce the potential for backwards compatiblity
> problems.

I have to agree with Fergus.

Example:
 M ( a < b , c > d )
For macro M, this could be an invocation with
- two parameters "a<b" and "c>d"
- one parameter, the parameter being the declaration of
  variable "d" having type "a<b,c>"
You can't tell which without a complete semantic analysis
of the program up to this point (including scopes and
name hiding).

Currently, preprocessing knows no C++ language rules and
conceptually occurs before any C++ syntax and semantic analysis
is performed. The preprocessor has its own syntax and semantics,
corresponding to C++ only in recognizing identifiers (lumping in
keywords), and in integer arithmetic expresssions.

The suggested change isn't just adding some complexity, it is a
completely different concept of preprocessing. It would mean
adding macros to the C++ language proper. Whether or not that
is a good idea, let's not think of it as a minor tweak on
the current preprocessor. It is completely different concept.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]