In article <a6iv1t$rdc$1@eeyore.INS.cwru.edu>,
Ken Alverson <Ken@Alverson.com> wrote:
>I guess the question is, what OTHER use do variadic macros have, and does
>that justify their inclusion in C++?  Or, does C99 compatibility alone
>justify their inclusion?

I think he's asking about macros that can take varying *number* of
arguments, e.g. error-reporting macros that expand into printf() calls.

Function overloading doesn't help much with that.

--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Barry Margolin" <barmar@genuity.net> wrote in message
news:%N7j8.14$Cd7.386@paloalto-snr2.gtei.net...
> In article <a6iv1t$rdc$1@eeyore.INS.cwru.edu>,
> Ken Alverson <Ken@Alverson.com> wrote:
> >I guess the question is, what OTHER use do variadic macros have, and does
> >that justify their inclusion in C++?  Or, does C99 compatibility alone
> >justify their inclusion?
>
> I think he's asking about macros that can take varying *number* of
> arguments, e.g. error-reporting macros that expand into printf() calls.
>
> Function overloading doesn't help much with that.

I understand what is being asked and function overloading does help with
that so long as it is a finite number of parameters.  I can define T
min(T,T), T min(T,T,T), T min(T,T,T,T) and so on...it may not be super
pretty, but generally all but the first can be reduced to something
trivially recursive.  There is a limit to how high you can reasonably go
without hurting readability at the call site...

The general C++ idiom has been to steer clear of variadic functions, printf
becomes cout for example.  Now, this is largely due to typesafety (and lack
thereof in variadic functions), but we've done well without variadic
functions, so until it is shown that variadic macros have a compelling usage
scenario, I am inclined to assume we can do without them.

Ken


---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Ken Alverson" <Ken@Alverson.com> wrote in message
news:a6j5rs$8aq$1@eeyore.INS.cwru.edu...
> > >I guess the question is, what OTHER use do variadic macros have, and does
> > >that justify their inclusion in C++?  Or, does C99 compatibility alone
> > >justify their inclusion?
> >
> > I think he's asking about macros that can take varying *number* of
> > arguments, e.g. error-reporting macros that expand into printf() calls.
> >

More precisely, macros that expand to compile-time constant expressions and
types.

> > Function overloading doesn't help much with that.

Indeed, it doesn't help at all, given that inline functions are a 'runtime'
construct.

> I understand what is being asked and function overloading does help with
> that so long as it is a finite number of parameters.  I can define T
> min(T,T), T min(T,T,T), T min(T,T,T,T) and so on...it may not be super
> pretty, but generally all but the first can be reduced to something
> trivially recursive.  There is a limit to how high you can reasonably go
> without hurting readability at the call site...

The problem is that it *must* be expanded at compile-time not at runtime, before
the template mechanism gets it at all.  That basically means macros, because the
macros (in this case) are generating overloaded functions and partial/explicit
specializations of templates.

> The general C++ idiom has been to steer clear of variadic functions, printf
> becomes cout for example.  Now, this is largely due to typesafety (and lack
> thereof in variadic functions), but we've done well without variadic
> functions, so until it is shown that variadic macros have a compelling usage
> scenario, I am inclined to assume we can do without them.

I'll give a small example of what I'm doing...

