frege wrote:
> Douglas Gregor wrote:
> >   - Show how variadic templates can benefit the wider C++ community.
> > Why isn't this just a feature for a few library hackers?
> >
>
> I think it is mainly for library hackers, but then the whole community
> will use the libraries.  And within every large C++ program there are
> program-specific 'libraries', and these will need variadics.  At least
> that's where I've been running into it.

Specific examples would really, really help make the case for variadic
templates.

> My biggest worry would be that we don't get it right.  Maybe that's a
> worry of the committee as well (in general, it should be, I think).

Everyone worries that they won't get it right, but that's not a reason
to stop trying. The only way to get it right is to get a coherent
proposal our to as many eyeballs as possible and, if time permits, to
implement the feature in a real compiler to play with it.

>  I
> have the same concern with 'concepts' (well that and the fact that
> concepts sounds an awful lot like 'types of types' (ie where does it
> end?) which leads to Bertrand Russell's 'system of types' which didn't
> go over well in the mathematics community, but that is a different
> story...)

That seems like a rather weak chain of reasoning :)
If you have concerns with concepts, by all means please vocalize them.
There are quite a few of us here that have in-depth knowledge of the
concepts proposals before the standard committee. We're happy to answer
any questions, but we can't guess at what those questions will be.


  Cheers,
  Doug

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Hi,

Douglas Gregor wrote:
> Specific examples would really, really help make the case for variadic
> templates.
What about in-place construction? Avoiding copy-constructors whenever
possible will definitely improve the overall view on C++ wrt
performance. As far as I know about the topic variadic templates are a
quite clean way to provide in-place construction in the standard lib.

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.comeaucomputing.com/csc/faq.html                      ]

Olaf Krzikalla wrote:
> Douglas Gregor wrote:
> > Specific examples would really, really help make the case for variadic
> > templates.
> What about in-place construction? Avoiding copy-constructors whenever
> possible will definitely improve the overall view on C++ wrt
> performance. As far as I know about the topic variadic templates are a
> quite clean way to provide in-place construction in the standard lib.

This is very interesting. Could you expand on this example, showing
exactly how one would use variadic templates to solve the problem and
how the extra copy is eliminated?

  Doug

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <1142526019.203890.282320@u72g2000cwu.googlegroups.com>,
 "Douglas Gregor" <doug.gregor@gmail.com> wrote:

> Olaf Krzikalla wrote:
> > Douglas Gregor wrote:
> > > Specific examples would really, really help make the case for variadic
> > > templates.
> > What about in-place construction? Avoiding copy-constructors whenever
> > possible will definitely improve the overall view on C++ wrt
> > performance. As far as I know about the topic variadic templates are a
> > quite clean way to provide in-place construction in the standard lib.
>
> This is very interesting. Could you expand on this example, showing
> exactly how one would use variadic templates to solve the problem and
> how the extra copy is eliminated?

I'm not up on the variadic template syntax, but the use case is
something like:

class A
{
    A(int, std::string, double, B);
    ...
};

..

vector<A> v;
v.push_back(3, "hi", 1.414, b);

as opposed to:

v.push_back(A(3, "hi", 1.414, b));

This would entail an overload of vector::push_back taking a parameter
pack, and an overload of allocator::construct taking a parameter pack.

Move semantics reduces, but does not eliminate the motivation for this
use case.  With move semantics, one may hope that A is much cheaper to
move instead of copy, and that the move constructor has been coded.  And
in this case too, vector::push_back and allocator::construct have been
overloaded appropriately to detect rvalues.  Then:

v.push_back(A(3, "hi", 1.414, b));

Creates the rvalue at this point, but move constructs it into the vector
(which is hopefully much cheaper than a copy construct).

Contrast with:

v.push_back(3, "hi", 1.414, b);

where the A is not created at all until the vector specifies the right
place to put it internally.  So in the case that A isn't cheaply
movable, you save a bundle on the expensive A(const A&).  And in the
case that A is cheaply movable, you save a little on the A(A&&).

