Christopher Eltschka wrote:
>> class A {};
>> void copy(A from, A to);           // function one
>> void copy(A from: from, A to: to); // function two
>> void copy(A from: f, A to: t);     // redeclaration of function two

Paul D. DeRocco wrote:
> Would the following represent two overloaded functions?
>         void copy(A from: f, A to: t);
>         void copy(A first: f, A second: s);
>
> The types are the same--only the keynames are different.

Which only serves to illustrate why having more than one name per
argument is a bad idea.

> This could be useful.

I doubt it.  One name is enough; two is confusing.  If you need more
than one name, then you're probably doing something wrong.

> Occasionally one finds oneself arbitrarily using a different
> type, just to force overload resolution to choose a different
> function:
>         void fill(char c, int n);      // output n copies of c
>         void fill(char c, unsigned n); // output c until column n
>
> could better be written as:
>         void fill(char char: c, int tocolumn: n);
>         void fill(char char: c, int count: n);

(Note: 'char' is a reserved word, so it can't be used as an
identifier.)

No, they could be better written as:

    void fill(char c, int count);
    void fillTo(char c, int tocolumn);

Here you're creating confusion by using the same function name for
doing different things.  In this case, it's probably clearer simply
to give the two functions different names.

Adding extra arguments names doesn't buy you anything you don't
already have; you can already choose descriptive names for arguments
in function prototypes.  Allowing two names doesn't buy you anything
extra; indeed, it only creates more confusion.

> Also, I'm not sure the keyname wants to be before the identifier:
>         void foo(int (*func: f)(int, char*), int* val: v);
>
> might be more clearly written:
>         void foo(func: int(*)(int, char*), val: int* v);

Yeesh.  And I thought the existing syntax for function pointers
was already complicated enough.  (Besides, you left out the names
for the arguments to 'func'.)  What's wrong with keeping it simple,
like this:

    void foo(int (*func)(int n, char *s), int *val);

Let's keep things simple unless we really really really need a
change, okay?

-- David R. Tribble, dtribble@technologist.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> Yeesh.  And I thought the existing syntax for function pointers
> was already complicated enough.  (Besides, you left out the names
> for the arguments to 'func'.)  What's wrong with keeping it simple,
> like this:
>
>     void foo(int (*func)(int n, char *s), int *val);

Personally, I like leaving out the parameter names inside function
parameters. That way, when I read across, the only non-type names I see
are those that are actually parameters to foo, which makes it easier to
find those parameters when the entire declaration is long and complex.

--

Ciao,
Paul


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35C7E025.DA742B87@ix.netcom.com>,
  "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
> David R Tribble wrote:
> >
> > Yeesh.  And I thought the existing syntax for function pointers
> > was already complicated enough.  (Besides, you left out the names
> > for the arguments to 'func'.)  What's wrong with keeping it simple,
> > like this:
> >
> >     void foo(int (*func)(int n, char *s), int *val);
>
> Personally, I like leaving out the parameter names inside function
> parameters. That way, when I read across, the only non-type names I see
> are those that are actually parameters to foo, which makes it easier to
> find those parameters when the entire declaration is long and complex.

I wouldn't advocate leaving out *all* parameter names, even from
function parameters. But when the only useful names I have are "n"
and "s" -- well, go ahead and nuke 'em.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka wrote:
>
> class A {};
> void copy(A from, A to);           // function one
> void copy(A from: from, A to: to); // function two
> void copy(A from: f, A to: t);     // redeclaration of function two

Would the following represent two overloaded functions?

 void copy(A from: f, A to: t);
 void copy(A first: f, A second: s);

The types are the same--only the keynames are different. This could be
useful. Occasionally one finds oneself arbitrarily using a different
type, just to force overload resolution to choose a different function:

 void fill(char c, int n);      // output n copies of c
 void fill(char c, unsigned n); // output c until column n

could better be written as:

 void fill(char char: c, int tocolumn: n);
 void fill(char char: c, int count: n);

Also, I'm not sure the keyname wants to be before the identifier:

 void foo(int (*func: f)(int, char*), int* val: v);

might be more clearly written:

 void foo(func: int(*)(int, char*), val: int* v);

--

Ciao,
Paul
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul D. DeRocco wrote:
>
> Christopher Eltschka wrote:
> >
> > class A {};
> > void copy(A from, A to);           // function one
> > void copy(A from: from, A to: to); // function two
> > void copy(A from: f, A to: t);     // redeclaration of function two
>
> Would the following represent two overloaded functions?
>
>         void copy(A from: f, A to: t);
>         void copy(A first: f, A second: s);
>

Yes - if you look up the posting I mentioned in DejaNews, you'll
see an example with a complex class with constructors like this:

class Complex
{
public:
  Complex(double re, double im=0); // traditional constructor
  Complex(double re: re = 0, double im: im = 0); // Explicitly state
re/im
  Complex(double abs: abs=1, double arg: arg); // Given as abs/arg
// ...
};

Now you'd be able to create Complex numbers like this:

Complex c1(1.0);               //  1.0 + 0.0i
Complex c2(1.0, 2.0);          //  1.0 + 2.0i
Complex c3(re: 2.0, im: 4.0);  //  2.0 + 4.0i
Complex c4;                    //  0.0 + 0.0i
Complex c5(im: 1.5);           //  0.0 + 1.5i
Complex c6(arg: M_PI/2);       //  0.0 + 1.0i
Complex c7(abs: 2, arg, M_PI); // -2.0 + 0.0i

[... some examples snipped ...]

> Also, I'm not sure the keyname wants to be before the identifier:
>
>         void foo(int (*func: f)(int, char*), int* val: v);
>
> might be more clearly written:
>
>         void foo(func: int(*)(int, char*), val: int* v);

Yes, I've already thought of that syntax as well (I've posted it along
with my correction of the "argument name independant of the argument
name" mistake).


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:

[...]

> Nathan Myers wrote:
> > In C++ (perhaps unlike in C) it's considered bad style to define
> > a function with so many arguments that somebody would want to name
> > them in a call.  For an example of such bad style, consider
> > std::basic_string<> members, and consider some of the ways it
> > have been done otherwise.
>
> Yes, but how many is too many?

