defaulting argument to previous argument

B

Bhushit Joshipura

It is illegal in g++ to default argument #6 to argument #5. I get an
error

[bhushit@x1-6-00-c0-49-b3-8a-c5 constantsum]$ g++ -g ../../surface.cpp
.../../../segments/segment.cpp
.../../../segments/geodesic-geodesic-state.cpp
.../../../segments/circular-circular-state.cpp *.cpp
ysumsphere.cpp:33: `where_00_ends' was not declared in this scope

for the code
Ysumsphere::Ysumsphere ( int x_min, int x_max, int y_min, int y_max,
int where_00_ends, int where_0max_ends = where_00_ends ) {
....
}

Definition : Monkeying
"Being able to express default arguments in terms of explicit
arguments"

My questions:
1. By the time the compiler sees arg #6, arg #5 is already seen. Why
does it fuss?
2. I can see cases in which Monkeying prevents unwanted assumptions
about explicit arguments. Do I miss a lesson in designing?
3. I fail to see anything fundamentally wrong with Monkeying. It is
just a matter of adding some more code to prologue of a function code.
Does it conflict with some absence of specification of order of
evaluation of arguments in C++?
4.I am sure I am neither the first nor the last to need this. How to
solve the situation the best? I do not want to put this burden on the
user of the class.

Any help appreciated.
-Bhushit
 
R

Ron Natalie

Bhushit Joshipura said:
My questions:
1. By the time the compiler sees arg #6, arg #5 is already seen. Why
does it fuss?

There is nothing that requires left to right evaluation of function arguments.
 
B

Bhushit Joshipura

Ron Natalie said:
There is nothing that requires left to right evaluation of function arguments.

Still questions #2 and #4 remain.
1. What if I need such a function? Am I the only one feeling the need?
2. How can I avoid putting unnecessary restriction on the ranage of
the arguments to be defaulted?
3. Is there a design strategy that would let me avoid this trap?
4. Why should my client be bothered with "always passing last
argument"?

-Bhushit
 
C

CrayzeeWulf

Bhushit Joshipura wrote:

Still questions #2 and #4 remain.
1. What if I need such a function? Am I the only one feeling the need?
2. How can I avoid putting unnecessary restriction on the ranage of
the arguments to be defaulted?
3. Is there a design strategy that would let me avoid this trap?
4. Why should my client be bothered with "always passing last
argument"?
You can use overloading to get full control over this process. How about
something like:

class Ysumsphere {
public:
Ysumsphere::Ysumsphere( int x_min,
int x_max,
int y_min,
int y_max,
int where_00_ends,
int where_0max_ends ) :
mXMin( x_min ),
mXMax( x_max ),
mYMin( y_min ),
mYMax( y_max ),
mWhere00Ends( where_00_ends ),
mWhere0MaxEnds( where_0max_ends ) { /* do something */ }

Ysumsphere::Ysumsphere( int x_min,
int x_max,
int y_min,
int y_max,
int where_00_ends ) :
mXMin( x_min ),
mXMax( x_max ),
mYMin( y_min ),
mYMax( y_max ),
mWhere00Ends( where_00_ends ),
mWhere0MaxEnds( where_00_ends ) { /* do something */ }
private:
int mXMin ;
int mXMax ;
int mYMin ;
int mYMax ;
int mWhere00Ends ;
int mWhere0MaxEnds ;
} ;

void yuck()
{
Ysumsphere foo( 1, 2, 3, 4, 5, 6 ) ;
Ysumsphere bar( 1, 2, 3, 4, 5 ) ;
return ;
}
 
N

Nick Hounsome

Bhushit Joshipura said:
It is illegal in g++ to default argument #6 to argument #5. I get an
error

[bhushit@x1-6-00-c0-49-b3-8a-c5 constantsum]$ g++ -g ../../surface.cpp
../../../segments/segment.cpp
../../../segments/geodesic-geodesic-state.cpp
../../../segments/circular-circular-state.cpp *.cpp
ysumsphere.cpp:33: `where_00_ends' was not declared in this scope