First, I defined a set of macros to perform linearization operations (similar to
boost's preprocessor library, though different because I created it separately).

Then I used that to define a template that extracts parameter types into another
template (the linearization in necessary to create the partial specializations
of function types).

This template extracts the types into a template that takes a single int n as a
parameter and has a nested template class that takes n type parameters.  For
example, a basic typelist structure...

template<class T, class U = null_t> struct typelist_t {
    typedef T head;
    typedef U tail;
};

template<int> struct typelist;

template<> struct typelist<1> {
    template<class T1> struct args {
        typedef typelist_t<T1> type;
    };
};

template<> struct typelist<2> {
    template<class T1, class T2> struct args {
        typedef typelist_t<T1, typename typelist<1>::args<T2>::type> type;
    };
};

Etc.

I generate these specializations with the linearization macros.

In combination with the extraction template, I can put the parameter types of a
function type into this template and get a typelist_t typedef.

e.g.

extract<void (int, int, int), typelist>::type::type

is equivalent to:

TYPELIST_3(int, int, int)

Then I reduce it to:

#define TYPELIST(ARGS) extract<void ARGS, typelist>::type::type

So now I have...

TYPELIST((int, int, int))

And here is the annoyance.  I would rather have TYPELIST(int, int, int), but
that requires variadic macros...

#define TYPELIST(...) extract<void (__VA_ARGS__), typelist>::type::type

Then I could finally use: TYPELIST(int, int, int)

Besides which, this is not limited to typelists, I myself use this mechanism for
tuples, closures, implementing operator->* for smart pointers, visitor classes,
etc..  E.g..

TUPLE(int, int) get_point();

is better than any of these as far as clarity is concerned...

TUPLE((int, int)) get_point();
TUPLE_2(int, int) get_point();
-or-
Tuple<TYPELIST_2(int, int)> get_point();

Incidently, the only macro that is left defined after linearization is
TYPELIST(), so the procedure is non-pollutant.

As you can see, this is the preprocessor working with the template mechanism,
and it is entirely type-safe, unlike ... in functions.  Variadic macros are
*compile-time* variable arguments, ... is a runtime construct.  There is a big
difference.  The only major, problem that I have found with my mechanism is that
sometimes I have to do a preprocessor pass first to get good error messages from
the compiler.

To re-make the typelist example above:

--------------------
#include "extract.h"

struct null_t;

// typelist_t

template<class T, class U = null_t> struct typelist_t {
    typedef T head;
    typedef U tail;
};

// typelist

template<int> struct typelist;

template<> struct typelist<1> {
    template<class T1> struct args {
        typedef typelist_t<T1> type;
    };
};

??=include ENABLE(linearize.h)

#define MACRO(C) \
    template<> struct typelist<C> { \
        template<LIST_CLASS_T(C)> struct args { \
            typedef typelist_t<T1, \
                typename typelist<C - 1> \
                    ::args<LIST_T_MINUS_FIRST(C)>::type> type; \
        }; \
    };

#define LBOUND 2

#include MAKE(100)

??=include DISABLE(linearize.h)

#define TYPELIST(ARGS) extract<void ARGS, typelist>::type::type
--------------------
(note:  I'm using ??= to distinguish from regular #include usage)

That is it.  All of the linearization-type macros are undefined, MACRO and
LBOUND are undefined automatically, MAKE is undefined.  All that is left
(excluding ENABLE and DISABLE which aren't necessary) is TYPELIST.

One macro, which I would, if given variadic macros, redefine as:

#define TYPELIST(...) extract<void (__VA_ARGS__), typelist>::type::type

Obviously, this type of stuff (aka garbage) cannot be done with inline
functions, it is meta-programming.  And the preprocessor coupled with the
template mechanism is a meta-programming powerhouse.  Plus, in this scenario,
lack of variadic macros adds parenthesis, which is "the most overused construct
in C and C++."  :)

Obviously (again) I can already do what I want, but the extra parenthesis are
disagreable.  Plus, C99 has it already.  It should be, "What are the *really*
good reasons *not* to have it?"  Besides, if I had my way, I would have
overloaded macros--based on number of arguments. :)  There are times where no
solution fits the problem better than the use of macros.  For instance, the C++
template mechanism (and typelists) cannot be used to declare and define a
function taking an arbitrary (compile-time, not ...) number of arguments of
arbitrary types.  The preprocessor can facilitate this.  The only alternative is
truely massive repetition.

For instance, why isn't operator->* commonly overloaded for smart-pointer-like
classes?  Because it is a total pain.  Yet, using some of the techniques that I
am above, it can be implemented like this:

#include "closure.h"

template<class T> class smart_ptr {
    private:
        T* m_ptr;
        // ...
    public:
        template<class U> inline typename closure<U>::return_type operator->*(U
ptr) {
            return make_closure(m_ptr, ptr);
        }
        // ...
};

This is thoroughly type-safe, and works for pointers-to-data-members as well as
pointers-to-member-functions (even const, volatile, and const volatile members)
up to 100 arguments (which could be expanded but it total overkill already).

Internally, closure makes heavy use of macro facilities, but there is nothing
left defined to interfere with smart_ptr.  Selective use of macros, rather than
pervasive, is perfectly acceptable.

Paul Mensonides



---
[ 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.research.att.com/~austern/csc/faq.html                ]

"None" <leavings@attbi.com> wrote in message
news:000001c1c989$e636fb30$7772e50c@c161550a...
>
> template<class T, class U = null_t> struct typelist_t {
>     typedef T head;
>     typedef U tail;
> };
>
> template<int> struct typelist;
<snip>
>
> TUPLE(int, int) get_point();
>
> is better than any of these as far as clarity is concerned...
>
> TUPLE((int, int)) get_point();
> TUPLE_2(int, int) get_point();
> -or-
> Tuple<TYPELIST_2(int, int)> get_point();

Ahh, this is progress.  This is, indeed, a valid reason for variadic macros.
It is an issue I would *rather* see solved at the language level than the
preprocessor level, but it does indeed fit as a solution, and given that
it's already a C99 feature, that's probably enough reason to support it
(though perhaps not enough to recommend its use).

Ken


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Ron Natalie wrote:
>
> "James Kuyper Jr." wrote:
> >
> > Paul Mensonides wrote:
> > >
> > > Hello, I wondering if the C++0x standard is likely to contain C99's variadic
> > > macros.
> >
> > C++ overloading makes them far less necessary than they are in C99.
>
> How does overloading help with MACROS?

I'm sorry, I was thinking of the wrong feature. For some reason I
thought you were referring to the printf() format string macros. Looking
back at your message, I can't quite figure out how I achieved that
misconception. Sorry for the confusion.

Two of the three examples given in the C standard, using variadic
macros, involve using them to wrap variadic functions, and both of those
functions were from the printf() family. C++ programs tend to use cout
instead, which means that you don't normally need a wrapping functions.
Therefore, I'm still not sure how useful it would be in a C++ context.
Could you give a C++ example of a case where using a variadic macro,
despite the disadvantages of macros, would (if the were added to the
language) be the best way to implement something?

There's been considerable resistence to any change to C++ that makes
macros more useful. One of Stroustrup's goals when designing it was to
give the non-macro features of the language functionality which removes
the need for macros. This strikes me as a vary good idea.
_

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Ken Alverson" <Ken@Alverson.com> wrote in message
news:<a6iv1t$rdc$1@eeyore.INS.cwru.edu>...

> I guess the question is, what OTHER use do variadic macros have, and
> does that justify their inclusion in C++?  Or, does C99
> compatibility alone justify their inclusion?

The rule is, as close to C as possible, but no closer.  Unless the C
feature causes some additional problems in C++, it should be adopted.
In the case of extensions to the preprocessor, it is hard to see where
there could be additional problems, because the preprocessors are
compatible now.

--
James Kanze                                   mailto:kanze@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique orient   e objet
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany, T   l.: +49 (0)69 19 86 27

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3C8D52D5.64218662@wizard.net>,
James Kuyper Jr. <kuyper@wizard.net> wrote:
>Ron Natalie wrote:
>>
>> "James Kuyper Jr." wrote:
>> >
>> > Paul Mensonides wrote:
>> > >
>> > > Hello, I wondering if the C++0x standard is likely to contain C99's
>variadic
>> > > macros.
>> >
>> > C++ overloading makes them far less necessary than they are in C99.
>>
>> How does overloading help with MACROS?
>
>I'm sorry, I was thinking of the wrong feature. For some reason I
>thought you were referring to the printf() format string macros. Looking
>back at your message, I can't quite figure out how I achieved that
>misconception. Sorry for the confusion.
>
>Two of the three examples given in the C standard, using variadic
>macros, involve using them to wrap variadic functions, and both of those
>functions were from the printf() family. C++ programs tend to use cout
>instead, which means that you don't normally need a wrapping functions.
>Therefore, I'm still not sure how useful it would be in a C++ context.

How do folks in the C++ world do things like:

#ifdef TESTING
#define ERROR(...) fprintf(stderr, ...)
#else
#define ERROR(...)
#endif

(I know this isn't correct syntax for variadic macros, consider it
pseudocode).  Presumably it would expand into something of the form:

cerr << ...

but what would you put in place of '...'?  Would the second line above be:

#define ERROR(x) cerr << x

so you then call it as:

ERROR("Error at line" << __LINE__);

I guess this would work, but it seems kind of ugly.  Function-like macros
usually should look like function calls, but in this case the argument is
not a valid expression; in another cae, it could even be a valid
expression:

ERROR(1 << 2);

but it's not doing what it looks like it does -- it doesn't print 8, as it
would if it were:

ERROR((1 << 2));

--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

On Sun, 10 Mar 2002, Paul Mensonides wrote:

> Hello, I wondering if the C++0x standard is likely to contain C99's variadic
> macros.

Since it is a pure extension that does not invalidate any
existing code, and since it has no special consequences for C++,
it seems certain to be in the next C++ standard. Some C++
compilers implement it already.

--
Steve Clamage, stephen.clamage@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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Ken Alverson" <Ken@Alverson.com> wrote in message
news:a6kbqn$694$1@eeyore.INS.cwru.edu...

[snip]

> > TUPLE(int, int) get_point();
> >
> > is better than any of these as far as clarity is concerned...
> >
> > TUPLE((int, int)) get_point();
> > TUPLE_2(int, int) get_point();
> > -or-
> > Tuple<TYPELIST_2(int, int)> get_point();
>
> Ahh, this is progress.  This is, indeed, a valid reason for variadic macros.
> It is an issue I would *rather* see solved at the language level than the
> preprocessor level, but it does indeed fit as a solution, and given that
> it's already a C99 feature, that's probably enough reason to support it
> (though perhaps not enough to recommend its use).

I also wish that it could be solved at a language level.  For instance, I wish
that you could overload class templates by number of parameters as well.

i.e.

template<class A> class X { ... };
template<class A, class B> class X { ... };

Then I could eliminate the use of function types being used for other than their
intended purpose--types of functions.  Instead, I'm using them as just lists of
types.  In other words, it is a hack, and one that is actually in use in this
scenario to implement real scenarios.  But, given that we already have explicit
specialization and partial specialization (which is significantly more
complicated then overloading on number of types or a finite set of integral
types), I don't see the problem with:

template<class A> class X { ... };
template<int A> class X { ... };

int main(int argc, char* argv[]) {
    X<10> x; // obviously X<int> not X<class>
    return 0;
}

The work around (which is more complicated and less intuitive)...

template<class T, T V> struct map_integral {
    static const T value = V;
};

template<class T, T V> const T map_integral<T, V>::value;

template<class A> class X { ... };

template<int I> class X< map_integral<int, I> > { };

int main(int argc, char* argv[]) {
    X< map_integral<int, 10> > x; // less obvious
    return 0;
}

Paul Mensonides


---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hi,

I for me don't need variadic macros for (Loki-)typelists. Instead I use
the following solution:

template<class T1,
  class T2 = NullType,
  class T3 = NullType,  //etc.up to 50
 >
struct TYPE {
  typedef Loki::EraseAll<TYPELIST_50(T1, T2, T3...), NullType>::Result
LIST;
};

typedef TYPE<int, int>::LIST t_2_ints;
typedef TYPE<int, int, int>::LIST t_3_ints;

Maybe the wording is a little bit sketchy, but it works (esp. the
trailing NullType is preserved).
I came up with this solution, because I had trouble with template types
inside TYPELIST. E.g.

typedef TYPELIST_2 (std::pair<int, int>, std::pair<int, int>)
t_2_int_pairs;

didn't work due to the misinterpreted commas (at least at the compilers
I tried).


Best regards
Olaf Krzikalla

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Olaf Krzikalla" <Entwicklung@reico.de> wrote in message
news:3C8F7A4D.CADC2CF5@reico.de...
> Hi,
>
> I for me don't need variadic macros for (Loki-)typelists. Instead I use
> the following solution:
>
> template<class T1,
> class T2 = NullType,
> class T3 = NullType, //etc.up to 50
> >
> struct TYPE {
>   typedef Loki::EraseAll<TYPELIST_50(T1, T2, T3...), NullType>::Result
> LIST;
> };
>
> typedef TYPE<int, int>::LIST t_2_ints;
> typedef TYPE<int, int, int>::LIST t_3_ints;
>
> Maybe the wording is a little bit sketchy, but it works (esp. the
> trailing NullType is preserved).

The NullType is preserved in mine also.

template<class T, class U = null_t> struct typelist_t;

> I came up with this solution, because I had trouble with template types
> inside TYPELIST. E.g.
>
> typedef TYPELIST_2 (std::pair<int, int>, std::pair<int, int>)
> t_2_int_pairs;
>
> didn't work due to the misinterpreted commas (at least at the compilers
> I tried).