Two:

copy(a, b); // does this copy a to b, ot does it copy b to a?

Named arguments solve this:

copy(from: a, to: b);

The compatibility problem can be solved with a rule proposed
independantly by Bradd W. Szonye and me (even with the same syntax,
which I used in my example above):

The name of the argument is completely independant of the name of
the argument. Arguments which don't specify a name are positional
arguments, while arguments specifying a name are position-independant
and *must* be used with that name. Overloading on names is possible,
that is:

class A {};
void copy(A from, A to);           // function one
void copy(A from: from, A to: to); // function two
void copy(A from: f, A to: t);     // redeclaration of function two

A a, b;

copy(a, b);               // calls void copy(A, A)
copy(from: a, to: b);     // calls void copy(A from:, A to:)
copy(a, to: b);           // error: no copy(A, A to:)

For more info, look for Bradd's posting "More on argument keywords"
and my posting in the thread "PROPOSAL: More flexible initializer
syntax."
in the "old" archive of DejaNews.

Adopting that to C would probably be problematic, since C has no
concept of overloading.

[...]
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka wrote:
>
> David R Tribble wrote:
>
> [...]
>
> > Nathan Myers wrote:
> > > In C++ (perhaps unlike in C) it's considered bad style to define
> > > a function with so many arguments that somebody would want to name
> > > them in a call.  For an example of such bad style, consider
> > > std::basic_string<> members, and consider some of the ways it
> > > have been done otherwise.
> >
> > Yes, but how many is too many?
>
> Two:
>
> copy(a, b); // does this copy a to b, ot does it copy b to a?
>
> Named arguments solve this:
>
> copy(from: a, to: b);
>
> The compatibility problem can be solved with a rule proposed
> independantly by Bradd W. Szonye and me (even with the same syntax,
> which I used in my example above):
>
> The name of the argument is completely independant of the name of
> the argument. Arguments which don't specify a name are positional

Oops! This should of course be:

The name of the argument is completely independant of the name of
the variable holding the argument.

That is,

  void copy(MyClass from: from, MyClass to: to)

is as legal as

  void copy(MyClass from: a, MyClass to: b)

and both refer to the same function. (As does

  void copy(MyClass from:, MyClass to:)

and

  void copy(MyClass to:, MyClass from:)

).

Maybe it would give a better syntax if the name was put in front
of the type:

  void copy(from: MyClass, to: MyClass);

  void copy(from: MyClass a, to: MyClass b)
  {
    b = a;
  }

Indeed, I think that syntax would be better. (The call syntax remains
unaffected, of course.)

> arguments, while arguments specifying a name are position-independant
> and *must* be used with that name. Overloading on names is possible,
> that is:
>
> class A {};
> void copy(A from, A to);           // function one
> void copy(A from: from, A to: to); // function two
> void copy(A from: f, A to: t);     // redeclaration of function two
>
> A a, b;
>
> copy(a, b);               // calls void copy(A, A)
> copy(from: a, to: b);     // calls void copy(A from:, A to:)
> copy(a, to: b);           // error: no copy(A, A to:)
>
> For more info, look for Bradd's posting "More on argument keywords"
> and my posting in the thread "PROPOSAL: More flexible initializer
> syntax."
> in the "old" archive of DejaNews.
>
> Adopting that to C would probably be problematic, since C has no
> concept of overloading.
>
> [...]
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35C1F217.CC55F191@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> The name of the argument is completely independant of the name of
> the argument.

The nouns in that sentance are independant of the nouns in that sentance...

You'll need to give these two things different terminology before that
can make sense. Perhaps you should have said:
    "The formal parameter names are independent of the actual parameter
    names, even in the prototype."
Although I'm not certain I agree.

> class A {};
> void copy(A from, A to);           // function one
> void copy(A from: from, A to: to); // function two
> void copy(A from: f, A to: t);     // redeclaration of function two

In the third case, if "from" is a sufficient parameter name, then there
should be no need to give the "from" variable the name f. The only thing
that's needed is some syntax to signify that the parameter name was
intended for use in function overloading or not; that way function
prototypes such as
    char * strcpy(char*to, const char*from);
don't suddenly start requiring a "to" and a "from" section unless it's
done deliberately.

But giving the same parameter two names, one for calling and one for
"local" use... IMHO this is a mistake.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35AEC6A5.1939DCFC@ix.netcom.com>, Paul D. DeRocco
<pderocco@ix.netcom.com> writes
>There is no easy way, short of cluttering every function argument with
>/*name*/ comments, to embed the names of parameters in existing C/C++
>source. And inserting such comments automatically would be undesireable
>because many functions don't need such commenting. (E.g., pow(x, y)).

Algol 60 had an interesting feature: the delimiter between two
parameters in a function definition *or* a function call could be either
of:
    comma
    close paren, string of letters, digits and spaces, colon, open paren

In other words, I could write:

    arctan2 (x, y)
or
    arctan2 (x) divided by:(y)

This let you add the documentation when you needed it, though I'm not
sure how you'd map the syntax to C.

--
Clive D.W. Feather   | Regulation Officer, LINX | Work: <clive@linx.org>
Tel: +44 1733 705000 | (on secondment from      | Home: <cdwf@i.am>
Fax: +44 1733 353929 |  Demon Internet)         | <http://i.am/davros>
Written on my laptop; please observe the Reply-To address
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35AB743C.167E@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> AllanW@my-dejanews.com wrote:
> >
> > In article <35AA46DE.794B@wizard.net>,
> >   James Kuyper <kuyper@wizard.net> wrote:
> > > Designated initializers use a brand new syntax, so they would take a bit
> > > more work to add to the next version of C++. However, I don't believe
> > > the new syntax would conflict with any existing C++ syntax:
> > >
> > >       func((struct BigPods){.x=1.0, .count = 1});

