C++0X parameter packs as last arguments only

Discussion in 'C++' started by Marc, Oct 16, 2010.

  1. Marc

    Marc Guest

    Hello,

    in C++0X, we can have functions with a number of arguments that is not
    fixed, which is cool:

    template<class...U> void f(double d,U... u);

    However, there is a restriction that the parameter pack must be the last
    argument, so I cannot write:

    template<class...U> void g(U... u,double d);

    I understand that having 2 parameter packs wouldn't make sense (or at
    least would be much more complicated), but as long as there is just one,
    I am not sure why it has to be at the end. Is it just to simplify the
    partial ordering of overloads for the compiler?

    I know this can be worked around with tuple manipulations (Daniel
    Krügler showed me the cool technique on clc++m a couple months ago), but
    it is incredibly more complicated.
    Marc, Oct 16, 2010
    #1
    1. Advertising

  2. Marc posted this message in ROT13 encoding:

    > Hello,
    >
    > in C++0X, we can have functions with a number of arguments that is not
    > fixed, which is cool:
    >
    > template<class...U> void f(double d,U... u);
    >
    > However, there is a restriction that the parameter pack must be the last
    > argument, so I cannot write:
    >
    > template<class...U> void g(U... u,double d);
    >
    > I understand that having 2 parameter packs wouldn't make sense (or at
    > least would be much more complicated), but as long as there is just one,
    > I am not sure why it has to be at the end. Is it just to simplify the
    > partial ordering of overloads for the compiler?


    Probably because the size of "..." is not known, so that the compiler would
    not where to push the following arguments.

    --
    Passwords are implemented as a result of insecurity.
    Chris Ahlstrom, Oct 16, 2010
    #2
    1. Advertising

  3. Marc

    Marc Guest

    Chris Ahlstrom wrote:

    > Marc posted this message in ROT13 encoding:


    Qvq V? V zhfg unir orra qvfgenpgrq.

    >> Hello,
    >>
    >> in C++0X, we can have functions with a number of arguments that is not
    >> fixed, which is cool:
    >>
    >> template<class...U> void f(double d,U... u);
    >>
    >> However, there is a restriction that the parameter pack must be the last
    >> argument, so I cannot write:
    >>
    >> template<class...U> void g(U... u,double d);
    >>
    >> I understand that having 2 parameter packs wouldn't make sense (or at
    >> least would be much more complicated), but as long as there is just one,
    >> I am not sure why it has to be at the end. Is it just to simplify the
    >> partial ordering of overloads for the compiler?

    >
    > Probably because the size of "..." is not known, so that the compiler would
    > not where to push the following arguments.


    Uh? I am talking about the C++0X variadics, where the size is perfectly
    well known. Not about the C-inherited "..." where the size is indeed a
    runtime property.
    Marc, Oct 16, 2010
    #3
  4. On Oct 16, 5:14 am, Marc <> wrote:
    > Hello,
    >
    > in C++0X, we can have functions with a number of arguments that is not
    > fixed, which is cool:
    >
    > template<class...U> void f(double d,U... u);
    >
    > However, there is a restriction that the parameter pack must be the last
    > argument, so I cannot write:
    >
    > template<class...U> void g(U... u,double d);
    >
    > I understand that having 2 parameter packs wouldn't make sense (or at
    > least would be much more complicated), but as long as there is just one,
    > I am not sure why it has to be at the end. Is it just to simplify the
    > partial ordering of overloads for the compiler?
    >
    > I know this can be worked around with tuple manipulations (Daniel
    > Krügler showed me the cool technique on clc++m a couple months ago), but
    > it is incredibly more complicated.


    See:

    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1603.pdf

    Section 5.4.

    It was considered and just didn't happen because it wasn't a
    sufficiently high priority.

    -Howard
    Howard Hinnant, Oct 17, 2010
    #4
  5. Marc

    Marc Guest

    Howard Hinnant wrote:

    > On Oct 16, 5:14 am, Marc <> wrote:
    >> Hello,
    >>
    >> in C++0X, we can have functions with a number of arguments that is not
    >> fixed, which is cool:
    >>
    >> template<class...U> void f(double d,U... u);
    >>
    >> However, there is a restriction that the parameter pack must be the last
    >> argument, so I cannot write:
    >>
    >> template<class...U> void g(U... u,double d);
    >>
    >> I understand that having 2 parameter packs wouldn't make sense (or at
    >> least would be much more complicated), but as long as there is just one,
    >> I am not sure why it has to be at the end. Is it just to simplify the
    >> partial ordering of overloads for the compiler?
    >>
    >> I know this can be worked around with tuple manipulations (Daniel
    >> Krügler showed me the cool technique on clc++m a couple months ago), but
    >> it is incredibly more complicated.

    >
    > See:
    >
    > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1603.pdf
    >
    > Section 5.4.
    >
    > It was considered and just didn't happen because it wasn't a
    > sufficiently high priority.


    Thank you for the reference.

    At least the possibility to revisit the issue for some later revision of
    the standard seems open...
    Marc, Oct 17, 2010
    #5
  6. Howard Hinnant posted this message in ROT13 encoding:

    > On Oct 16, 5:14 am, Marc <> wrote:
    >> Hello,
    >>
    >> in C++0X, we can have functions with a number of arguments that is not
    >> fixed, which is cool:
    >>
    >> template<class...U> void f(double d,U... u);
    >>
    >> However, there is a restriction that the parameter pack must be the last
    >> argument, so I cannot write:
    >>
    >> template<class...U> void g(U... u,double d);
    >>
    >> I understand that having 2 parameter packs wouldn't make sense (or at
    >> least would be much more complicated), but as long as there is just one,
    >> I am not sure why it has to be at the end. Is it just to simplify the
    >> partial ordering of overloads for the compiler?
    >>
    >> I know this can be worked around with tuple manipulations (Daniel
    >> Krügler showed me the cool technique on clc++m a couple months ago), but
    >> it is incredibly more complicated.

    >
    > See:
    >
    > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1603.pdf
    >
    > Section 5.4.
    >
    > It was considered and just didn't happen because it wasn't a
    > sufficiently high priority.


    We feel that the few operations that would benefit may better be
    accomplished by working with a true heterogeneous data structure such as
    a tuple.

    Thanks for the reference!

    --
    : Any porters out there should feel happier knowing that DEC is shipping
    : me an AlphaPC that I intend to try getting linux running on: this will
    : definitely help flush out some of the most flagrant unportable stuff.
    : The Alpha is much more different from the i386 than the 68k stuff is, so
    : it's likely to get most of the stuff fixed.

    It's posts like this that almost convince us non-believers that there
    really is a god.

    -- Anthony Lovell, to Linus's remarks about porting
    Chris Ahlstrom, Oct 17, 2010
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sangram
    Replies:
    16
    Views:
    1,978
  2. Johny
    Replies:
    8
    Views:
    389
  3. Great Job
    Replies:
    0
    Views:
    416
    Great Job
    Feb 9, 2008
  4. Victor Bazarov
    Replies:
    7
    Views:
    481
    Zhihao Yuan
    Nov 30, 2012
  5. Zhihao Yuan
    Replies:
    0
    Views:
    235
    Zhihao Yuan
    Nov 30, 2012
Loading...

Share This Page