In article 6A77@lonnds.ml.com, Julian Pardoe <pardoej@lonnds.ml.com> writes:
>
>The problem is that up to now it has been quite legal to have
>    void Copy (Point from, Point to);
>in one header and
>    void Copy (Point src, Point dst);
>in another.  The argument names can also vary between function declaration
>and function definition (itself a declaration).

Yes, and changing that rule would break a lot of existing code. For
example, it is common (and in my view a good coding practice) to
use long parameter names in function prototypes for documentation
purposes. Coding the actual function with long names is tedious,
and so programmers like to use short names in the implementation of
the function.

>I don't understand this argument at all.  Are identifiers longer than
>6 characters "decorative scrollwork"?  When I'm reading a new piece of
>code I can't be expected to have an encyclopaedic knowledge of the entire
>system and I certainly don't want to go away and read the definition of
>every function that the code I'm looking at calls.  Keyed arguments are
>a handy piece of self-documentation just like meaningful function-names.
> ...
>Keyed arguments also allow a more flexible form of argument defaulting.
>This too can be extremely useful when a function takes a large number
>of arguments.

Keyed arguments are used to good effect in some languages. The C++
Committee evaluated three such proposals at different times, and
rejected all of them. The reason you gave above was one reason.
Another is that the interaction with function overloading causes
too many ambiguities. However nice keyed arguments might be in theory,
they just don't fit with the rest of C++.

Addressing the last point, C++ provides mechanisms that make long
parameter lists unnecessary. Object-oriented programming, for example,
tends to result in programs with small functions having few parameters.

Even the classic example of something like a Window class that needs lots
of parameters for its constructor can be dealt with in other ways.
For example, instead of this

class Window {
public:
 Window(int width, int height, Color foreground,
  Color background, FontType font, FontSize fsize
  ... etc );
};

You can do this:
 Window(int width, int height); // sets all defaults

 Window& Foreground(Color);
 Window& Background(Color);
 Window& Font(FontType);
 Window& Fsize(FontSize);
 ... etc

Then you can create and initialize a Window like this:

 Window w(200, 100);
 w.Foreground(Red).Background(White).Font(Palatino).Fsize(10);

Notice the syntax look a lot like it would with keyed parameters, but the
result is more flexible, easier to implement, and easier to use.

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

clamage@taumet.eng.sun.com (Steve Clamage) wrote:
>Even the classic example of something like a Window class that needs lots
>of parameters for its constructor can be dealt with in other ways.
>For example, instead of this
> Window(int width, int height, Color foreground,
>  Color background, FontType font, FontSize fsize
>  ... etc );
>Then you can create and initialize a Window like this:
> Window w(200, 100);
> w.Foreground(Red).Background(White).Font(Palatino).Fsize(10);
>Notice the syntax look a lot like it would with keyed parameters, but the
>result is more flexible, easier to implement, and easier to use.

Not necessarily.  After all, you've taken parameters out of the
constructor that are needed for full construction.  There's no
syntactical way to make it obvious which functions are needed to fully
construct the object.  If you have reasonable defaults, this isn't a
problem, but if you don't, there's a significant opportunity for
problems.  And, in your example above, when does the Window actually
get created?  You've got to add yet another function to say that
you're truly ready for the real construction to happen.

Andrew Bell
abell@mindspring.com



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Andrew C Bell writes:
> clamage@taumet.eng.sun.com (Steve Clamage) wrote:

>> Even the classic example of something like a Window class that needs lots
>> of parameters for its constructor can be dealt with in other ways.
>> For example, instead of this
>> Window(int width, int height, Color foreground,
>> Color background, FontType font, FontSize fsize
>> ... etc );
>> Then you can create and initialize a Window like this:
>> Window w(200, 100);
>> w.Foreground(Red).Background(White).Font(Palatino).Fsize(10);

> Not necessarily.  After all, you've taken parameters out of the
> constructor that are needed for full construction.

For a constructor that actually needs all these arguments, you could
have a nested Argument class (or struct) that is the sole argument to
the constructor.  Then the previous example looks like this:

Window w(Window::Arg().Width(200).Height(100).Foreground(Red)
                      .Background(White).Font(Palatino).Fsize(10));

>> Notice the syntax look a lot like it would with keyed parameters, but the
>> result is more flexible, easier to implement, and easier to use.

Even better than Mr. Clamage's pattern, this would also allow a general
Argument declared that could initialize many different Windows.

> There's no syntactical way to make it obvious which functions are
> needed to fully construct the object.  If you have reasonable
> defaults, this isn't a problem, but if you don't, there's a
> significant opportunity for problems.

This problem goes away with an Argument object.  If the Argument is not
fully specified, then the constructor (or function) can throw an
exception saying so.

Of course, I didn't invent this pattern myself; I got the basics from D&E.

--
Colin Rafferty
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]