[snip]
> > Probably the biggest problem [[other than the initial shock -- this is
> > SOOOO different than what we have now]] is how to handle a call with
> > a mixture of positional and named arguments, especially in the presence
> > of default arguments.
> >     itoa(.base=16, 0, x);
> > Is x the buffer, and 0 the value?  Or vice-versa?
> >     itoa(10, 8, .buffer=x);
> > Argument 2 (.buffer) given twice?  Or do we handle all named arguments
> > first, and make a second pass for remainder?  Difficult.
> >
> > In my opinion the best answer is to simply disallow it.  Either all
> > arguments are named, or all are positional.  Overload resolution could
> > get a bit tricky too, but I doubt it would be an impossible hurdle.
>
> The C9X standard has chosen a different option. Designators cause a skip
> to the specified member, and following initializers that have no
> designator will be assigned in order starting from there. Initialization
> of the same member multiple times is permitted; each ocurrance overrides
> the previous ones.

An interesting solution.  Seems to me that the closest thing to a
precedent comes from enumerations, where the same value can be used
with multiple identifiers.

I can see value in the rule that named designators cause the
arguments to "skip" to that one, especially when combined with
default arguments:
    void baz(int a1, int a2=0, int a3=0, int a4=0, int a5=0, int a6=0,
             int b1=0, int b2=0, int b3=0, int b4=0, int b5=0, int b6=0);
    /* ... */
    baz(1, 2, .b1=1, 2);

But allowing the same member multiple times causes some of the
settings to be ignored?  I should have paid more attention to the
C standard -- this is just downright wierd!

    int foo(int a, int b, int c, int d);
    int bar(int x) { printf("%d\n",x); return x; }

    /* ... */
    foo(bar(1),bar(2),bar(3),.b=bar(4),bar(5),bar(6),.d=bar(7),.a=bar(8));

Is this legal?  If so, does this call bar() 8 times or 4 times?

    foo(1, 2, 3, 4, .a=1, 2, 3, 4, .b=2, 3, 4, .c=3, 4, .d=4);

Is this legal too?  Is it at least considered bad programming style?
Personally, I would assume that foo() had at least 14 arguments...

> Overload resolution is one issue that would make transferring this C
> innovation over to C++ trickier than I first thought.

It does get very hairy.  We can of course fall back on the concept of
"ambiguous" calls -- if two or more functions are equally good matches,
then the call is invalid.  But we shouldn't make this rule any more
prevalent than we absolutely have to -- whenever we can define one
function to be a better match than another, we should do so.

I figured out some time ago (in my own mind, at least) that not
allowing both named and positional arguments would help a lot.  I had
always assumed that any one parameter could only be supplied twice,
however.  Is that something we want to replicate in C++, for the sake
of consistency/portability, or would this be easy to drop?

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6oed8c$2oh$1@nnrp1.dejanews.com>, one paragraph's formatting
got removed somehow.
> In article <35AA46DE.794B@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> > Designated initializers use a brand new syntax, so they would take a bit
> > more work to add to the next version of C++. However, I don't believe
> > the new syntax would conflict with any existing C++ syntax:
> >
> >  func((struct BigPods){.x=1.0, .count = 1});
>
> I've worked with two language that supported named parameters.
> Ironically, both were among the few languages considered "lower-level"
> than C: one was the PDP-11 Macro assembly language, and one was the
> VAX Macro assembly language.  In each case, they had provisions for
> allowing arguments to be either named or positional, and supplied
> rules for how to disambiguate when both were used in the same call.

It would be a radical change for C++, but I would love it. I think
that
    itoa(.value=10, .buffer=buffer, .base=8);
    // (Not neccesarily this syntax)
is a lot easier to maintain than
    itoa(10, buffer, 8); // Is this "0000010" -- 7 digits plus null
                         //   terminator?
                         // Or is it "8" -- number 8 in base 10?
                         // Or is it "12" -- number 10 in base 8?

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

  James Kuyper <kuyper@wizard.net> wrote:
> Designated initializers use a brand new syntax, so they would take a bit
> more work to add to the next version of C++. However, I don't believe
> the new syntax would conflict with any existing C++ syntax:
>
>  func((struct BigPods){.x=1.0, .count = 1});