I had the same problem.  The code that I posted before fixes this problem, even
without a TYPELIST((...)) macro, and, though it works, I can't say that I like
all those default NullTypes though.  Though I agree, it will work, and I also
agree that I don't *need* variadic macros, I just think they would be useful.

typelist<2>::args<int, int>::type
typelist<3>::args<int, int, int>::type

Actually, my implementation uses default arguments for this thoughout, e.g.

template<> struct typelist<3> {
    template<class T1, class T2 = T1, class T3 = T2> struct args {
        typedef typelist_t<T1, typename typelist<2>::args<T2, T3>::type> type;
    };
};

// etc.

So I actually shorten the above to:

typelist<2>::args<int>::type;
typelist<3>::args<int>::type;

Paul Mensonides


---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Olaf Krzikalla" <Entwicklung@reico.de> wrote in message
news:3C8F7A4D.CADC2CF5@reico.de...
> Hi,
>
> I for me don't need variadic macros for (Loki-)typelists. Instead I use
> the following solution:
>
> template<class T1,
> class T2 = NullType,
> class T3 = NullType, //etc.up to 50
> >
> struct TYPE {
>   typedef Loki::EraseAll<TYPELIST_50(T1, T2, T3...), NullType>::Result
> LIST;
> };
>
> typedef TYPE<int, int>::LIST t_2_ints;
> typedef TYPE<int, int, int>::LIST t_3_ints;
>
> Maybe the wording is a little bit sketchy, but it works (esp. the
> trailing NullType is preserved).

