Sorry if this has been brought up before, but I would like to see a
small change to the language as it is, you can only use default
parameter values in the declaration of of function, and it is illegal
to use this in the definition, unless the definition also is serving
as the declaration.

I'd like to propose that the definition allowed to have default
values, as long as the the default values match the declaration.

rm




---
Robert Mashlan  R2M Software  rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/
---
[ 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 42137520@library.airnews.net, rmashlan@r2m.com (Robert
Mashlan) writes:

>Sorry if this has been brought up before, but I would like to see a
>small change to the language as it is, you can only use default
>parameter values in the declaration of of function, and it is illegal
>to use this in the definition, unless the definition also is serving
>as the declaration.
>
>I'd like to propose that the definition allowed to have default
>values, as long as the the default values match the declaration.

One problem is defining "matching default values". The only realistic
definition would be "identical sequence of tokens".

(Reason for "identical": Does (1+1) match 2? If so, does (10.0/3) match
(30/9.0)? Does exp(0.0) match 1.0? The pairs are each equivalent under
the rules of C++. Then consider the validity of other transformations
such as (a+b) versus (b+a), where a user-defined operator might -- or
might not, you can't always tell -- be involved.)

But even "identical token sequence" is not sufficient. Consider
 int foo(int i = x); // x is a global variable or constant
Will the x referenced by this declaration be the same as the x
referenced at the site of the function definition? The compiler
would have to keep around a lot of information about default
parameter values to verify equivalence.

Next, what is the benefit gained by the change in rules? I don't
really see any, but apparently you have a problem you are trying
to solve.

But consider an historical note: Default parameter values were made part
of C++ before function overloading was really useable. (Look up the first
edition of "The C++ Programming Language" to see how overloading was
originally specified. It was pretty hard to use.) Stroustrup has said
that if overloading had been specified better at the start, he probably
would not have added default parameter values.

You can usually get the same effect more reliably (the rules for default
parameter values can trip you up) using overloading instead. Example:
Instead of
 int foo(int i=2, int j=3) { ... }
you can write
 int foo(int i, int j) { ... }
 int foo(int i)        { return foo(i, 3); }
 int foo()             { return foo(2, 3); }
This technique puts all the information about default values in one
place that cannot be overridden by alternative declarations. It also
eliminates surprises about names in scope at the declaration point
versus names in scope at the call site.
---
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:

>But even "identical token sequence" is not sufficient. Consider
> int foo(int i = x); // x is a global variable or constant
>Will the x referenced by this declaration be the same as the x
>referenced at the site of the function definition? The compiler
>would have to keep around a lot of information about default
>parameter values to verify equivalence.

The compiler already has to carry this information around whenever it
encounters a function call that uses the declaration.   The
definition,  when compiled, should match the internal representation
for the default parameter of the declaration.   Probably the best way
of expressing it is to say that the tokens, after preprocessing, and
expanded to be fully qualified (adding the namespace or class scope),
must match.

>Next, what is the benefit gained by the change in rules? I don't
>really see any, but apparently you have a problem you are trying
>to solve.

It would aid in documenting default parameters -- as it is, if you
want to look up the default parameters, you have to go look at the
file containing the declaration.   My habit is to document the default
parameters in the definition using comments in the parameter list,
but the problem is that if the defaults are changed in the
declaration, they may not be updated in the comments.  I'd like to
document the default parameters, and let the compiler enforce it,
without having to double-check the declaration.  Secondly, I'd like to
just simply cut and paste the declaration and use it as the definition
without editing out the default parameter list.

To me, it seems like the no redefinition rule is as harsh as it would
be to require declarations to use an anonymous parameter list.   The
compiler doesn't use the names of the parameters in the declaration,
but it is allowed to document the declaration.



---
Robert Mashlan  R2M Software  rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/



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