«

Hi,

Problem:
========
Some of my output functions are beginning to take pretty many
arguments... I mean.... We're talking about 10-15 arguments

So I thought to myself, perhaps this is beginning to get out of hands if
I continue to put in extra functionality in the (file-writing)
output-functions....

I thought to myself that perhaps I should begin to assemble some of the
2D pointers into some structures and then pass the pointer to the
"container" structure, even though I probably wont be needing all
pointers in the structure. That should get rid of a a few of function
arguments... Or would it be completely acceptable to live with say 20
arguments? As an example... Take this function:



void vtk_output(int nx, int ny, int nz, double *xvalues,
double *yvalues, double *zvalues,
double **temp_array, double **porosities,
double **local_rhocp, double **p_locations,
int show_p_locations, int show_rhocp,
unsigned number_of_interior_cells,
int *output_filestep, int output_direction,
int num_integration, int show_boundary)


I'm passing some integers that either has the value 0 or 1... Perhaps I
should rewrite the program and use some bit-fiddling stuff - using
logical AND / OR for comparing?

The following holds either 0 or 1:

int show_p_locations,
int show_rhocp,
int num_integration,
int show_boundar

And int output_direction is {0, 1, 2 or 3}.

Is there a good way of passing say.... "int control_stuff" where

control_stuff (bit 0) = show_p_locations;
control_stuff (bit 1) = show_rhocp
control_stuff (bit 2) = int num_integration,
control_stuff (bit 3) = int show_boundar
control_stuff (bit 4....7) = reserved for future use...

?

And does any upper limit exists - something about stack overflow or
something to consider, if one passes say 100 arguments (not that I could
think of doing it)?

Also, I never use any "extern" prototypes in my header files. I didn't
get any problems yet so I don't see why the "extern" keyword exists in
the first place? From what I've read various places, this extern keyword
just tells that the definition? is placed in another source file (AFAIR
- something like that)?



Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

"Martin Jørgensen" <> wrote in message
news:bp01m3-...
> Hi,
>
> Problem:
> ========
> Some of my output functions are beginning to take pretty many arguments...
> I mean.... We're talking about 10-15 arguments
>
> So I thought to myself, perhaps this is beginning to get out of hands if I
> continue to put in extra functionality in the (file-writing)
> output-functions....
>
> I thought to myself that perhaps I should begin to assemble some of the 2D
> pointers into some structures and then pass the pointer to the "container"
> structure, even though I probably wont be needing all pointers in the
> structure. That should get rid of a a few of function arguments... Or
> would it be completely acceptable to live with say 20 arguments? As an
> example... Take this function:
>
>
>
> void vtk_output(int nx, int ny, int nz, double *xvalues,
> double *yvalues, double *zvalues,
> double **temp_array, double **porosities,
> double **local_rhocp, double **p_locations,
> int show_p_locations, int show_rhocp,
> unsigned number_of_interior_cells,
> int *output_filestep, int output_direction,
> int num_integration, int show_boundary)
>
>
> I'm passing some integers that either has the value 0 or 1... Perhaps I
> should rewrite the program and use some bit-fiddling stuff - using logical
> AND / OR for comparing?
>
> The following holds either 0 or 1:
>
> int show_p_locations,
> int show_rhocp,
> int num_integration,
> int show_boundar
>
> And int output_direction is {0, 1, 2 or 3}.
>
> Is there a good way of passing say.... "int control_stuff" where
>
> control_stuff (bit 0) = show_p_locations;
> control_stuff (bit 1) = show_rhocp
> control_stuff (bit 2) = int num_integration,
> control_stuff (bit 3) = int show_boundar
> control_stuff (bit 4....7) = reserved for future use...
>
> ?
>
> And does any upper limit exists - something about stack overflow or
> something to consider, if one passes say 100 arguments (not that I could
> think of doing it)?
>
> Also, I never use any "extern" prototypes in my header files. I didn't get
> any problems yet so I don't see why the "extern" keyword exists in the
> first place? From what I've read various places, this extern keyword just
> tells that the definition? is placed in another source file (AFAIR -
> something like that)?

If the function is called recursively, then overflow of the stack (automatic
memory) might be a worry.
If your function is passing 100 arguments, then you have written a function
that is literally impossible to debug.
Almost for certain, this is a bad design.