The NullType is preserved in mine also.

template<class T, class U = null_t> struct typelist_t;

> I came up with this solution, because I had trouble with template types
> inside TYPELIST. E.g.
>
> typedef TYPELIST_2 (std::pair<int, int>, std::pair<int, int>)
> t_2_int_pairs;
>
> didn't work due to the misinterpreted commas (at least at the compilers
> I tried).

I had the same problem.  The code that I posted before fixes this problem, even
without a TYPELIST((...)) macro, and, though it works, I can't say that I like
all those default NullTypes though.  Though I agree, it will work, and I also
agree that I don't *need* variadic macros, I just think they would be useful.

typelist<2>::args<int, int>::type
typelist<3>::args<int, int, int>::type

Actually, my implementation uses default arguments for this thoughout, e.g.

template<> struct typelist<3> {
    template<class T1, class T2 = T1, class T3 = T2> struct args {
        typedef typelist_t<T1, typename typelist<2>::args<T2, T3>::type> type;
    };
};

// etc.

So I actually shorten the above to:

typelist<2>::args<int>::type;
typelist<3>::args<int>::type;

Paul Mensonides

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hello, I wondering if the C++0x standard is likely to contain C99's variadic
macros.

Does anyone know if there has been any talk about it that I missed?

Paul Mensonides

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hello, I wondering if the C++0x standard is likely to contain C99's variadic
macros.

