Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Function call with wrong number of parameters

Reply
Thread Tools

Function call with wrong number of parameters

 
 
David Wade
Guest
Posts: n/a
 
      03-15-2007

"William Hughes" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> On Mar 15, 9:57 am, Chris Dollin <(E-Mail Removed)> wrote:
> > William Hughes wrote:
> > > On Mar 15, 7:14 am, (E-Mail Removed) (Kenny McCormack)
> > > wrote:
> > >> In article

<(E-Mail Removed) om>,William Hughes
<(E-Mail Removed)> wrote:
> >
> > >> ...

> >
> > >> >The behaviour is undefined (and if a prototype is in scope a
> > >> >diagnostic must be issued (many compilers will issue a diagnostic
> > >> >if a prototype is not is scope)).

> >
> > >> >C has neither named parameters, no default values for ommited
> > >> >parameters. Why I don't know. It strikes me that adding
> > >> >these features would

> >
> > >> > -be useful
> > >> > -be relatively easy
> > >> > -have few if any backwards compatability
> > >> > issues

> >
> > >> The fact is that C just isn't that sort of language. If you want VB

(or
> > >> even C++), you know where to find it.

> >
> > > But why do you say "C just isn't that sort of language"?

> >
> > Because, when you look at it, it isn't that sort of language:
> > convenience features aren't C's strength.
> >
> > > Is there something about the theory of the C language
> > > that precludes this sort of feature?

> >
> > "It's not useful enough".
> >
> > > It seems to me that adding a syntax to the
> > > prototype allowing for named and/or default parameters
> > > is easy enough. If the compiler can identify the function,
> > > then parsing and completing (if necessary) the provided
> > > arguments is straightforward. If the compiler cannot
> > > identify the function (e.g. function pointer)
> > > then it has no choice but to use the arguments
> > > provided and default methods.

> >
> > > What am I missing?

> >
> > There are many -- many, many, many -- simple and straightforward
> > features that might be added to C without doing violence to the
> > core. The trouble is, there are many, many, many such features,
> > of different value to different users, hence of different value
> > to different implementors, and of different levels of advocacy
> > in standards bodies.
> >
> > A feature isn't useful if you can't reasonably expect to find
> > it in all the implementations you expect to be targets. Adding
> > a new feature isn't a matter of noticing that it's easy to
> > add and bingo! We have it now: it's a matter of convincing
> > sufficiently many implementors that their users will want it
> > that it becomes sufficiently widespread that everyone has to
> > have it.
> >
> > That's discounting two other forces: that different
> > straightforward features may interact in crookedside ways,
> > and that for several such features have as a response "if you
> > need that, use C++".
> >

>
> True, but the same things apply to
> e.g. prototypes and complex number support.
>
> If the argument is simply
>
> We can't add all features, this is one we decided not
> to add
>
> OK. However, the (usefullness)/(difficulty to add) ratio
> seems to me to be quite high, higher than features that were
> added. Is this just a disagreement on the usefullness of
> the feature, or have I missed some difficulty in
> adding this feature.
>


I am not sure why its usefull. Provided you pass pointers then can't you
just pass "NULL" for any thing you want to omit. I am also not sure about
difficulty to add. Assuming you have separate compilation units then at
present code can work without function prototypes. This would require them
(I think) because I am pretty sure the caller would have to create dummy
paramters for the missing ones. If I had a vote I don't think its one I
would give it to...

> - William Hughes
>



 
Reply With Quote
 
 
 
 
Dik T. Winter
Guest
Posts: n/a
 
      03-16-2007
In article <(E-Mail Removed). com> "William Hughes" <(E-Mail Removed)> writes:

[ About default parameter values and named arguments.]

> If the argument is simply
>
> We can't add all features, this is one we decided not
> to add
>
> OK. However, the (usefullness)/(difficulty to add) ratio
> seems to me to be quite high, higher than features that were
> added. Is this just a disagreement on the usefullness of
> the feature, or have I missed some difficulty in
> adding this feature.


I do not think that this feature did even come up. Moreover, something along
the same features has already been done with structure initialisation, so
some of the syntax, actually, is already there. On the other hand, doing the
same for functions, comes pretty close to overloading, and would make quite a
few standard functions superfluous. Note, however, that the defaults *must*
be indicated in the prototype in order to have the same efficiency as
currently, and this can become quite confusing, e.g. what happens if you
call a function without a prototype in sight with insufficient parameters?
And especially so when in one place the definition serves as a prototype and
in another place there is only a declaration that serves as a prototype.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
 
Reply With Quote
 
 
 
 
Chris Dollin
Guest
Posts: n/a
 
      03-16-2007
Dik T. Winter wrote:

> In article <(E-Mail Removed). com> "William Hughes" <(E-Mail Removed)> writes:
>
> [ About default parameter values and named arguments.]
>
> > If the argument is simply
> >
> > We can't add all features, this is one we decided not
> > to add
> >
> > OK. However, the (usefullness)/(difficulty to add) ratio
> > seems to me to be quite high, higher than features that were
> > added. Is this just a disagreement on the usefullness of
> > the feature, or have I missed some difficulty in
> > adding this feature.

>
> I do not think that this feature did even come up. Moreover, something along
> the same features has already been done with structure initialisation, so
> some of the syntax, actually, is already there. On the other hand, doing the
> same for functions, comes pretty close to overloading, and would make quite a
> few standard functions superfluous. Note, however, that the defaults *must*
> be indicated in the prototype in order to have the same efficiency as
> currently, and this can become quite confusing, e.g. what happens if you
> call a function without a prototype in sight with insufficient parameters?


Oh, that's easy-peasy: "the effect is undefined"!

> And especially so when in one place the definition serves as a prototype and
> in another place there is only a declaration that serves as a prototype.


If we don't like it, we demonise it. Er ... not that I'd reccommend
that as a general rule.

--
Chris "Buffy hedgehog" Dollin
"It took a very long time, much longer than the most generous estimates."
- James White, /Sector General/

 
Reply With Quote
 
William Hughes
Guest
Posts: n/a
 
      03-16-2007
On Mar 15, 8:44 pm, "Dik T. Winter" <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed). com> "William Hughes" <(E-Mail Removed)> writes:
>
> [ About default parameter values and named arguments.]
>
> > If the argument is simply
> >
> > We can't add all features, this is one we decided not
> > to add
> >
> > OK. However, the (usefullness)/(difficulty to add) ratio
> > seems to me to be quite high, higher than features that were
> > added. Is this just a disagreement on the usefullness of
> > the feature, or have I missed some difficulty in
> > adding this feature.

>
> I do not think that this feature did even come up. Moreover, something along
> the same features has already been done with structure initialisation, so
> some of the syntax, actually, is already there. On the other hand, doing the
> same for functions, comes pretty close to overloading, and would make quite a
> few standard functions superfluous. Note, however, that the defaults *must*
> be indicated in the prototype in order to have the same efficiency as
> currently, and this can become quite confusing, e.g. what happens if you
> call a function without a prototype in sight with insufficient parameters?
> And especially so when in one place the definition serves as a prototype and
> in another place there is only a declaration that serves as a prototype.
> --


If you call a function without a declaration or definition in scope,
or only a
delclaration without parameter informationan, with the wrong
number and/or type of parameters then you are in nasal demon
territory. If a
declaration does not match the definition you are in nasal demon
territory [1].
Nothing new here. Still, I am not advocating the addition of default/
named parameters,
merely wondering whether there absence is due to some factor I had
not considered.

- William Hughes

[1] You do, of course, include foo.h in foo.c to catch this.

 
Reply With Quote
 
William Hughes
Guest
Posts: n/a
 
      03-16-2007
On Mar 15, 6:02 pm, "David Wade" <(E-Mail Removed)> wrote:
> "William Hughes" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed) ups.com...> On Mar 15, 9:57 am, Chris Dollin <(E-Mail Removed)> wrote:
> > > William Hughes wrote:
> > > > On Mar 15, 7:14 am, (E-Mail Removed) (Kenny McCormack)
> > > > wrote:
> > > >> In article

>
> <(E-Mail Removed) om>,William Hughes
>
>
>
> <(E-Mail Removed)> wrote:
>
> > > >> ...

>
> > > >> >The behaviour is undefined (and if a prototype is in scope a
> > > >> >diagnostic must be issued (many compilers will issue a diagnostic
> > > >> >if a prototype is not is scope)).

>
> > > >> >C has neither named parameters, no default values for ommited
> > > >> >parameters. Why I don't know. It strikes me that adding
> > > >> >these features would

>
> > > >> > -be useful
> > > >> > -be relatively easy
> > > >> > -have few if any backwards compatability
> > > >> > issues

>
> > > >> The fact is that C just isn't that sort of language. If you want VB

> (or
> > > >> even C++), you know where to find it.

>
> > > > But why do you say "C just isn't that sort of language"?

>
> > > Because, when you look at it, it isn't that sort of language:
> > > convenience features aren't C's strength.

>
> > > > Is there something about the theory of the C language
> > > > that precludes this sort of feature?

>
> > > "It's not useful enough".

>
> > > > It seems to me that adding a syntax to the
> > > > prototype allowing for named and/or default parameters
> > > > is easy enough. If the compiler can identify the function,
> > > > then parsing and completing (if necessary) the provided
> > > > arguments is straightforward. If the compiler cannot
> > > > identify the function (e.g. function pointer)
> > > > then it has no choice but to use the arguments
> > > > provided and default methods.

>
> > > > What am I missing?

