Hyman Rosen wrote in message ...
>This is suitable for an object that has many different settings.
>For example, in a graphical drawing system, a pen object can have
>color, font, line thickness, join styles, masks, and many other
>settings. Windows have a similar variety of properties. In some
>cases, one creates a default object and then sets its properties
>one-by-one, but that is not suitable when creation of the object
>affects the environment.

If I remember correctly (it was a while ago now), the Amiga OS used
a initialisation object technique for creating new complex objects like
windows and buttons. Something like this:

    struct NewWindow nw;
    struct Window* w;
    nw.Left = 100;
    nw.Top = 100;
    nw.Width = 400;
    nw.Font = myfont;
    // etc...

    w = CreateWindow(&nw);

It makes the code a bit clumsy, but I remember finding it very easy -
once you learn all the setting names, you don'r need to refer to the
manual each time you create a window.

--
Neil

---
[ 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                             ]

Neil Gall wrote:
> If I remember correctly (it was a while ago now), the Amiga OS used
> a initialisation object technique for creating new complex objects like
> windows and buttons. Something like this:
>
>     struct NewWindow nw;
>     struct Window* w;
>     nw.Left = 100;
>     nw.Top = 100;
>     nw.Width = 400;
>     nw.Font = myfont;
>     // etc...
>
>     w = CreateWindow(&nw);
>
> It makes the code a bit clumsy, but I remember finding it very easy -
> once you learn all the setting names, you don'r need to refer to the
> manual each time you create a window.

I'd have to dig out the documentation for the details, but the Amiga OS
used a device called the tag list. It made extensive use of varadic
function calls. Since I don't have the document handy, I'll do this
from memory with an assurance that I've got some of the details wrong.

    struct Window * w = NULL;
    CreateWindowFromTag( &w, NW_LEFT, 100, NW_TOP, 100, NW_WIDTH, 400,
        NW_FONT, myfont, TAG_END);

There was a well formalized set of routines that would take a definition
array and use the tags to fill in the appropriate fields in the data
structure.

A lot of effort went into the design of this capability and a fair body
of practice exists, but it belongs in the C standard, not the C++
standard because of its nature.

mtew@cds.duke.edu
---
[ 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                             ]

Per Erik Stendahl (berrs@cyberdude.comyouknowwhat) wrote:

: This is obvious. But what if you're scanning through somebody else's
: code, or even you'r own (after a week)?

You're assuming that the same developer that would neglect to document the
meaning and proper usage of parameters would bother to give parameters
meaningful names.  My experience indicates that this sort of developer
never bothers with such details regardless of how easy they are to use.
The fact is, you -still- have to refer to the declarations or
documentation to know what to name the arguments.  In those cases where
the argument names are obvious, you will find the argument order is also
obvious.  It all seems like a lot of bother to use what amounts to a
leading default argument.
---
[ 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                             ]

Hyman Rosen (uunet!jyacc!hymie@ncar.UCAR.EDU) wrote:

: Here's an example - say you have a function which wants three parameters:

:  enum colors { RED, GREEN, BLUE };
:  enum shapes { SQUARE, ROUND, POINTY };
:  enum textures { SLICK, FUZZY, TACKY };

:  void build_chair(colors color = BLUE,
:     shapes shape = POINTY,
:     textures texture = FUZZY);

: Create a class:

  [auhor's class declaration elided]

:  void build_chair(const chair_parms &cp)
:  {
:   return build_chair(cp.color(), cp.shape(), cp.texture());
:  }

I experimented with this type of named-parameter mechanism (holy cow, can
it already have been as long as) five years ago and never once considered
doing it again.  As you say, this can be done, but I'm hard-pressed to
even imagine a situation where it's necessary.  The situation this
arrangement benefits is one where a function is called with many arguments
of indistinct types AND the programmer calling the function is (let's face
it, inexcusably) unaware of the meaning of each positional parameter.
There are a number of other remedies for this:

For the caller:

  - read the documentation
  - look at the declaration

For the developer:

  - code fewer parameters.  This possibly means more, smaller member
    functions.
  - code smaller classes.  Classes with any member variables lead to fatter
    parameter lists.
---
[ 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                             ]

jodle wrote:
>
> Hyman Rosen (uunet!jyacc!hymie@ncar.UCAR.EDU) wrote:

[snip]

> I experimented with this type of named-parameter mechanism (holy cow, can
> it already have been as long as) five years ago and never once considered
> doing it again.  As you say, this can be done, but I'm hard-pressed to
> even imagine a situation where it's necessary.  The situation this
> arrangement benefits is one where a function is called with many arguments
> of indistinct types AND the programmer calling the function is (let's face
> it, inexcusably) unaware of the meaning of each positional parameter.

What I had in mind was using keyword arguments together with default
arguments. Take, for instance, a raytracer in which you have a Sphere class.
When you create a sphere you specify a lot of parameters like position,
orientation, color, transparency, textures, bumpmaps, material, etc. All of
these values do not change during the lifetime of the sphere so I would like
to have all those memberobjects const. That would be 1) self-documenting
(doesn't change after construction) and 2) bug-preventing (oops typo!
fortunately the compiler caught that!). Unfortunately all const member
objects have to be initialized in the constructor which means that the
constructorcall must have parameters for all of them. But it could be a real
pain-in-the-behind to have to explicitly initialize all of those parameters
if many of them have not-often-overridden default values.