for the code
Ysumsphere::Ysumsphere ( int x_min, int x_max, int y_min, int y_max,
int where_00_ends, int where_0max_ends = where_00_ends ) {
...
}

Definition : Monkeying
"Being able to express default arguments in terms of explicit
arguments"

My questions:
1. By the time the compiler sees arg #6, arg #5 is already seen. Why
does it fuss?

because the order of evaluation of arguments is implementation defined.
Further teh standard specifically prohibits this (for the above reason)
2. I can see cases in which Monkeying prevents unwanted assumptions
about explicit arguments. Do I miss a lesson in designing?
3. I fail to see anything fundamentally wrong with Monkeying. It is
just a matter of adding some more code to prologue of a function code.
Does it conflict with some absence of specification of order of
evaluation of arguments in C++?

Yes - where_00_ends is a local variable that may or may not have been
initialised to the value of the supplied parameter when it is used to init
where_0max_ends
4.I am sure I am neither the first nor the last to need this. How to
solve the situation the best? I do not want to put this burden on the
user of the class.

Simple - use overloading:

Ysumsphere::Ysumsphere ( int x_min, int x_max, int y_min, int y_max,
int where_00_ends, int where_0max_ends) ;

Ysumsphere::Ysumsphere ( int x_min, int x_max, int y_min, int y_max,
int where_00_ends) ;

Unfortunately the second ctor can't call the first but the that doesn't
really matter for simple classes.

If you have more complicated construction and really want the effect of ctor
calling ctor then the same effect can be acheived by pushing the core stuff
into a base class - the overloaded ctors then call call the base ctor with
all the 'default' args.
 
S

ske

Nick said:
It is illegal in g++ to default argument #6 to argument #5. I get an
error

[bhushit@x1-6-00-c0-49-b3-8a-c5 constantsum]$ g++ -g ../../surface.cpp
../../../segments/segment.cpp
../../../segments/geodesic-geodesic-state.cpp
../../../segments/circular-circular-state.cpp *.cpp
ysumsphere.cpp:33: `where_00_ends' was not declared in this scope

for the code
Ysumsphere::Ysumsphere ( int x_min, int x_max, int y_min, int y_max,
int where_00_ends, int where_0max_ends = where_00_ends ) {
...
}

Definition : Monkeying
"Being able to express default arguments in terms of explicit
arguments"

My questions:
1. By the time the compiler sees arg #6, arg #5 is already seen. Why
does it fuss?


because the order of evaluation of arguments is implementation defined.
Further teh standard specifically prohibits this (for the above reason)

2. I can see cases in which Monkeying prevents unwanted assumptions
about explicit arguments. Do I miss a lesson in designing?
3. I fail to see anything fundamentally wrong with Monkeying. It is
just a matter of adding some more code to prologue of a function code.
Does it conflict with some absence of specification of order of
evaluation of arguments in C++?


Yes - where_00_ends is a local variable that may or may not have been
initialised to the value of the supplied parameter when it is used to init
where_0max_ends

4.I am sure I am neither the first nor the last to need this. How to
solve the situation the best? I do not want to put this burden on the
user of the class.


Simple - use overloading:

Ysumsphere::Ysumsphere ( int x_min, int x_max, int y_min, int y_max,
int where_00_ends, int where_0max_ends) ;

Ysumsphere::Ysumsphere ( int x_min, int x_max, int y_min, int y_max,
int where_00_ends) ;

Unfortunately the second ctor can't call the first but the that doesn't
really matter for simple classes.

If you have more complicated construction and really want the effect of ctor
calling ctor then the same effect can be acheived by pushing the core stuff
into a base class - the overloaded ctors then call call the base ctor with
all the 'default' args.

Alternatively if the parameters are only used to initialise member
variables then a single constructor with a member initialisation list
should do the trick (without having to duplicate constructors or add a
base class):

ie:
Ysumsphere::Ysumsphere ( int x_min, int x_max, int y_min, int y_max,
int where_00_ends) : where_0max_ends(where_00_ends) { ... }

Assuming of course that where_0max_ends is a member of the class.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top