>
> > > There are many -- many, many, many -- simple and straightforward
> > > features that might be added to C without doing violence to the
> > > core. The trouble is, there are many, many, many such features,
> > > of different value to different users, hence of different value
> > > to different implementors, and of different levels of advocacy
> > > in standards bodies.

>
> > > A feature isn't useful if you can't reasonably expect to find
> > > it in all the implementations you expect to be targets. Adding
> > > a new feature isn't a matter of noticing that it's easy to
> > > add and bingo! We have it now: it's a matter of convincing
> > > sufficiently many implementors that their users will want it
> > > that it becomes sufficiently widespread that everyone has to
> > > have it.

>
> > > That's discounting two other forces: that different
> > > straightforward features may interact in crookedside ways,
> > > and that for several such features have as a response "if you
> > > need that, use C++".

>
> > True, but the same things apply to
> > e.g. prototypes and complex number support.

>
> > If the argument is simply

>
> > We can't add all features, this is one we decided not
> > to add

>
> > OK. However, the (usefullness)/(difficulty to add) ratio
> > seems to me to be quite high, higher than features that were
> > added. Is this just a disagreement on the usefullness of
> > the feature, or have I missed some difficulty in
> > adding this feature.

>
> I am not sure why its usefull. Provided you pass pointers then can't you
> just pass "NULL" for any thing you want to omit. I am also not sure about
> difficulty to add. Assuming you have separate compilation units then at
> present code can work without function prototypes.


However, only if all calls to functions without prototypes use
the correct number and type of parameters. Adding default parameters
changes little. You could still call a function with default
parameters,
even without a prototype, as long as you include all parameters
(including default parameters).

If you use a coding style under which it is an error to call
a function without a prototype in scope
(except for the rare cases, eg function pointers,
where it is unavoidable) you cannot avoid prototypes.

>This would require them


Only to use the new feature. If no declaration or definition
containing
default information was in scope, then the compiler could not assume
that missing parameters exist. This does not lead to problems that
are
not already there.


- William Hughes

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      03-16-2007
William Hughes wrote:
>

.... snip ...
>
> If you use a coding style under which it is an error to call a
> function without a prototype in scope (except for the rare cases,
> eg function pointers, where it is unavoidable) you cannot avoid
> prototypes.


It is trivial to provide default parameters effects, where needed.
Two examples are:

getchar() via #define getchar() getc(stdin)
ggets(p) via #define ggets(p) fggets(p, stdin)

where getchar is part of the standard library, and ggets is defined
in my own ggets.h file.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
William Hughes
Guest
Posts: n/a
 
      03-16-2007
On Mar 15, 2:40 pm, "Stephen Sprunk" <(E-Mail Removed)> wrote:
> "William Hughes" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed) ps.com...
>
> > C has neither named parameters, no default values for ommited
> > parameters. Why I don't know. It strikes me that adding
> > these features would

>
> > -be useful
> > -be relatively easy
> > -have few if any backwards compatability
> > issues

>
> > On the other hand, the fact that these features did not make
> > it into C99 suggests that I am wrong.

>
> All of the new features in C99 that I care about are ones that various folks
> had implemented as extensions to their C89/90 compilers. Presumably the
> things you list above could also be added to C99 as extensions, and if they
> became popular they could be added to the standard in C0X. Since nobody has
> even bothered with implementing such extensions to date, it seems that
> they're not as useful and/or as easy as you think, and therefore it makes
> little sense to standardize them.


Indeed, but this just shifts the problem a bit. (I am aware that C90
and C99
to a large extent standardized existing extensions. What I am not
aware
of is whether any complier offers default/named parameters as an
extension.
Apparently not.) The question now becomes "why have they not been
implemented?".
The answer "it seems that they're not as useful and/or as easy as you
think"
while accurate, is not very useful. A bit more detail would be
helpful.

>
> If you disagree, go grab the GCC source, submit patches, and try to get some
> advocacy going over in comp.std.c.


If I had advocated their inclusion in C this would be good advice.

> Here in comp.lang.c, we discuss what
> _is_, not what _could be_.
>


As far a topicallity goes, the question "Why is feature X not found in
C?"
seem to me a good fit for comp.lang.c, (the slightly different
question
"Should feature X be added to the next C standard?" is clearly best
suited to comp.std.c).

- William Hughes

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Variable number of parameters on SOAP call? John Allen Ruby 2 03-03-2009 05:52 PM
How to call function whose function call with arguments is in astring grbgooglefan C++ 2 01-30-2008 07:18 AM
Class Member Data and Member Function Parameters - Should Parameters Be Data Members? Jason C++ 2 05-13-2006 07:11 AM
write a function such that when ever i call this function in some other function .it should give me tha data type and value of calling function parameter komal C++ 6 01-25-2005 11:13 AM
Variable number of parameters in a function call? Felix Kater C Programming 10 10-11-2004 08:17 PM



Advertisments