A problem with C++ is that I cannot do this:

void f(int a = 0, int b = 0);
f(, 34);  // call f(0, 34)

I can do:
f(23); // call f(23, 0)
or
f(23, 34); // call f(23, 34)

So with keyword arguments + default arguments I would have "options"
when calling functions.

If I may give a silly example, consider calling "flex" (the Unix command)
and having to explicitly specify each option:
% flex yes no big no no no no no yes no yes yes no no no ... myfile.l

:-)

> There are a number of other remedies for this:
>
> For the caller:
>
>   - read the documentation
>   - look at the declaration

This is obvious. But what if you're scanning through somebody else's
code, or even you'r own (after a week)?

Keyword arguments provides clues at the calling point. Keyword arguments
also clutters the code, of course. I don't have any experience with
code using keywords arguments myself so I don't know much about the
drawbacks.

> For the developer:
>
>   - code fewer parameters.  This possibly means more, smaller member
>     functions.

This is also good advice.

Regards
Per Erik Stendahl,
Swedish Institute of Computer Science
---
[ 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                             ]

jodle@bix.com (jodle) writes:
> I experimented with this type of named-parameter mechanism (holy cow, can
> it already have been as long as) five years ago and never once considered
> doing it again.  As you say, this can be done, but I'm hard-pressed to
> even imagine a situation where it's necessary.

This is suitable for an object that has many different settings.
For example, in a graphical drawing system, a pen object can have
color, font, line thickness, join styles, masks, and many other
settings. Windows have a similar variety of properties. In some
cases, one creates a default object and then sets its properties
one-by-one, but that is not suitable when creation of the object
affects the environment.
---
[ 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                             ]

P Murray wrote:
>
> Now that the standard is basically a done deal,
> have there been any suggestions on how C++
> should evolve in the future and what things
> should be added to any future standard C++?

I do not know if someone already has mentioned this, and
I am sure that it must have been discussed in the past.

Sometimes I really miss "named parameters" (I am not
sure of the correct name for this feature).

What I mean is this:

// Declare CreateSphere()
Sphere *
CreateSphere(Vector center, double radius, Color color);

// Use CreateSphere()
sphere = CreateSphere(center = Vector(1.0, 1.0, 1.0),
                      color = Color::white, radius = 3.0);


I think this would be very nice to have. It also simplifies
the use of default parameters since you can give default
values for all the parameters and just specify those
that you wish to override.

What do you think?

Regards
Per Erik Stendahl,
Swedish Institute of Computer Science.
---
[ 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                             ]

Per Erik Stendahl wrote:

> I do not know if someone already has mentioned this, and
> I am sure that it must have been discussed in the past.
>
> Sometimes I really miss "named parameters" (I am not
> sure of the correct name for this feature).
>
>
> What do you think?
>
> Regards
> Per Erik Stendahl,
> Swedish Institute of Computer Science.



Roland Hartinger has already mentioned this in the past. The correct name is
'Keyword arguments'.
His proposal was close to technical perfect. But "the extensions group reached a
consensus that the proposal was close to redundant, would cause compatiblitiy
problems with existing C++ code, and would encourage programming styles that ought

not to be encouraged." as you can read in Bjarne Stroustrups book "The Design and
Evolution of C++" (1985). He explains the reasons in detail starting page 153 to
page 156.
However, I agree with you that including this would be very nice.

Tobias
---
[ 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                             ]