If you are passing 20 arguments, then you have a function that is incredibly
difficult to debug.
Since 80% of the cost of software is maintenance, I think that is what
should really curtail how much stuff we pass into our functions. By making
the functions as small and simple as possible, we make them much easier to
debug and hence to maintain.

There are times when the complexity of the problem requires lots of
parameters to our function. In such cases, we will have to rely on
probabilistic testing + code coverage + endpoint (fencepost) style tests.

So I guess that I am saying that we should limit (as much as possible) the
arguments we pass into a function. But the reason is not due to stack
(we'll call it automatic memory here to avoid problems) but rather is due to
the difficulty of ensuring correctness with a monstrous pile of inputs.

IMO-YMMV.

> Best regards
> Martin Jørgensen
>
> --
> ---------------------------------------------------------------------------
> Home of Martin Jørgensen - http://www.martinjoergensen.dk

On Mon, 12 Jun 2006 22:52:26 +0200
Martin Jørgensen <> wrote:

> I thought to myself that perhaps I should begin to assemble some of
> the 2D pointers into some structures and then pass the pointer to the
> "container" structure, even though I probably wont be needing all
> pointers in the structure. That should get rid of a a few of function
> arguments... Or would it be completely acceptable to live with say 20
> arguments? As an example... Take this function:
>
>
>
> void vtk_output(int nx, int ny, int nz, double *xvalues,
> double *yvalues, double *zvalues,
> double **temp_array, double **porosities,
> double **local_rhocp, double **p_locations,
> int show_p_locations, int show_rhocp,
> unsigned number_of_interior_cells,
> int *output_filestep, int output_direction,
> int num_integration, int show_boundary)
>
I think you might have too much being done in one function, you might
want to have more than one output function. Maybe one for each kind of
data. That will probably make thing neater.

> And does any upper limit exists - something about stack overflow or
> something to consider, if one passes say 100 arguments (not that I
> could think of doing it)?
>
I think C specification specifies a minimum for number of arguments but
not a maximum, although most implementations probably have a limit.
You should check the documentation for the compiler you're using. Of
course, depending on the size of the structures being passed as
parameters you could have memory limitation issues. But you really
shouldn't think about passing that many parameters to a function.

Martin Jørgensen wrote:
> Hi,
>
> Problem:
> ========
> Some of my output functions are beginning to take pretty many
> arguments... I mean.... We're talking about 10-15 arguments

The only C language issue you've raised is the minimum translation
limit...

* 31 parameters in one function definition
* 31 arguments in one function call

[In C99 it's 127 parameters and arguments.]

> So I thought to myself, perhaps this is beginning to get out of hands if
> I continue to put in extra functionality in the (file-writing)
> output-functions....
>
> I thought to myself that perhaps I should begin to assemble some of the
> 2D pointers into some structures and then pass the pointer to the
> "container" structure,

Or do what most low level file I/O does, use pointers to parameter
blocks.

> even though I probably wont be needing all
> pointers in the structure. That should get rid of a a few of function
> arguments... Or would it be completely acceptable to live with say 20
> arguments?

It depends. You're more likely to hit implementation/platform and
general programming
issues than actual language issues.

> As an example... Take this function:
>
> void vtk_output(int nx, int ny, int nz, double *xvalues,
> double *yvalues, double *zvalues,
> double **temp_array, double **porosities,
> double **local_rhocp, double **p_locations,
> int show_p_locations, int show_rhocp,
> unsigned number_of_interior_cells,
> int *output_filestep, int output_direction,
> int num_integration, int show_boundary)
>
>
> I'm passing some integers that either has the value 0 or 1... Perhaps I
> should rewrite the program and use some bit-fiddling stuff - using
> logical AND / OR for comparing?
>
> The following holds either 0 or 1:
>
> int show_p_locations,
> int show_rhocp,
> int num_integration,
> int show_boundar
>
> And int output_direction is {0, 1, 2 or 3}.
>
> Is there a good way of passing say.... "int control_stuff" where
>
> control_stuff (bit 0) = show_p_locations;
> control_stuff (bit 1) = show_rhocp
> control_stuff (bit 2) = int num_integration,
> control_stuff (bit 3) = int show_boundar
> control_stuff (bit 4....7) = reserved for future use...
>
> ?

Consider the way that open works in POSIX, but it ain't pretty IMNSHO.

> And does any upper limit exists - something about stack overflow or
> something to consider, if one passes say 100 arguments (not that I could
> think of doing it)?

See above.

> Also, I never use any "extern" prototypes in my header files.

The lack of extern is incidental, the lack of prototype for such
functions is
criminal.

> I didn't get any problems yet so I don't see why the "extern" keyword exists
> in the first place? From what I've read various places, this extern keyword
> just tells that the definition? is placed in another source file (AFAIR
> - something like that)?

It says that the identifier being delcared has external linkage. It
needn't
be in another source file per se. [With headers, it's not always clear
what
'another source file' means since the header itself is usually another
source
file!]

It's basically redundant, but not quite as redundant as 'auto'.

--
Peter

On Mon, 12 Jun 2006 22:52:26 +0200, Martin Jørgensen
<> wrote:

>Hi,
>
>Problem:
>========
>Some of my output functions are beginning to take pretty many
>arguments... I mean.... We're talking about 10-15 arguments
>
>So I thought to myself, perhaps this is beginning to get out of hands if
>I continue to put in extra functionality in the (file-writing)
>output-functions....
>
>I thought to myself that perhaps I should begin to assemble some of the
>2D pointers into some structures and then pass the pointer to the
>"container" structure, even though I probably wont be needing all
>pointers in the structure.

All this would indicate to me that it's time to re-think the design.


--
Al Balmer
Sun City, AZ

Dann Corbit wrote:
> "Martin Jørgensen" <> wrote in message
> news:bp01m3-...
-snip-

> If you are passing 20 arguments, then you have a function that is incredibly
> difficult to debug.
> Since 80% of the cost of software is maintenance, I think that is what
> should really curtail how much stuff we pass into our functions. By making
> the functions as small and simple as possible, we make them much easier to
> debug and hence to maintain.

Inside the function, it then calls other functions so the problem is
split up into smaller pieces...

> There are times when the complexity of the problem requires lots of
> parameters to our function. In such cases, we will have to rely on
> probabilistic testing + code coverage + endpoint (fencepost) style tests.

How is that done?

> So I guess that I am saying that we should limit (as much as possible) the
> arguments we pass into a function. But the reason is not due to stack
> (we'll call it automatic memory here to avoid problems) but rather is due to
> the difficulty of ensuring correctness with a monstrous pile of inputs.

Ok.



Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

Rafael Almeida wrote:
> On Mon, 12 Jun 2006 22:52:26 +0200
> Martin Jørgensen <> wrote:
>
>
>>I thought to myself that perhaps I should begin to assemble some of
>>the 2D pointers into some structures and then pass the pointer to the
>> "container" structure, even though I probably wont be needing all
>>pointers in the structure. That should get rid of a a few of function
>>arguments... Or would it be completely acceptable to live with say 20
>>arguments? As an example... Take this function:
>>
>>
>>
>>void vtk_output(int nx, int ny, int nz, double *xvalues,
>> double *yvalues, double *zvalues,
>> double **temp_array, double **porosities,
>> double **local_rhocp, double **p_locations,
>> int show_p_locations, int show_rhocp,
>> unsigned number_of_interior_cells,
>> int *output_filestep, int output_direction,
>> int num_integration, int show_boundary)
>>
>
> I think you might have too much being done in one function, you might
> want to have more than one output function. Maybe one for each kind of
> data. That will probably make thing neater.

But it should all be written to the same file.... Hmm... But ok, good
point. Could probably be done. I just pass in FILE *fp as argument to
each sub-function.

>>And does any upper limit exists - something about stack overflow or
>>something to consider, if one passes say 100 arguments (not that I
>>could think of doing it)?
>>
>
> I think C specification specifies a minimum for number of arguments but
> not a maximum, although most implementations probably have a limit.
> You should check the documentation for the compiler you're using. Of
> course, depending on the size of the structures being passed as
> parameters you could have memory limitation issues. But you really
> shouldn't think about passing that many parameters to a function.

Do you mean it's a compiler issue if the number of arguments are too many?


Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

Peter Nilsson wrote:
> Martin Jørgensen wrote:
>
>>Hi,
>>
>>Problem:
>>========
>>Some of my output functions are beginning to take pretty many
>>arguments... I mean.... We're talking about 10-15 arguments
>
>
> The only C language issue you've raised is the minimum translation
> limit...
>
> * 31 parameters in one function definition
> * 31 arguments in one function call
>
> [In C99 it's 127 parameters and arguments.]

Don't you mean "the maximum limit"?

>>So I thought to myself, perhaps this is beginning to get out of hands if
>>I continue to put in extra functionality in the (file-writing)
>>output-functions....
>>
>>I thought to myself that perhaps I should begin to assemble some of the
>>2D pointers into some structures and then pass the pointer to the
>>"container" structure,
>
>
> Or do what most low level file I/O does, use pointers to parameter
> blocks.

Exactly what I was considering. Then I would have to rewrite a lot, but
that's okay...

>>even though I probably wont be needing all
>>pointers in the structure. That should get rid of a a few of function
>>arguments... Or would it be completely acceptable to live with say 20
>>arguments?
>
>
> It depends. You're more likely to hit implementation/platform and
> general programming
> issues than actual language issues.

How do I know if (as an example) 20 arguments would be too much.

Compiler error? Program crash? Unexpected behaviour? Something else?

>>As an example... Take this function:
>>
>>void vtk_output(int nx, int ny, int nz, double *xvalues,
>> double *yvalues, double *zvalues,
>> double **temp_array, double **porosities,
>> double **local_rhocp, double **p_locations,
>> int show_p_locations, int show_rhocp,
>> unsigned number_of_interior_cells,
>> int *output_filestep, int output_direction,
>> int num_integration, int show_boundary)
>>
>>
>>I'm passing some integers that either has the value 0 or 1... Perhaps I
>>should rewrite the program and use some bit-fiddling stuff - using
>>logical AND / OR for comparing?
>>
>>The following holds either 0 or 1:
>>
>>int show_p_locations,
>>int show_rhocp,
>>int num_integration,
>>int show_boundar
>>
>>And int output_direction is {0, 1, 2 or 3}.
>>
>>Is there a good way of passing say.... "int control_stuff" where
>>
>>control_stuff (bit 0) = show_p_locations;
>>control_stuff (bit 1) = show_rhocp
>>control_stuff (bit 2) = int num_integration,
>>control_stuff (bit 3) = int show_boundar
>>control_stuff (bit 4....7) = reserved for future use...
>>
>>?
>
>
> Consider the way that open works in POSIX, but it ain't pretty IMNSHO.

I have no idea about where to find out about that and I don't really
know what POSIX is (ok, I just googled and found out that it's an
abbreviation: Portable Operating System Interface.... + A family of
open system standards based on Unix. Bash is concerned with POSIX
1003.2....)

>>And does any upper limit exists - something about stack overflow or
>>something to consider, if one passes say 100 arguments (not that I could
>>think of doing it)?
>
>
> See above.
>
>
>>Also, I never use any "extern" prototypes in my header files.
>
>
> The lack of extern is incidental, the lack of prototype for such
> functions is
> criminal.

I have prototypes in my header files. They're just not "extern"...

>>I didn't get any problems yet so I don't see why the "extern" keyword exists
>>in the first place? From what I've read various places, this extern keyword
>>just tells that the definition? is placed in another source file (AFAIR
>>- something like that)?
>
>
> It says that the identifier being delcared has external linkage. It
> needn't
> be in another source file per se. [With headers, it's not always clear
> what
> 'another source file' means since the header itself is usually another
> source
> file!]
>
> It's basically redundant, but not quite as redundant as 'auto'.

Why do you have the "extern" keyword in front of the prototypes when it
seems unnecessary?


Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

Martin Jørgensen wrote:
>
.... snip ...
>
> Do you mean it's a compiler issue if the number of arguments are
> too many?

Not usually (see your compiler docs), but it is a human interface
problem. Look up the rule of 7.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

Martin Jørgensen wrote:

> Some of my output functions are beginning to take pretty many
> arguments... I mean.... We're talking about 10-15 arguments

I'd say that was about 10 too many, just on general principles.

--
Chris "seeker" Dollin
"We did not have time to find out everything we wanted to know." /A Clash of Cymbals/