'keyword arguments' is exactly the example discussed in (Bjarne Stroustrup's)
Design and Evolution of C++ as
'a proposed extension that is neat, but it is possible in C++ already'.
It's section 6.5.1.
The idea is to use a helper class:
class w_args {
...
public:
 w_args() // set defaults
  wc(black), wx(0),...
 w_args& color(color c) { wc = c; return *this;}
 w_args& x(int x) { wx = x; return *this;}
...
}

and use it in a class window with constructors
window() ; // default
window(w_args wa); // set options from wa

which can then be constructed as
window w(w_args().color(green).x(5))

(I remember having seen this bit online somewhere as well,
but I can't remember where).
--
Jeroen Nijhof      J.H.B.Nijhof@aston.ac.uk
Accordion Links    http://www-th.phys.rug.nl/~nijhof/accordions.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>
> In article <35AB743C.167E@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> > AllanW@my-dejanews.com wrote:
> > >
> > > In article <35AA46DE.794B@wizard.net>,
> > >   James Kuyper <kuyper@wizard.net> wrote:
> > > > Designated initializers use a brand new syntax, so they would take a bit
> > > > more work to add to the next version of C++. However, I don't believe
> > > > the new syntax would conflict with any existing C++ syntax:
> > > >
> > > >       func((struct BigPods){.x=1.0, .count = 1});
>
> [snip]
> > > Probably the biggest problem [[other than the initial shock -- this is
> > > SOOOO different than what we have now]] is how to handle a call with
> > > a mixture of positional and named arguments, especially in the presence
> > > of default arguments.
> > >     itoa(.base=16, 0, x);
> > > Is x the buffer, and 0 the value?  Or vice-versa?
> > >     itoa(10, 8, .buffer=x);
> > > Argument 2 (.buffer) given twice?  Or do we handle all named arguments
> > > first, and make a second pass for remainder?  Difficult.
> > >
> > > In my opinion the best answer is to simply disallow it.  Either all
> > > arguments are named, or all are positional.  Overload resolution could
> > > get a bit tricky too, but I doubt it would be an impossible hurdle.
> >
> > The C9X standard has chosen a different option. Designators cause a skip
> > to the specified member, and following initializers that have no
> > designator will be assigned in order starting from there. Initialization
> > of the same member multiple times is permitted; each ocurrance overrides
> > the previous ones.
>
> An interesting solution.  Seems to me that the closest thing to a
> precedent comes from enumerations, where the same value can be used
> with multiple identifiers.
>
> I can see value in the rule that named designators cause the
> arguments to "skip" to that one, especially when combined with
> default arguments:
>     void baz(int a1, int a2=0, int a3=0, int a4=0, int a5=0, int a6=0,
>              int b1=0, int b2=0, int b3=0, int b4=0, int b5=0, int b6=0);
>     /* ... */
>     baz(1, 2, .b1=1, 2);
>

I'm sorry I didn't catch this earlier. You're mixing up the
initialization of structure members with the assignment of arguments to
function parameters. Those are two entirely different things. The
confusion may have come from my providing an example of a function
defined to take a structure as an argument.  As far as I know, the
syntax you give above is not part of C9X, but the following rewrite is:

 struct baz{
  int a1, a2, a3, a4, a5, a6, b1, b2, b3, b4, b5, b6;
 };
 struct baz bz={1, 2, .b1=1, 2};


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6og44i$65v$1@nnrp1.dejanews.com>,  <AllanW@my-dejanews.com> wrote:

> It would be a radical change for C++, but I would love it. I think
> that
>     itoa(.value=10, .buffer=buffer, .base=8);
>     // (Not neccesarily this syntax)
> is a lot easier to maintain than
>     itoa(10, buffer, 8); // Is this "0000010" -- 7 digits plus null
>                          //   terminator?
>                          // Or is it "8" -- number 8 in base 10?
>                          // Or is it "12" -- number 10 in base 8?

Suppose the vendor of a C++ programming environment were to add an option
to display information about the arguments when displaying a program,
much as some environments already display keywords and comments in
different colors?  Such an option would solve your maintainability problem,
and would not require any change to the language at all.

In general, I would like to encourage the programming community to think
about the potential of tools that manipulate programs in ways that
offer useful facilities to programmers without changing the language
definition.  A stable language definition is important for communication,
so by putting tools into the development environments, we improve both
communication and maintainability.
--
    --Andrew Koenig
      ark@research.att.com
      http://www.research.att.com/info/ark



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> wrote:
>>> Designated initializers use a brand new syntax, so they would take a
>>> bit more work to add to the next version of C++. However, I don't
>>> believe the new syntax would conflict with any existing C++ syntax:
>>>     func((struct BigPods){.x=1.0, .count = 1});

AllanW@my-dejanews.com wrote:
>> Probably the biggest problem [[other than the initial shock -- this
>> is SOOOO different than what we have now]] is how to handle a call
>> with a mixture of positional and named arguments, especially in the
>> presence of default arguments.
>>     itoa(.base=16, 0, x);
>> Is x the buffer, and 0 the value?  Or vice-versa?
>>     itoa(10, 8, .buffer=x);
>> Argument 2 (.buffer) given twice?  Or do we handle all named
>> arguments first, and make a second pass for remainder?  Difficult.

James Kuyper wrote:
> ...
> Overload resolution is one issue that would make transferring this C
> innovation over to C++ trickier than I first thought.

This was discussed here some months ago.  Stroustrup discusses the
problems in 6.5.1 of his "Design and Evolution of C++".  Basically,
it's a good idea except for some conflicts with default arguments
and function overloading.  But the biggest problem is that the
committee didn't want function argument names to be part of the
unalterable interface for a function.  In other words, once you
choose a name for an argument, you are stuck with it; changing the
argument name breaks existing code.

There were those (myself included) who argued that the name of
the function is already cast in concrete as part of the interface;
you can't simply change function names, either.  So why not
allow fixed argument name(s), as well?  Alas, it was not to be.


-- David R. Tribble, dtribble@technologist.com --
-- C++, the PL/1 of the 90s.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <dtribble@technologist.com> wrote:
>
>This was discussed here some months ago.  Stroustrup discusses the
>problems in 6.5.1 of his "Design and Evolution of C++".  Basically,
>it's a good idea except for some conflicts with default arguments
>and function overloading.  ...   Alas, it was not to be.

In C++ (perhaps unlike in C) it's considered bad style to define
a function with so many arguments that somebody would want to name
them in a call.  For an example of such bad style, consider
std::basic_string<> members, and consider some of the ways it
have been done otherwise.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <Ew51qq.MKs@research.att.com>,
  ark@research.att.com (Andrew Koenig) wrote:
> In article <6og44i$65v$1@nnrp1.dejanews.com>,  <AllanW@my-dejanews.com>
wrote:
>
> > It would be a radical change for C++, but I would love it. I think
> > that
> >     itoa(.value=10, .buffer=buffer, .base=8);
> >     // (Not neccesarily this syntax)
> > is a lot easier to maintain than
> >     itoa(10, buffer, 8); // Is this "0000010" -- 7 digits plus null
> >                          //   terminator?
> >                          // Or is it "8" -- number 8 in base 10?
> >                          // Or is it "12" -- number 10 in base 8?
>
> Suppose the vendor of a C++ programming environment were to add an option
> to display information about the arguments when displaying a program,
> much as some environments already display keywords and comments in
> different colors?  Such an option would solve your maintainability problem,
> and would not require any change to the language at all.

I think that this would be a huge step forward, and I encourage it.
Microsoft Visual Basic already does this, although Visual C++ does
not.  (Ironically, these are now both considered a part of the
"Visual Studio", implying that they share components, and yet this
is not true at all -- the remaining differences between the two
programming environments are staggering.)

And yet, even this is not ideal.  I make minor changes in the Visual
C++ programming environment, but for bigger changes or new code, I
prefer a different debugger.  So personal is the nature of an editor
that I doubt that there will ever be one that completely satisfies
everyone.

Further, the road of easy-to-use programming is a very long one.
Even with parameter prompts available, I would still wish that
named parameters existed.

Imagine a function with 6 parameters, five with defaults.  Four of
these five defaults are adequate for your needs, but you wish to
change the value of the last parameter.  With current C++ rules, you
must specify all six values.  With named parameters, you would only
need to specify the non-default value and the last value, allowing
all others to use their defaults.

In practice, I think this would reduce the number of overloaded
member functions needed in robust classes.

> In general, I would like to encourage the programming community to think
> about the potential of tools that manipulate programs in ways that
> offer useful facilities to programmers without changing the language
> definition.  A stable language definition is important for communication,
> so by putting tools into the development environments, we improve both
> communication and maintainability.

The entire industry has a long way to go, not only in languages but
in tools and in programmer maturity.

But if you want to be shocked, look back to the tools you used 5-10
years ago.  Now extrapolate what improvements we may have 5-10 years
from now.  Exciting?  Fun!  This is a good time to be in this business.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35AC0B54.3104@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:
> This was discussed here some months ago.  Stroustrup discusses the
> problems in 6.5.1 of his "Design and Evolution of C++".  Basically,
> it's a good idea except for some conflicts with default arguments
> and function overloading.  But the biggest problem is that the
> committee didn't want function argument names to be part of the
> unalterable interface for a function.  In other words, once you
> choose a name for an argument, you are stuck with it; changing the
> argument name breaks existing code.
>
> There were those (myself included) who argued that the name of
> the function is already cast in concrete as part of the interface;
> you can't simply change function names, either.  So why not
> allow fixed argument name(s), as well?  Alas, it was not to be.

But there's an easy response to that objection.

    char *strcpy(char *dest, const char*source);

This prototype makes source and dest part of the function signature;
code could use these names, and once that happened it would be very
difficult to change the prototypes to use other argument names.
But the whole point of named arguments is to allow the callers to use
those names!  For arguments that should not have permanent names,
don't put them in the prototype:

    char *strcpy(char *, const char*);

Now the caller has no choice except to use positional arguments; on
the other hand, there are no names to break in future versions.
(This is how it works in the Microsoft header files right now.  Which
is annoying -- for library functions I don't call very often, I can't
use the header files to remind me which argument comes first.  I have
to fire up the on-line help system, which is big and slow...)



This reminds me: A few years ago, I used to use a compiler that
wouldn't accept a prototype like this:
    void abc(int first, int);
That compiler would accept the prototype with two named arguments,
or two unnamed arguments, but not one of each.  (They've probably
fixed it by now; I don't know.)  But there was never anything in
any draft of the standard to make the above declaration illegal
-- was there?

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

JHB NIJHOF wrote:
>
>   James Kuyper <kuyper@wizard.net> wrote:
> > Designated initializers use a brand new syntax, so they would take a bit
> > more work to add to the next version of C++. However, I don't believe
> > the new syntax would conflict with any existing C++ syntax:
> >
> >       func((struct BigPods){.x=1.0, .count = 1});
>
> 'keyword arguments' is exactly the example discussed in (Bjarne Stroustrup's)
> Design and Evolution of C++ as
> 'a proposed extension that is neat, but it is possible in C++ already'.

What C9X will mandate is related to structure members, not function
parameters. Examine my example more closely. I chose it because it shows
how to implement a substitute for keyword arguments in C9X using
compound literals and designated initializers. In retrospect I see that
it was a confusing example.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <dtribble@technologist.com> wrote:
>> This was discussed here some months ago.  Stroustrup discusses the
>> problems in 6.5.1 of his "Design and Evolution of C++".  Basically,
>> it's a good idea except for some conflicts with default arguments
>> and function overloading.  ...   Alas, it was not to be.

Nathan Myers wrote:
> In C++ (perhaps unlike in C) it's considered bad style to define
> a function with so many arguments that somebody would want to name
> them in a call.  For an example of such bad style, consider
> std::basic_string<> members, and consider some of the ways it
> have been done otherwise.

Yes, but how many is too many?  Quick, can you tell me which of
these calls is correct?:

    n = fread(fp, buf, 1, sizeof(buf));
    n = fread(buf, fp, 1, sizeof(buf));
    n = fread(buf, 1, sizeof(buf), fp);

I wouldn't have to look this up each and every single time I use
it if I had this instead:

    n = fread(_fp = fp, _buf = buf, _size = 1, _num = sizeof(buf);

And this is only four arguments.  It could be argued that any
more than two can be confusing.

Of course, the problem that allowing named function parameters
creates is that now ISO has to come up with standard argument
names for all of the standard library functions that are acceptable
to everyone.


-- David R. Tribble, dtribble@technologist.com --
-- C++, the PL/1 of the 90s.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6oi6iu$gom$1@whatsit.aston.ac.uk>,
  JHB NIJHOF <nijhojhb@aston.ac.uk> wrote:
>   James Kuyper <kuyper@wizard.net> wrote:
> > Designated initializers use a brand new syntax, so they would take a bit
> > more work to add to the next version of C++. However, I don't believe
> > the new syntax would conflict with any existing C++ syntax:
> >
> >  func((struct BigPods){.x=1.0, .count = 1});
>
> 'keyword arguments' is exactly the example discussed in (Bjarne Stroustrup's)
> Design and Evolution of C++ as
> 'a proposed extension that is neat, but it is possible in C++ already'.
> It's section 6.5.1.
> The idea is to use a helper class:
> class w_args {
> ...
> public:
>  w_args() // set defaults
>   wc(black), wx(0),...
>  w_args& color(color c) { wc = c; return *this;}
>  w_args& x(int x) { wx = x; return *this;}
> ...
> }
>
> and use it in a class window with constructors
> window() ; // default
> window(w_args wa); // set options from wa
>
> which can then be constructed as
> window w(w_args().color(green).x(5))
>
> (I remember having seen this bit online somewhere as well,
> but I can't remember where).

This is an intriguing idea.  I can see only two problems:

* It's extra work.  Eevery major function call that implements
  this mechanism must (in general) invent it's own argument
  class.  There may be several functions similar enough to
  share an argument class, but this won't always happen.  The
  argument class must have a name (they can't all be w_args!),
  which is probably similar to the function name -- but not
  identical...

* It may slow down the execution.  The argument class is
  constructed with default values for all arguments, and then
  one at a time the values are changed before the function is
  finally called.  For a non-trivial list of arguments (which
  is the only time I'd consider this), the overhead could be
  far greater than language-defined default arguments.

Still, the idea is one I have never used before, and it looks
like it can be very useful in certain situations.

I fact, I think I would go a step further, make the class BE
the function.  I'd implement the functionality in operator()
or maybe in the destructor.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> Of course, the problem that allowing named function parameters
> creates is that now ISO has to come up with standard argument
> names for all of the standard library functions that are acceptable
> to everyone.

Well, maybe. I came up with a decent solution once upon a time in
comp.std.c++: positional and named arguments are not compatible. I think
that's the way it works in Lisp. If you make the two distinct argument
types, then there's no conflict between the two. Positional parameters
have positional arguments, and named parameters always have the name on
the arguments. That is, given

    int foo(int p1, key1: int k1, int p2, key2: int k2, int p3);

then

    foo(key1: 1, key2: 2, 3, 4, 5);

binds p1 = 3, p2 = 4, p3 = 5, k1 = 1, and k2 = 2. Simply saying foo(1,
2, 3, 4, 5) would be illegal. No more ambiguity, and the keyword names
are not necessarily tied to the parameter names.

Of course, this works better in C++ where you could overload

    void * memcpy(void *, void const *, size_t); // with
    void * memcpy(dest: void *, src: void *, size: size_t);

Since C has no overloading, the solution is less desirable since it
couldn't apply to the standard library. A compromise could be that if no
arguments are named, then they apply to positional AND keyword arguments
in order, but that seems hackish to me.
--
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds

My reply address is correct as-is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35ACAB8E.41C6@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> AllanW@my-dejanews.com wrote:
> >
> > In article <35AB743C.167E@wizard.net>,
> >   James Kuyper <kuyper@wizard.net> wrote:
> > > AllanW@my-dejanews.com wrote:
> > > >
> > > > In article <35AA46DE.794B@wizard.net>,
> > > >   James Kuyper <kuyper@wizard.net> wrote:
> > > > > Designated initializers use a brand new syntax, so they would take a
bit
> > > > > more work to add to the next version of C++. However, I don't believe
> > > > > the new syntax would conflict with any existing C++ syntax:
> > > > >
> > > > >       func((struct BigPods){.x=1.0, .count = 1});
> >
> > [snip]
> > > > Probably the biggest problem [[other than the initial shock -- this is
> > > > SOOOO different than what we have now]] is how to handle a call with
> > > > a mixture of positional and named arguments, especially in the presence
> > > > of default arguments.
> > > >     itoa(.base=16, 0, x);
> > > > Is x the buffer, and 0 the value?  Or vice-versa?
> > > >     itoa(10, 8, .buffer=x);
> > > > Argument 2 (.buffer) given twice?  Or do we handle all named arguments
> > > > first, and make a second pass for remainder?  Difficult.
> > > >
> > > > In my opinion the best answer is to simply disallow it.  Either all
> > > > arguments are named, or all are positional.  Overload resolution could
> > > > get a bit tricky too, but I doubt it would be an impossible hurdle.
> > >
> > > The C9X standard has chosen a different option. Designators cause a skip
> > > to the specified member, and following initializers that have no
> > > designator will be assigned in order starting from there. Initialization
> > > of the same member multiple times is permitted; each ocurrance overrides
> > > the previous ones.
> >
> > An interesting solution.  Seems to me that the closest thing to a
> > precedent comes from enumerations, where the same value can be used
> > with multiple identifiers.
> >
> > I can see value in the rule that named designators cause the
> > arguments to "skip" to that one, especially when combined with
> > default arguments:
> >     void baz(int a1, int a2=0, int a3=0, int a4=0, int a5=0, int a6=0,
> >              int b1=0, int b2=0, int b3=0, int b4=0, int b5=0, int b6=0);
> >     /* ... */
> >     baz(1, 2, .b1=1, 2);
> >
>
> I'm sorry I didn't catch this earlier. You're mixing up the
> initialization of structure members with the assignment of arguments to
> function parameters. Those are two entirely different things. The
> confusion may have come from my providing an example of a function
> defined to take a structure as an argument.  As far as I know, the
> syntax you give above is not part of C9X, but the following rewrite is:
>
>  struct baz{
>   int a1, a2, a3, a4, a5, a6, b1, b2, b3, b4, b5, b6;
>  };
>  struct baz bz={1, 2, .b1=1, 2};

  Returning to the original topic of this sub-thread:  If and when C++ 'll
incorporate this C9X syntax, the obvious consequences are:  as for now C++
struct can mean or C struct (PODS - no constructors, no member functions etc)
or a full-blown class with access defaulted to public; the border between
them is rather blurred ( say, not only PODS structure can be initialized by
initializer list). Designated initializers syntax in C++, on the other side,
would be valid only for PODS structures (otherwise it'd be introducing
alternate constructor syntax for classes) - so suddenly the same keyword is
introducing two *really* different things with different associaded syntaxes.

        Regards,
                Alex Krol

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35AD0FBA.5D15@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:
> David R Tribble <dtribble@technologist.com> wrote:
> >> This was discussed here some months ago.  Stroustrup discusses the
> >> problems in 6.5.1 of his "Design and Evolution of C++".  Basically,
> >> it's a good idea except for some conflicts with default arguments
> >> and function overloading.  ...   Alas, it was not to be.
>
> Nathan Myers wrote:
> > In C++ (perhaps unlike in C) it's considered bad style to define
> > a function with so many arguments that somebody would want to name
> > them in a call.  For an example of such bad style, consider
> > std::basic_string<> members, and consider some of the ways it
> > have been done otherwise.
>
> Yes, but how many is too many?  Quick, can you tell me which of
> these calls is correct?:
>
>     n = fread(fp, buf, 1, sizeof(buf));
>     n = fread(buf, fp, 1, sizeof(buf));
>     n = fread(buf, 1, sizeof(buf), fp);
>
> I wouldn't have to look this up each and every single time I use
> it if I had this instead:
>
>     n = fread(_fp = fp, _buf = buf, _size = 1, _num = sizeof(buf);
>
> And this is only four arguments.  It could be argued that any
> more than two can be confusing.
>
> Of course, the problem that allowing named function parameters
> creates is that now ISO has to come up with standard argument
> names for all of the standard library functions that are acceptable
> to everyone.
>

If you did not remember the order of arguments, it is unlikely that
you will remember the argument names. Beside that, a C++ designer
would have designed the order of args. in the following way:

    size_t istream::read(char* buf, size_t max_len)

and void read(istream& ist, string* s);

BTW, I still find a lot of uses for char array (beside string class). I
wish that istrstream was not deprecated, because I may want to use
stream functionality to parse a character buffer and I do not want to
create a new string or copy from char buffer to the string.

- Saroj Mahapatra

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers wrote:
>
> David R Tribble <dtribble@technologist.com> wrote:
> >
> >This was discussed here some months ago.  Stroustrup discusses the
> >problems in 6.5.1 of his "Design and Evolution of C++".  Basically,
> >it's a good idea except for some conflicts with default arguments
> >and function overloading.  ...   Alas, it was not to be.
>
> In C++ (perhaps unlike in C) it's considered bad style to define
> a function with so many arguments that somebody would want to name
> them in a call.  For an example of such bad style, consider
> std::basic_string<> members, and consider some of the ways it
> have been done otherwise.

Locales might be a better example. A quick run through the basic_string
template and the various locale templates gives the following argument
counts (counting all default arguments, counting template member
functions as a single function, counting only public members):

# args     basic_string       locale
-------     ------------       ----------
0  22   21
1  19   21
2  34   16
3  24    6
4   8   10
5   2   13
6  --    4
7  --    2

If you look at percentages, the data breaks down like this:

# args     basic_string       locale
-------     ------------       ----------
0  20%   23%
1  17%   23%
2  31%   17%
3  22%    6%
4   7%   11%
5   2%   14%
6  --    4%
7  --    2%

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35AD0FBA.5D15@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:
> Of course, the problem that allowing named function parameters
> creates is that now ISO has to come up with standard argument
> names for all of the standard library functions that are acceptable
> to everyone.

Not neccesarily, although I hope that they would do so for some of
the functions (such as fread).  But atoi(), for instance, would not
require a parameter name -- indeed, parameter names would probably
not be useful for any standard library function that takes only one
argument.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
...
> Probably the biggest problem [[other than the initial shock -- this is
> SOOOO different than what we have now]] is how to handle a call with
> a mixture of positional and named arguments....
...
> In my opinion the best answer is to simply disallow it.  Either all
> arguments are named, or all are positional.
...

What Fortran-90 does is to require all named args to come after all
positional args in the call.  So (in C):

int func( int i, int j, int k );
...
larg = func( iarg, .k=karg, .j=jarg ); /* OK */
larg = func( iarg, jarg, karg ); /* OK */
larg = func( .i=iarg, j, k ); /* not OK */

This would work well in C, or so it Cms to me.

 -P.

--
************ "Yeah, but poverty can't buy happiness, either."
*************
* Peter S. Shenkin; Chemistry, Columbia U.; 3000 Broadway, Mail Code
3153 *
** NY, NY  10027;  shenkin@columbia.edu;  (212)854-5143;  FAX: 678-9039
***
*MacroModel WWW page:
http://www.columbia.edu/cu/chemistry/mmod/mmod.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrew Koenig wrote:
>
> Suppose the vendor of a C++ programming environment were to add an
> option to display information about the arguments when displaying a
> program, much as some environments already display keywords and
> comments in different colors?  Such an option would solve your
> maintainability problem, and would not require any change to the
> language at all.
>
> In general, I would like to encourage the programming community to
> think about the potential of tools that manipulate programs in ways
> that offer useful facilities to programmers without changing the
> language definition.  A stable language definition is important for
> communication, so by putting tools into the development environments,
> we improve both communication and maintainability.

But there are two situations when help remembering parameter orders is
needed: when writing the code and when reading the code. The above
solution is only partial because reading the code is often done
off-line, without access to such tools. For instance, source code is
often printed out, and fragments of source code are often included in
books and printed documentation.

There is no easy way, short of cluttering every function argument with
/*name*/ comments, to embed the names of parameters in existing C/C++
source. And inserting such comments automatically would be undesireable
because many functions don't need such commenting. (E.g., pow(x, y)).

--

Ciao,
Paul


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,
You may wish to read sections 6.5.1 and 6.5.1.2 in "The Design and
Evolution of C++" by B. Stroustrup for a discussion of why keyword
arguments were considered and rejected.  Alternative methods are briefly
discussed.
LR.
AllanW@my-dejanews.com wrote:
>
> In article <Ew51qq.MKs@research.att.com>,
>   ark@research.att.com (Andrew Koenig) wrote:
> > In article <6og44i$65v$1@nnrp1.dejanews.com>,  <AllanW@my-dejanews.com>
> wrote:
> >
> > > It would be a radical change for C++, but I would love it. I think
> > > that
> > >     itoa(.value=10, .buffer=buffer, .base=8);
> > >     // (Not neccesarily this syntax)
> > > is a lot easier to maintain than
> > >     itoa(10, buffer, 8); // Is this "0000010" -- 7 digits plus null
> > >                          //   terminator?
> > >                          // Or is it "8" -- number 8 in base 10?
> > >                          // Or is it "12" -- number 10 in base 8?
> >
> > Suppose the vendor of a C++ programming environment were to add an option
> > to display information about the arguments when displaying a program,
> > much as some environments already display keywords and comments in
> > different colors?  Such an option would solve your maintainability problem,
> > and would not require any change to the language at all.
>
> I think that this would be a huge step forward, and I encourage it.
> Microsoft Visual Basic already does this, although Visual C++ does
> not.  (Ironically, these are now both considered a part of the
> "Visual Studio", implying that they share components, and yet this
> is not true at all -- the remaining differences between the two
> programming environments are staggering.)
>
> And yet, even this is not ideal.  I make minor changes in the Visual
> C++ programming environment, but for bigger changes or new code, I
> prefer a different debugger.  So personal is the nature of an editor
> that I doubt that there will ever be one that completely satisfies
> everyone.
>
> Further, the road of easy-to-use programming is a very long one.
> Even with parameter prompts available, I would still wish that
> named parameters existed.
>
> Imagine a function with 6 parameters, five with defaults.  Four of
> these five defaults are adequate for your needs, but you wish to
> change the value of the last parameter.  With current C++ rules, you
> must specify all six values.  With named parameters, you would only
> need to specify the non-default value and the last value, allowing
> all others to use their defaults.
>
> In practice, I think this would reduce the number of overloaded
> member functions needed in robust classes.

[ mod note: excessive quoting removed. -sdc ]


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Alex_Krol@scitex.com wrote:
>
> In article <35A860A1.B4955AF6@null.net>,
>   "Douglas A. Gwyn" <DAGwyn@null.net> wrote:
> > Alex_Krol@scitex.com wrote:
> > >   So, in C9X we'll have some sort of constructors for structs and unions,
> > > only with syntax different from that of C++ ? Why the difference, then?
> >
> > I was unaware that PODS *had* constructors in C++.
>
>    Of course, not - by definition.
>   Let me rephrase my question - is it a deliberate Comittee's policy
> to divorce from C++ ? For it seems that this syntax makes it nearly impossible
> to incorporate these C9X features into any future C++ standard
> (Well, just imagine what it'd be like -
>    nonPodsType(1,1) vs (struct PodsType){1,1} etc).

The C++ constructor call is something that could not be easily
incorporated into C. It adds all kinds of parsing ambiguities that C
could otherwise completely ignore. However, going the other way needn't
be difficult. C9x compound listerals shouldn't be difficult to add to
the next revision of C++. They're really only an extension to the syntax
already used to write an POD struct initialization in either language. I
can't think of any existing feature of C++ that they could be confused
with:

 {
  struct PodsType temp={1,1};
  func(temp);
 }

gets replaced by

 func((struct PodsType){1,1});

> (Not that I'm against this separation, BTW)
>
> >
> > Designated initializers (and compound literals) originated in the

Designated initializers use a brand new syntax, so they would take a bit
more work to add to the next version of C++. However, I don't believe
the new syntax would conflict with any existing C++ syntax:

 func((struct BigPods){.x=1.0, .count = 1});

> > 8th Edition UNIX C compiler, so there has been longstanding
> > existing practice.  These were included in the Technical Report
> > issued by the Numerical C Extensions Group years ago.  If C++
> > invented something different, I'd say that you should ask *them*
> > for justification for the deviation.
>
>    Seems that distancing from C++ *is* deliberate, after all.

C++ didn't choose something different, it just choose not to implement
those extensions at all.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35AA46DE.794B@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> Designated initializers use a brand new syntax, so they would take a bit
> more work to add to the next version of C++. However, I don't believe
> the new syntax would conflict with any existing C++ syntax:
>
>  func((struct BigPods){.x=1.0, .count = 1});

I've worked with two language that supported named parameters.
Ironically, both were among the few languages considered "lower-level"
than C: one was the PDP-11 Macro assembly language, and one was the
VAX Macro assembly language.  In each case, they had provisions for
allowing arguments to be either named or positional, and supplied
rules for how to disambiguate when both were used in the same call.

It would be a radical change for C++, but I would love it. I think that
itoa(.value=10, .buffer=buffer, .base=8); // Not neccesarily this syntax is a
lot easier to maintain than  itoa(10, buffer, 8); // Is this "0000010" -- 7
digits plus null terminator?  // Or is it "8" -- number 8 in base 10?  // Or
is it "12" -- number 12 in base 8?

Probably the biggest problem [[other than the initial shock -- this is
SOOOO different than what we have now]] is how to handle a call with
a mixture of positional and named arguments, especially in the presence
of default arguments.
    itoa(.base=16, 0, x);
Is x the buffer, and 0 the value?  Or vice-versa?
    itoa(10, 8, .buffer=x);
Argument 2 (.buffer) given twice?  Or do we handle all named arguments
first, and make a second pass for remainder?  Difficult.

In my opinion the best answer is to simply disallow it.  Either all
arguments are named, or all are positional.  Overload resolution could
get a bit tricky too, but I doubt it would be an impossible hurdle.

Something for the next C++ standard, in (I'm guessing) circa 2002?

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>
> In article <35AA46DE.794B@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> > Designated initializers use a brand new syntax, so they would take a bit
> > more work to add to the next version of C++. However, I don't believe
> > the new syntax would conflict with any existing C++ syntax:
> >
> >       func((struct BigPods){.x=1.0, .count = 1});
>
> I've worked with two language that supported named parameters.
> Ironically, both were among the few languages considered "lower-level"
> than C: one was the PDP-11 Macro assembly language, and one was the
> VAX Macro assembly language.  In each case, they had provisions for
> allowing arguments to be either named or positional, and supplied
> rules for how to disambiguate when both were used in the same call.
>
> It would be a radical change for C++, but I would love it. I think that
> itoa(.value=10, .buffer=buffer, .base=8); // Not neccesarily this syntax is a
> lot easier to maintain than  itoa(10, buffer, 8); // Is this "0000010" -- 7
> digits plus null terminator?  // Or is it "8" -- number 8 in base 10?  // Or
> is it "12" -- number 12 in base 8?
>
> Probably the biggest problem [[other than the initial shock -- this is
> SOOOO different than what we have now]] is how to handle a call with
> a mixture of positional and named arguments, especially in the presence
> of default arguments.
>     itoa(.base=16, 0, x);
> Is x the buffer, and 0 the value?  Or vice-versa?
>     itoa(10, 8, .buffer=x);
> Argument 2 (.buffer) given twice?  Or do we handle all named arguments
> first, and make a second pass for remainder?  Difficult.
>
> In my opinion the best answer is to simply disallow it.  Either all
> arguments are named, or all are positional.  Overload resolution could
> get a bit tricky too, but I doubt it would be an impossible hurdle.

The C9X standard has chosen a different option. Designators cause a skip
to the specified member, and following initializers that have no
designator will be assigned in order starting from there. Initialization
of the same member multiple times is permitted; each ocurrance overrides
the previous ones.
Overload resolution is one issue that would make transferring this C
innovation over to C++ trickier than I first thought.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]