In article <3469DFF3.DC97F246@informatik.tu-chemnitz.de>, Tobias Neubert
<Tobias.Neubert@Informatik.TU-Chemnitz.DE> wrote:

> Roland Hartinger has already mentioned this in the past. The correct
> name is 'Keyword arguments'.  His proposal was close to technical
> perfect. But "the extensions group reached a consensus that the
> proposal was close to redundant, would cause compatiblitiy problems
> with existing C++ code, and would encourage programming styles that
> ought not to be encouraged." as you can read in Bjarne Stroustrups book
> "The Design and Evolution of C++" (1985). He explains the reasons in
> detail starting page 153 to page 156.  However, I agree with you that
> including this would be very nice.

Indeed it would be a good addition.

Stroustrups' reasons are good before the standard is finalized, but if we
think about "Where next for C++" Keyword arguments should be reconsidered.

As Stendahl showed in his CreateSphere example, with Keyword arguments you
do not have to call the function with the argument in the same order as in
the definition!

I would further suggest that default arguments can be anywhere on the
agrumets list not just the last ones:

// Declare CreateSphere()
Sphere * CreateSphere(Vector center = Vector(0.0, 0.0, 0.0), double radius
= 1.0, Color color = Color::white);

// Use CreateSphere()
sphere = CreateSphere(center = Vector(1.0, 1.0, 1.0),
                      color = Color::white, radius = 3.0);

OR

sphere = CreateSphere(color = Color::black, radius = 3.0);

OR

sphere = CreateSphere(radius = 17.0);

--
Shai Spharim
Software Engineer

ksWaves Ltd.
23, Kalisher St.
Tel-Aviv
Israel 65165

Email: shai@kswaves.com
Home page: http://www.waves.com
Phone +972-35107667
Fax +972-35105881
___________________________________________
Computers are useless. They can only give you answers.
- Pablo Picasso.
---
[ 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                             ]

In article <3469B1B5.6152@cyberdude.comyouknowwhat>, Per Erik Stendahl
<berrs@cyberdude.comyouknowwhat> wrote:

[...]

>I do not know if someone already has mentioned this, and
>I am sure that it must have been discussed in the past.
>
>Sometimes I really miss "named parameters" (I am not
>sure of the correct name for this feature).

[...]

>I think this would be very nice to have. It also simplifies
>the use of default parameters since you can give default
>values for all the parameters and just specify those
>that you wish to override.
>
>What do you think?

   As Tobias said, it's been done.  However, extending of your comment
about overriding only the arguments you want to and leaving the others
unchanged, I would think that it'd be nice to be able to use the 'default'
keyword in a function call.  For example:

void DrawCircle(float x=0.0, float y=0.0, float radius=1.0, bool filled=false);

   DrawCircle(default,12,3.5,default);

Just a thought.

B.B.       --I am not a goat!
---
[ 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                             ]

Bryant Brandon wrote:
>
[snip]
> ...I would think that it'd be nice to be able to use the 'default'
> keyword in a function call.  For example:
>
> void DrawCircle(float x=0.0, float y=0.0, float radius=1.0, bool filled=false);
>
>    DrawCircle(default,12,3.5,default);

[snip]

/*
 I wouldn't necessarily recommend this in practice, but...

 If you don't mind manual tedium, you can do the following.
 Note that this scheme gets exponentially harder as the
 number of default parameters increases.
*/

void DrawCircle(float x=0.0, float y=0.0,
                float radius=1.0, bool filled=false)
{
        // ...
}

class Default {};

// One default parameter variants...

void DrawCircle(const Default& dummy = Default(), float y=0.0,
           float radius=1.0, bool filled=false)
{
        DrawCircle (0.0, y, radius, filled);
}

// others...

// Two default parameter variants...

void DrawCircle(const Default& dummy1 = Default(),
           const Default& dummy2 = Default(),
           float radius=1.0, bool filled=false)
{
        DrawCircle (0.0, 0.0, radius, filled);
}

// others...

// Example client code

void foobar ()
{
        DrawCircle(Default(), Default(), 3.5, true);
}

--
:  Allan Clarke         : "All that is necessary for evil to abound is for  :
: clarke_nospam@ses.com :       good men to do nothing" -Edmond Burke       :
:    SES, Inc           :            http://www.ses.com/~clarke             :
: Austin, Texas         :           512/328-5544 512/327-6646(fax)          :
---
[ 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                             ]

Shai Spharim wrote:
>
> I would further suggest that default arguments can be anywhere on the
> agrumets list not just the last ones:

I disagree. I've once used a compiler that allowed this, and had in a
class library *long* parameter lists, many of which had default values,
and which their manual suggested coding like this:

  ugly.worse(4,,,,,5,,2);

What you get to is a counting-the-comma's contest, and that's not by any
means where I like to spend my time.
   _
/Bjorn.
--
Bjorn Fahller                  Tel: +46 8 4220898 /
NA/EBC/DN/NT                   -------------------
Ericsson Business Networks AB / A polar bear is a rectangular
S-131 89 Stockholm/SWEDEN    /  bear after a coordinate transform
---
[ 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                             ]

Bjorn Fahller wrote:
>
> Shai Spharim wrote:
> >
> > I would further suggest that default arguments can be anywhere on the
> > agrumets list not just the last ones:
>
> I disagree. I've once used a compiler that allowed this, and had in a
> class library *long* parameter lists, many of which had default values,
> and which their manual suggested coding like this:
>
>   ugly.worse(4,,,,,5,,2);
>
> What you get to is a counting-the-comma's contest, and that's not by any
> means where I like to spend my time.

The point is that keyword arguments _eliminate_ the need to count commas in
this case. In fact, they eliminate the need to remember the order of parameters
in general. The order has nothing to do with the meaning, so requiring that you
remember the order is to confront you with unnecessary implementation details.
Why should it matter semantically whether I write:

 read(buffer: buf, length: n, actual: a);

or

 read(actual: a, buffer: buf, length: n);

The meaning is the same, and the compiler should sort out the implementation
details.

I like the idea of keyword parameters, although I'm not sure how one would
define what happens when some parameters are specified by keyword and others
are not.

--

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         ]
[ 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                             ]

Per Erik Stendahl wrote:
>
> P Murray wrote:
> >
> > Now that the standard is basically a done deal,
> > have there been any suggestions on how C++
> > should evolve in the future and what things
> > should be added to any future standard C++?
>
> I do not know if someone already has mentioned this, and
> I am sure that it must have been discussed in the past.
>
> Sometimes I really miss "named parameters" (I am not
> sure of the correct name for this feature).
>
> What I mean is this:
>
> // Declare CreateSphere()
> Sphere *
> CreateSphere(Vector center, double radius, Color color);
>
> // Use CreateSphere()
> sphere = CreateSphere(center = Vector(1.0, 1.0, 1.0),
>                       color = Color::white, radius = 3.0);
>
> I think this would be very nice to have. It also simplifies
> the use of default parameters since you can give default
> values for all the parameters and just specify those
> that you wish to override.
>
> What do you think?

I prefer the ability to have explicit names, which then are part
of the function signature:

void copy(double from: f, double& to: t);

double a;
copy(from: M_PI, to: a); ok
copy(to: a, from: M_PI); ok, too
copy(M_PI, a); error: no function copy(double, double&) defined

This was brought up in comp.std.c++ by Bradd W. Szonye under the
subject "More on argument keywords" (Message-ID
<9611080526.AA12532@dwrsun4>,
Nov. 9,1996) and by me in the thread "PROPOSAL: More flexible
initializer syntax." (Message-ID
<329DEB20.4979F382@physik.tu-muenchen.de>,
Nov. 29, 1996). You can use DejaNews to get those articles.

The advantage of this is that it doesn't break any old program
(additional, previously illegal syntax for names; "normal"
declarations have unchanged semantics), and allows overloading
in names.

For example:

class complex
{
public:
  complex(double re, double im=0); // old style
  complex(double Re: re=0, double Im: im=0); // *different* function
  complex(double Abs: abs, double Arg: arg=0); // define by abs/arg
// ...
};

complex c1;  // 0
   // default constructor from comlex(double Re: =0, double Im: =0)

complex c2(5); // 5
   // complex(double, double=0)

complex c3(1,2); // 1+2i
   // complex(double, double=0)

complex c4(Re: 4); // 4
   // complex(double Re: =0, double Im: =0)

complex c5(Im: 3); // 3i
   // complex(double Re: =0, double Im: =0)

complex c6(Abs: 3, Arg: M_PI/5); // 3 e^(i M_PI/5)
  // complex(double Abs:, double Arg: =0)
---
[ 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                             ]

In article <346bff0c.1276854@engnews1.eng>, someone calling themselves stephen.clamage_nospam@eng.sun.com (Steve Clamage) wrote:
>On 13 Nov 97 11:33:23 GMT, shai@kswaves.com (Shai Spharim) wrote:

>Named arguments are a fine language feature in some languages, but
>just don't fit into C++. You might find some old articles by me on the
>subject in comp.std.c++ by checking Deja News. If not, I might be able
>to dredge them up and post them again.

I guess for anyone who really wants to implement them, you could sort
of kludge it by doing this:

typedef int MyIntegerType;
typedef int MyOtherIntType;

void MyFunc(MyIntegerType i, MyOtherIntType j = 0) { /* do something
*/ }

void MyFunc(MyOtherIntType j, MyIntegerType i = 0) { MyFunc(i, j); }

then call MyFunc like this:

MyFunc( MyIntegerType(3), MyOtherIntType(1) );

..

Giving the parameter types descriptive names would almost be the same
as having named parameters...

Just a thought...

|~\  /~| /~~| |~|    _______________________________________________
|  \/  |/ / |_| |__  The .sig wears a ring of polymorph! --More--
|      ' /| |_| | /  The .login hits! The .cshrc bites!
| |\/|  /\  | |  /   -----------------------------------------------
| |  |_/  \_| | /    "Say . . . That's a nice bike!" -- The T1000
=\|===========|/==========- The Mabster:  mhamilton@bunge.com.au -==
---
[ 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                             ]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
> I like the idea of keyword parameters, although I'm not sure how one would
> define what happens when some parameters are specified by keyword and others
> are not.

A way of doing this in standard C++ is to create a parameter class
which initializes itself to the proper default values, and has member
functions which correspond to the parameters.

Here's an example - say you have a function which wants three parameters:

 enum colors { RED, GREEN, BLUE };
 enum shapes { SQUARE, ROUND, POINTY };
 enum textures { SLICK, FUZZY, TACKY };

 void build_chair(colors color = BLUE,
    shapes shape = POINTY,
    textures texture = FUZZY);

Create a class:

 class chair_parms {
 private:
  colors color_;
  shapes shape_;
  textures texture_;
 public:
  chair_parms() :
   color_(BLUE), shape_(POINTY), texture_(FUZZY) { }
  colors color() const { return color_; }
  shapes shape() const { return shape_; }
  textures texture() const { return texture_; }

  chair_parms &color(colors c) { color_ = c; return *this; }
  chair_parms &shape(shapes s) { shape_ = s; return *this; }
  chair_parms &texture(textures t) { texture_ = t; return *this; }
 };

Then create a new function that takes this structure as a parameter and
calls the old one:

 void build_chair(const chair_parms &cp)
 {
  return build_chair(cp.color(), cp.shape(), cp.texture());
 }

Now users can say

 build_chair(chair_parms().shape(ROUND).color(RED));
 build_chair(chair_parms().texture(TACKY));
---
[ 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                             ]

On 17 Nov 97 10:42:05 GMT, mhamilton@bunge.com.au (Mab) wrote:

>In article <346bff0c.1276854@engnews1.eng>, stephen.clamage_nospam@eng.sun.com (Steve Clamage) wrote:
>>On 13 Nov 97 11:33:23 GMT, shai@kswaves.com (Shai Spharim) wrote:

>>Named arguments are a fine language feature in some languages, but
>>just don't fit into C++. You might find some old articles by me on the
>>subject in comp.std.c++ by checking Deja News. If not, I might be able
>>to dredge them up and post them again.

>I guess for anyone who really wants to implement them, you could sort
>of kludge it by doing this:

>typedef int MyIntegerType;
>typedef int MyOtherIntType;
> ...

No, that doesn't work. Typedefs create aliases for type names; they do
not create new types. You cannot overload on typedefs, and the meaning
of a piece of code is identical for any use of either int,
MyIntegerType, or MyOtherIntType in any context.

For class member functions you can often get an acceptible substitute
for named parameters by creating functions for each parameter value
and chaining them. For example, instead of this:

class T {
public:
 void doSomething(int height, int width, int depth);
};

You can do this:

class T {
 int h, w, d;
public:
 T& height(int i = default_height) { h = i; }
 T& width(int i = default_width) { w = i; }
 T& depth(int i = default_depth) { d = i; }
 void doSomething(); // uses h,w,d instead of parameters
};

Now you can write things like these for some T object t:

t.height().width(11).depth(12).doSomething(); // default height
t.width(12).depth(12).height(19).doSomething(); // arbitrary order




---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ 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                             ]