Does anyone know if there has been any talk about it that I missed?

Paul Mensonides


---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Paul Mensonides" <pmenso57@attbi.com> writes:

> Hello, I wondering if the C++0x standard is likely to contain C99's
> variadic macros.

Nobody knows what will be in that standard; just assume x >= 8.

> Does anyone know if there has been any talk about it that I missed?

I think there has been no talk about it that you missed. A number of
committee members have stated previously in this group that C99
features that do not conflict with C++ feature are likely to appear in
the next revision of C++.

Regards,
Martin

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Martin von Loewis" <loewis@informatik.hu-berlin.de> wrote in message
news:j43cz8pfwh.fsf@informatik.hu-berlin.de...
> > Hello, I wondering if the C++0x standard is likely to contain C99's
> > variadic macros.
>
> Nobody knows what will be in that standard; just assume x >= 8.
>
> > Does anyone know if there has been any talk about it that I missed?
>
> I think there has been no talk about it that you missed. A number of
> committee members have stated previously in this group that C99
> features that do not conflict with C++ feature are likely to appear in
> the next revision of C++.

I'm curious because I use a template class that extracts the types out of a
parameter list of a function type into some other template with this
'signature':

template_name<number_or_args>::args<...>

For instance:

typedef typelist<3>::args<char, signed char, unsigned char>::type
character_types;