-Howard

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Howard Hinnant <howard.hinnant@gmail.com> wrote:
> Contrast with:
> v.push_back(3, "hi", 1.414, b);
> where the A is not created at all until the vector specifies the right
> place to put it internally.

Hey, does it mean that we could (for very simple but popular scenarios)
remove requirement of container elements to be be copy-constructible
and/or assignable?! That would be a big thing!


B.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On 03/17/2006 10:57 AM, Howard Hinnant wrote:
[snip]
> class A
> {
>     A(int, std::string, double, B);
>     ...
> };
> vector<A> v;
> v.push_back(3, "hi", 1.414, b);
[snip]
It would also be useful for the auto_ptr_new
as proposed in:

  http://lists.boost.org/Archives/boost/2003/01/43503.php

I've used boost/preprocessor to try doing this, but it was
difficult and didn't work always; so, I'd find this very
useful.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <dveqbu$ghq$1@inews.gazeta.pl>,
 brok@rubikon.pl ("Bronek Kozicki") wrote:

> Howard Hinnant <howard.hinnant@gmail.com> wrote:
> > Contrast with:
> > v.push_back(3, "hi", 1.414, b);
> > where the A is not created at all until the vector specifies the right
> > place to put it internally.
>
> Hey, does it mean that we could (for very simple but popular scenarios)
> remove requirement of container elements to be be copy-constructible
> and/or assignable?! That would be a big thing!

Variadic templates could certainly ease the requirement of
CopyConstructible when moving a single item into a node-based container.
The rvalue reference proposal also reduces these requirements:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html#Introd
uction

Except for container functions which explicitly use CopyConstructible or
and CopyAssignable of the element type (such as copy construction and
copy assignment of the container itself), requirements are dropped to
MoveConstructible and and MoveAssignable.

Additionally, if we wanted, we could easily drop the MoveAssignable
requirement from most of the node-based container member functions.  LWG
issue 276 has already dropped the CopyConstructible requirement for
these latter cases.

With or without Variadic templates, in C++0X (assuming acceptance of the
rvalue reference package) you will be able to have containers of:

stringstreams
fstreams
unique_ptr (an auto_ptr replacement)
scoped_lock (e.g. boost::scoped_lock)

and any other user-defined movable but non-copyable class.

Code example:

class A
{
private:
   int* data_;              // owns pointer
   A(const A&);             // not CopyConstructible
   A& operator=(const A&);  // not CopyAssignable
public:
   A(/* whatever data */);
   A(A&& a) : data_(a.data_) {a.data_ = 0;}  // MoveConstructible
   A& operator=(A&& a)                       // MoveAssignable
      {std::swap(data_, a.data_); return *this;}
   ~A() {delete data_;}
    ...
};

std::vector<A> v;
v.push_back(A(/* whatever data */));  // ok! A <i>moved</i> in.
A a(/* whatever data */);
v.push_back(a);  // compile time error, copy constructor not accessible
v.push_back(std::move(a));  // ok! a <i>moved</i> in.

-Howard

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Howard Hinnant wrote:
> I'm not up on the variadic template syntax, but the use case is
> something like:
>
> class A
> {
>     A(int, std::string, double, B);
>     ...
> };
>
> ..
>
> vector<A> v;
> v.push_back(3, "hi", 1.414, b);
>
> as opposed to:
>
> v.push_back(A(3, "hi", 1.414, b));

Of course, an alternative not using variadic templates which works
within the existing language would be something like this:

  new(v) A(3, "hi", 1.414, b);

or, to use a more general form inserting at an arbitrary position,

  new(v, v.end()) A(3, "hi", 1.414, b);

However, I agree that the notation using variadic templates is clearer
and I'm certainly all in favor of variadic templates as these have
more uses than just this case.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Larry wrote:
> On 03/17/2006 10:57 AM, Howard Hinnant wrote:
> [snip]
>
>>class A
>>{
>>    A(int, std::string, double, B);
>>    ...
>>};
>>vector<A> v;
>>v.push_back(3, "hi", 1.414, b);
>
> [snip]
> It would also be useful for the auto_ptr_new
> as proposed in:
>
>   http://lists.boost.org/Archives/boost/2003/01/43503.php
>
> I've used boost/preprocessor to try doing this, but it was
> difficult and didn't work always; so, I'd find this very
> useful.

I think a very good motivating example is function abstraction, i.e.
implementing a function object class that can entirely and naturally
wrap any other function object and provide binding, currying, tracing,
locking etc. services on top of it.

Functional languages have shown how useful first-order functions are. In
C they are first order (pointers to functions) but you can't do anything
interesting with them. In C++ a function object behaves much like a
first-order function, but because of C++'s inability to manipulate a
function's arguments list has led to the contortions taken by Loki and
Boost's incarnations of functors.

Variadic templates would allow implementation of true, scalable (to
arbitrary parameter counts) function objects.


Andrei

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

> Variadic templates could certainly ease the requirement of
> CopyConstructible when moving a single item into a node-based container.
> The rvalue reference proposal also reduces these requirements:

As I think you've mentioned, variadic templates would be also a big
help for a general variable argument count forwarding function, such a
constructor. For example:

namespace std {

template <class T>
class allocator
{
   public:
   //...
   void construct(pointer p, const T &);
};

construct is very a limited function that forces the creation of a
copy. Now with rvalue references:

template <class Convertible>
void construct(pointer p, Convertible &&other);

We can construct outside and move to the target, or construct it from a
convertible object. But the possibility of in-place construction is
very important, so that construct is a replacement for in-place new.
Imagine building a class in a external device. Moving that object is as
expensive as copying it, if "pointer" type can't point from/to usual
memory to the device.

Variadic templates would also help libraries constructing objects in
shared memory/memory mapped files like Boost.Interprocess. Current
overload hacks to simulate variable constructor arguments with
preprocessor + mpl are very unmaintainable.

As an example, boost::optional and N1878 could have a generic
constructor that can construct the optional target from any source
combination. Current constructors:

optional ( T const& v );
optional ( optional const& rhs );

are not enough. Apart from adding a move constructor/assignment,
variadic templates would provide 0 overhead way to construct an
optional, instead of copying it (or moving it, if that's added). The
same could be applied to a variant type.

Regards,

Ion

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

I am not sure why this is necessary.  Not enough evidence is provided for
what could be achieved if we had this feature in the languages; the examples
provided are artificial and unconvincing.

The leading use case is a tuple type.  It is tempting to be able to compare
objects of compatible types and to perform a cross-assignment between them
easily.  But if you see the analogy between C++ data records to SQL data
records, you can easily see the difference between a plain structure and a
tuple type: a tuple type is a database record with no column labels.  I do
not like it - and I do not like std::pair for the same reason.  Example:

template<class p_key_t, class p_value_t> class Association { p_key_t key;
p_value_t value; };

template<class p_key_t, class p_value_t>
std::wostream &operator <<(std::wostream &p_s, Association const &p_a) {
return p_s << L'{' << p_a.key << L'\u2192' << p_a.value  << L'}'; }

In an example as above, I prefer using p_a.key and p_a.value to p_a.first
and p_a.second because the former form suggest some semantic - they function
as column names in a database.

I think that the advantage of having descriptive property names outweighs
the advantage of having compiler-generated conversions from tuple<char,
char> to tuple<int, int>.  On the other hand, you cannot have both: if you
use a plain struct with descriptive member names, you cannot get the
conversion because it only applies to tuples; if you need the conversion,
you cannot have descriptive member names.  It can be frustrating for the
programmer; moreover, it can prevent him, as it already does in the
std::pair case, from using descriptive member names, which amounts to
creating a natural tendency to use bad coding style.

Now the arguments against the supposed advantages:

Memberwise comparison is questionable because has the drawback that it
cannot use customized predicates - you can (perhaps) use only one that must
apply to all of the types involved.  While this can easily be achieved, it
would be easier to overload the comparison predicates without using tuples
at all.

The same argument applies to the assignment case as well but its weakness is
that it can also be applied to std::copy and std::copy has been agreed upon.
It would make a Defect Report: custom assignment objects, analogous to
custom predicates, cannot be used with std::copy.  The workaround of using
std::transform instead does not work with array types (array objects cannot
be assigned to).

Or perhaps, in this case, the defect report should be passed further to
missing assignment operator for array objects - the "curse of C" from the
times C had no assignment to structure objects and could not return them on
stack, which has been fixed for structures, but not for arrays?

The << operator for tuples is a misunderstanding: you cannot print the
string "C++" as C++, because you would also have to print "1 2 3" as 1 2 3
and that would make the output unreadable even for the human reader, let
alone the parser.  I would recommend using 3#"C++" and 5#"1 2 3" in this
case in order to make things simple and avoid quoting of special characters
which leads to monstrous results if applied recursively; but of course it is
a matter of taste.

Chris

Uzytkownik "faisalv" <faisalv@gmail.com> napisal w wiadomosci
news:1141276529.772735.153890@i40g2000cwc.googlegroups.com...
>I was very surprised to read in Mr. Meredith's assessment of the state
> of C++ evolution (included in the most recent C++ standard's mailing)
> that variadic templates are highly unlikely to make it into the next
> c++ standard.  Assuming his assessment is accurate, all self-respecting
> C++ metaprogrammers (from novice to expert) should find themselves
> gravely disappointed. Variadic templates have the potential of being to
> C++ metaprogramming what lists are to lisp.  I would think that they
> would be considered as one of the cornerstones of C++ metaprogramming
> and thus would receive a great deal of attention from the evolution
> committee.  Is there anything that can still be done to ensure there
> inclusion?  I would be more than happy to lend my efforts to the cause,
> should someone feel confident enough to technically spearhead the
> project.
>
> I am including a link to the 3rd revision of the proposal for all to
> read:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1704.pdf
>
> regards,
> Faisal Vali, MD, MSc
>
> ---
> [ 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.comeaucomputing.com/csc/faq.html                      ]
>


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

krixel@qed.pl ("Krzysztof Zelechowski") writes:

> I am not sure why this is necessary.  Not enough evidence is provided for
> what could be achieved if we had this feature in the languages; the examples
> provided are artificial and unconvincing.

Maybe unconvincing, but hardly artificial.

> The leading use case is a tuple type.

..which was chosen because it is a real, useful example, and a
library that was accepted into TR1 (in part because of its
usefulness).

> It is tempting to be able to compare objects of compatible types and
> to perform a cross-assignment between them easily.  But if you see
> the analogy between C++ data records to SQL data records, you can
> easily see the difference between a plain structure and a tuple
> type: a tuple type is a database record with no column labels.  I do
> not like it - and I do not like std::pair for the same reason.

Whether or not you like it, tuples are extremely useful in generic
code.  They're not just "lazy man's structs."  Think of them, if you
like, as heterogeneous sequences.  You don't need to label every
element of a built-in array, do you?

For a real use case, see boost::zip_iterator<>.

Anyway, tuples are just an example.  The boost/tr1 bind and boost/tr1
function libraries, too, would benefit from the proposed feature.  Not
to mention countless other popular libraries in Boost (Python, Lambda,
Spirit, Phoenix, Fusion, etc...) and at least one in Loki (in case you
have something against Boost) that I can think of.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.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.comeaucomputing.com/csc/faq.html                      ]

faisalv wrote:
> I was very surprised to read in Mr. Meredith's assessment of the state
> of C++ evolution (included in the most recent C++ standard's mailing)
> that variadic templates are highly unlikely to make it into the next
> c++ standard.  Assuming his assessment is accurate, all self-respecting
> C++ metaprogrammers (from novice to expert) should find themselves
> gravely disappointed. Variadic templates have the potential of being to
> C++ metaprogramming what lists are to lisp.  I would think that they
> would be considered as one of the cornerstones of C++ metaprogramming
> and thus would receive a great deal of attention from the evolution
> committee.

Variadic templates are definitely a powerful feature for template
metaprogramming. The problem with variadic templates is that they
appear to only serve the C++ template metaprogramming segment of the
C++ community, and that segment is a relatively small part of the
entire C++ community. For variadic templates to move forward in the
evolution working group, its proponents need to make the case that they
can improve C++ for the community as a whole.

> Is there anything that can still be done to ensure there
> inclusion?

There is no way to ensure inclusion, but I believe that variadic
templates might still be discussed if a solid, direct proposal became
available before the Berlin meeting in April. No guarantees, but there
will be proponents of variadic templates at the meeting.

> I would be more than happy to lend my efforts to the cause,
> should someone feel confident enough to technically spearhead the
> project.

Well, I'm the primary author of the most recent variadic templates
proposals. I am willing to lead the effort to produce a revised
proposal for Berlin, but I'll need help. If we can finish before the
Berlin meeting, we have a chance of gaining acceptance in C++0x... but
nothing is certain.

To maximize our chances at getting variadic templates accepted into
C++0x, there are a few things we need to do. I'm assuming that you
agree with the basic syntax and semantics of N1704, but nothing is set
in stone.

  - Show how variadic templates can benefit the wider C++ community.
Why isn't this just a feature for a few library hackers?

  - Abandon the "a la carte" style of N1704 in favor of a small,
simple, direct proposal. We should only ask for the minimal features
needed to make variadic tempates work, and not discuss any alternatives
(they're in a previous document). In essence, we need to say "do this",
not "we could do this... or this...".

  - Determine whether variadic templates could also solve some of the
issues that pop up with initializers (see N1890 for the problems and
proposed solutions). If we view an aggregate initializer {'C', 17,
3.14159} as a "parameter pack", does that give us a better way to
initialize sequences than sequence constructors? Does it allow us to
simulate aggregate initialization for a complex user-defined type?
These are the kinds of issues that help show the benefits to the wider
community.

  - Take a look at Scheme macros. Many people have noted the
similarities between our variadic templates proposals and Scheme
macros; we should see how the Scheme community uses macros, both to
determine whether we have variadic templates "right" and for additional
motivation.

  - Implement it. This is perhaps a pipe dream, but if we had time to
implement variadic templates in GCC it would make the extension more
"real" for the committee. We did this with concepts, and I think it
really helped show that concepts for C++ are attainable and have real
benefits for programmers. The good news is that variadic templates are
a LOT easier to implement than concepts; the bad news is that I'm not
sure we could pull it off in only a few weeks.

Is there general interest in a revised variadic templates proposal?

  Doug

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Douglas Gregor <doug.gregor@gmail.com> wrote:
>  - Show how variadic templates can benefit the wider C++ community.
> Why isn't this just a feature for a few library hackers?

typesafe replacement for unsafe variadic C-style macros alone is
indispensable; other uses are yet to be explored, but seems to be quite
interesting and definitely useful. I feel that it would (together with
Concepts) help C++ a lot in area of generic programming, without burden
of "advanced metaprogramming hackery".

I'm definitely interested in this proposal. I agree that there are two
areas that should be explored:
- how they interact (complement? simulate? replace?) initializer lists
- how similar functionality is deployed in other programming languages


B.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Douglas Gregor wrote:
> faisalv wrote:
>
.
>
> Well, I'm the primary author of the most recent variadic templates
> proposals. I am willing to lead the effort to produce a revised
> proposal for Berlin, but I'll need help. If we can finish before the
> Berlin meeting, we have a chance of gaining acceptance in C++0x... but
> nothing is certain.
>

Thanks for the work so far.

> To maximize our chances at getting variadic templates accepted into
> C++0x, there are a few things we need to do. I'm assuming that you
> agree with the basic syntax and semantics of N1704, but nothing is set
> in stone.
>
>   - Show how variadic templates can benefit the wider C++ community.
> Why isn't this just a feature for a few library hackers?
>

I think it is mainly for library hackers, but then the whole community
will use the libraries.  And within every large C++ program there are
program-specific 'libraries', and these will need variadics.  At least
that's where I've been running into it.

Also, I'm sure once upon a time, templates were considered only for
library hackers...

>   - Abandon the "a la carte" style of N1704 in favor of a small,
> simple, direct proposal. We should only ask for the minimal features
> needed to make variadic tempates work, and not discuss any alternatives
> (they're in a previous document). In essence, we need to say "do this",
> not "we could do this... or this...".
>

At an absolute minimum (which I'd be sad if that's all we got, but it
would be better than nothing), I would at least like a special case of
default template params to work for template functions.  ie:

struct Nil {};

template <typename T1 = Nil, typename T2 = Nil, typename Tn = Nil>
void some_func(T1 t1 = Nil(), T2 t2 = Nil(), Tn tn = Nil())
{
.
}

ie the special case where the default template args match the default
function args should be allowable in C++.  This would allow me to
eliminate much of the repetitiveness.  But it would still leave me
doing 'hacks'.

As I said, at a very sad minimum.  I'd only bring it up if/when any
other variadic proposal is turned down.

>   - Determine whether variadic templates could also solve some of the
> issues that pop up with initializers (see N1890 for the problems and
> proposed solutions). If we view an aggregate initializer {'C', 17,
> 3.14159} as a "parameter pack", does that give us a better way to
> initialize sequences than sequence constructors? Does it allow us to
> simulate aggregate initialization for a complex user-defined type?
> These are the kinds of issues that help show the benefits to the wider
> community.
>
>   - Take a look at Scheme macros. Many people have noted the
> similarities between our variadic templates proposals and Scheme
> macros; we should see how the Scheme community uses macros, both to
> determine whether we have variadic templates "right" and for additional
> motivation.
>

My biggest worry would be that we don't get it right.  Maybe that's a
worry of the committee as well (in general, it should be, I think).  I
have the same concern with 'concepts' (well that and the fact that
concepts sounds an awful lot like 'types of types' (ie where does it
end?) which leads to Bertrand Russell's 'system of types' which didn't
go over well in the mathematics community, but that is a different
story...)

>
> Is there general interest in a revised variadic templates proposal?
>

I sure would like to see some (_any_) improvements - the current state
of affairs is killing my sense of coding aesthetics.

>   Doug
>

Tony

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

I was very surprised to read in Mr. Meredith's assessment of the state
of C++ evolution (included in the most recent C++ standard's mailing)
that variadic templates are highly unlikely to make it into the next
c++ standard.  Assuming his assessment is accurate, all self-respecting
C++ metaprogrammers (from novice to expert) should find themselves
gravely disappointed. Variadic templates have the potential of being to
C++ metaprogramming what lists are to lisp.  I would think that they
would be considered as one of the cornerstones of C++ metaprogramming
and thus would receive a great deal of attention from the evolution
committee.  Is there anything that can still be done to ensure there
inclusion?  I would be more than happy to lend my efforts to the cause,
should someone feel confident enough to technically spearhead the
project.

I am including a link to the 3rd revision of the proposal for all to
read:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1704.pdf

regards,
Faisal Vali, MD, MSc

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <1141276529.772735.153890@i40g2000cwc.googlegroups.com>,
 "faisalv" <faisalv@gmail.com> wrote:

> I was very surprised to read in Mr. Meredith's assessment of the state
> of C++ evolution (included in the most recent C++ standard's mailing)
> that variadic templates are highly unlikely to make it into the next
> c++ standard.  Assuming his assessment is accurate, all self-respecting
> C++ metaprogrammers (from novice to expert) should find themselves
> gravely disappointed. Variadic templates have the potential of being to
> C++ metaprogramming what lists are to lisp.  I would think that they
> would be considered as one of the cornerstones of C++ metaprogramming
> and thus would receive a great deal of attention from the evolution
> committee.  Is there anything that can still be done to ensure there
> inclusion?  I would be more than happy to lend my efforts to the cause,
> should someone feel confident enough to technically spearhead the
> project.
>
> I am including a link to the 3rd revision of the proposal for all to
> read:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1704.pdf

At the risk of nothing more than a "me too" post, I would also love to
see variadic templates in C++0X.  This proposed language feature is very
close to the top of my personal wish list.

-Howard

---
[ 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.comeaucomputing.com/csc/faq.html                      ]