could be rewritten as

#define TYPELIST(ARGS) extract<void ARGS, typelist>::type::type

The annoying part is that you have a pass parenthesized arguments:

TYPELIST((char, signed char, unsigned char))

But with variadic macros, I could eliminated them:

#define TYPELIST(...) extract<void (__VA_ARGS__), typelist>::type::type

Then:  TYPELIST(char, signed char, unsigned char)

Not a big deal, I was just wondering.  I think it's a useful feature, that gets
rid of
TYPELIST_2
TYPELIST_3
TYPELIST_4

etc.

Paul Mensonides

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Paul Mensonides wrote:
>
> Hello, I wondering if the C++0x standard is likely to contain C99's variadic
> macros.

C++ overloading makes them far less necessary than they are in C99.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." wrote:
>
> Paul Mensonides wrote:
> >
> > Hello, I wondering if the C++0x standard is likely to contain C99's variadic
> > macros.
>
> C++ overloading makes them far less necessary than they are in C99.

How does overloading help with MACROS?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Ron Natalie" <ron@sensor.com> wrote in message
news:3C8CEE00.E1555F7A@sensor.com...
>
> "James Kuyper Jr." wrote:
> >
> > Paul Mensonides wrote:
> > >
> > > Hello, I wondering if the C++0x standard is likely to contain C99's
variadic
> > > macros.
> >
> > C++ overloading makes them far less necessary than they are in C99.
>
> How does overloading help with MACROS?

A lot of times, macros are used to simulate functions that can take more
than one type of parameter, such as MIN and MAX.  Even ignoring templates,
C++ is able to create min and max functions for many different types and
even different numbers of parameters without creating different names for
each.

I guess the question is, what OTHER use do variadic macros have, and does
that justify their inclusion in C++?  Or, does C99 compatibility alone
justify their inclusion?

Ken


---
[ 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.research.att.com/~austern/csc/faq.html                ]