Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #58112 > unrolled thread

New directions in C: Default arguments

Back to article view | Back to comp.lang.c

Contents

  New directions in C: Default arguments jacob navia <jacob@spamsink.net> - 2015-03-14 23:11 +0100
    Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-14 18:17 -0700
      Re: New directions in C: Default arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-15 11:25 +0000
        Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-15 07:18 -0700
          Re: New directions in C: Default arguments Bartc <bc@freeuk.com> - 2015-03-15 14:32 +0000
            Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-15 08:30 -0700
              Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-15 09:05 -0700
                Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-15 10:15 -0700
                  Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-15 15:03 -0700
                    Re: New directions in C: Default arguments Bartc <bc@freeuk.com> - 2015-03-15 22:40 +0000
                      Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-15 16:04 -0700
                      Re: New directions in C: Default arguments Keith Thompson <kst-u@mib.org> - 2015-03-16 08:35 -0700
                        Re: New directions in C: Default arguments David Brown <david.brown@hesbynett.no> - 2015-03-16 16:45 +0100
                          Re: New directions in C: Default arguments Keith Thompson <kst-u@mib.org> - 2015-03-16 11:36 -0700
                            Re: New directions in C: Default arguments Philip Lantz <prl@canterey.us> - 2015-03-17 02:09 -0700
                              Re: New directions in C: Default arguments Bartc <bc@freeuk.com> - 2015-03-17 12:44 +0000
                                Re: New directions in C: Default arguments Philip Lantz <prl@canterey.us> - 2015-03-17 11:07 -0700
                        Re: New directions in C: Default arguments Martin Shobe <martin.shobe@yahoo.com> - 2015-03-16 11:35 -0500
                          Re: New directions in C: Default arguments Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-16 17:07 +0000
                            Re: New directions in C: Default arguments Martin Shobe <martin.shobe@yahoo.com> - 2015-03-16 12:40 -0500
                            Re: New directions in C: Default arguments Bartc <bc@freeuk.com> - 2015-03-16 18:12 +0000
                              Re: New directions in C: Default arguments Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-16 18:30 +0000
                                Re: New directions in C: Default arguments Martin Shobe <martin.shobe@yahoo.com> - 2015-03-16 13:52 -0500
                                  Re: New directions in C: Default arguments Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-16 19:35 +0000
                                    Re: New directions in C: Default arguments Martin Shobe <martin.shobe@yahoo.com> - 2015-03-16 14:52 -0500
                                      Re: New directions in C: Default arguments Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-16 20:27 +0000
                                Re: New directions in C: Default arguments Bartc <bc@freeuk.com> - 2015-03-16 19:44 +0000
                                  Re: New directions in C: Default arguments Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-16 19:55 +0000
                                    Re: New directions in C: Default arguments Bartc <bc@freeuk.com> - 2015-03-16 20:23 +0000
                                      Re: New directions in C: Default arguments Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-16 20:53 +0000
                                      Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-16 14:33 -0700
                          Re: New directions in C: Default arguments Keith Thompson <kst-u@mib.org> - 2015-03-16 11:44 -0700
                            Re: New directions in C: Default arguments Martin Shobe <martin.shobe@yahoo.com> - 2015-03-16 13:59 -0500
    Re: New directions in C: Default arguments Bartc <bc@freeuk.com> - 2015-03-15 01:33 +0000
      Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-15 00:59 -0700
      Re: New directions in C: Default arguments David Brown <david.brown@hesbynett.no> - 2015-03-15 23:45 +0100
        Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-15 16:21 -0700
          Re: New directions in C: Default arguments David Brown <david.brown@hesbynett.no> - 2015-03-16 11:41 +0100
            Re: New directions in C: Default arguments Bartc <bc@freeuk.com> - 2015-03-16 11:13 +0000
              Re: New directions in C: Default arguments David Brown <david.brown@hesbynett.no> - 2015-03-16 13:19 +0100
                Re: New directions in C: Default arguments Bartc <bc@freeuk.com> - 2015-03-16 12:38 +0000
                  Re: New directions in C: Default arguments David Brown <david.brown@hesbynett.no> - 2015-03-16 13:51 +0100
                    Re: New directions in C: Default arguments Bartc <bc@freeuk.com> - 2015-03-16 13:21 +0000
                      Re: New directions in C: Default arguments David Brown <david.brown@hesbynett.no> - 2015-03-16 15:12 +0100
                        Re: New directions in C: Default arguments Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 14:24 +0000
                          Re: New directions in C: Default arguments David Brown <david.brown@hesbynett.no> - 2015-03-16 16:09 +0100
                            Re: New directions in C: Default arguments Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 18:11 +0000
                              Re: New directions in C: Default arguments David Brown <david.brown@hesbynett.no> - 2015-03-17 13:23 +0100
                                Re: New directions in C: Default arguments Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 12:28 +0000
                                Re: New directions in C: Default arguments jacob navia <jacob@spamsink.net> - 2015-03-17 13:33 +0100
                                Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-17 08:20 -0700
                                  Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-17 15:16 -0700
        Re: New directions in C: Default arguments jacob navia <jacob@spamsink.net> - 2015-03-16 11:38 +0100
          Re: New directions in C: Default arguments Bartc <bc@freeuk.com> - 2015-03-16 10:51 +0000
            Re: New directions in C: Default arguments raltbos@xs4all.nl (Richard Bos) - 2015-03-16 13:47 +0000
          Re: New directions in C: Default arguments David Brown <david.brown@hesbynett.no> - 2015-03-16 13:20 +0100
          Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-16 10:43 -0700
        Re: New directions in C: Default arguments David Brown <david.brown@hesbynett.no> - 2015-03-17 13:18 +0100
    Re: New directions in C: Default arguments bert <bert.hutchings@btinternet.com> - 2015-03-15 08:25 -0700
      Re: New directions in C: Default arguments jacob navia <jacob@spamsink.net> - 2015-03-15 18:16 +0100
    Re: New directions in C: Default arguments Michael Angelo Ravera <maravera@prodigy.net> - 2015-03-16 00:38 -0700
      Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-16 01:03 -0700
      Re: New directions in C: Default arguments Robert Wessel <robertwessel2@yahoo.com> - 2015-03-16 09:04 -0500
        Re: New directions in C: Default arguments Michael Angelo Ravera <maravera@prodigy.net> - 2015-03-17 00:22 -0700
          Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-17 01:08 -0700
            Re: New directions in C: Default arguments fir <profesor.fir@gmail.com> - 2015-03-19 01:37 -0700
              Re: New directions in C: Default arguments asetofsymbols@gmail.com - 2015-03-20 00:45 -0700
          Re: New directions in C: Default arguments Robert Wessel <robertwessel2@yahoo.com> - 2015-03-17 22:17 -0500
            Re: New directions in C: Default arguments Michael Angelo Ravera <maravera@prodigy.net> - 2015-03-18 15:55 -0700
    Re: New directions in C: Default arguments gwowen <gwowen@gmail.com> - 2015-03-16 01:07 -0700
      Re: New directions in C: Default arguments Keith Thompson <kst-u@mib.org> - 2015-03-16 08:18 -0700
        Re: New directions in C: Default arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-16 17:35 +0000
        Definitions vs. Prototypes (Was: New directions in C: Default arguments) gazelle@shell.xmission.com (Kenny McCormack) - 2015-03-16 17:55 +0000
    Re: New directions in C: Default arguments Kaz Kylheku <kaz@kylheku.com> - 2015-03-16 20:21 +0000
      Re: New directions in C: Default arguments jacob navia <jacob@spamsink.net> - 2015-03-16 22:44 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#58112 — New directions in C: Default arguments

1.6 Default arguments
1.6.1 Motivation
Default arguments are formal parameters that are given a value (the 
default value) to use when the caller does not supply an actual 
parameter value. Of course, actual parameter values, when given, 
override the default values.

In many situations, some of the arguments to a function can be default 
values. This simplifies the interface for the function and at the same 
time keeps the necessary option for the user of the function, to specify 
some corner cases exactly.

Default arguments are used in Python, Fortran, the “Mathematica” 
language, Lisp, Ruby. Tcl/tk, Visual Basic.


1.6.2 Syntax
return-type fnName(arg1,arg2,arg3=<expr>,arg4=<expr>);

[toc] | [next] | [standalone]

#58117

W dniu sobota, 14 marca 2015 23:11:39 UTC+1 użytkownik jacob navia napisał:
> 1.6 Default arguments
> 1.6.1 Motivation

as to default agruments 9as known form c++) i (still) am not sure if this is/would be good in c

at first glance it seem usable, but at second it looks probably like not so
much usable i rather rarely see a use
of this (maybe, its hard to say exactly)

disadvantage is that it breax the rule of c code being explicit - in minor way but
ut breaks, for example if i remember ok
you then will nt be sure if

print()

is a 0-argument call of some multi argument call with default arguments - this is disadvantage possibly (probably) disqualifying it in my eye

it would be useful when this will 
allow for some binary optymistations
but i am not sure if this is used for some optymisations, probably no and tehere is only one function body and 
default arguments are pushed on stack implicitely on call side, ewentually
a wrapper could be written like

foo(int x)
{
  foo(x,2,3);
}

this could be done in normalc, more wrappers thus more set of 'default args' can be done this way and this is explicite

imo here are some places for potential optimisations for example in some way where more than one entry point to the function could be allowed - or something like that

[toc] | [prev] | [next] | [standalone]

#58124

fir <profesor.fir@gmail.com> writes:

> W dniu sobota, 14 marca 2015 23:11:39 UTC+1 użytkownik jacob navia napisał:
>> 1.6 Default arguments
>> 1.6.1 Motivation
>
> as to default agruments 9as known form c++) i (still) am not sure if
> this is/would be good in c
<snip>
> disadvantage is that it breax the rule of c code being explicit - in
> minor way but
> ut breaks, for example if i remember ok
> you then will nt be sure if
>
> print()
>
> is a 0-argument call of some multi argument call with default
> arguments - this is disadvantage possibly (probably) disqualifying it
> in my eye

Why would it disqualify it in C when it does not in other languages?
For example, in C++ the meaning of "print();" simply depends on the
declaration of print.  That might be a "bad idea", but it does not
disqualify the notion of default arguments.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#58131

W dniu niedziela, 15 marca 2015 12:25:43 UTC+1 użytkownik Ben Bacarisse napisał:
> fir <profesor.fir@gmail.com> writes:
> 
> > W dniu sobota, 14 marca 2015 23:11:39 UTC+1 użytkownik jacob navia napisał:
> >> 1.6 Default arguments
> >> 1.6.1 Motivation
> >
> > as to default agruments 9as known form c++) i (still) am not sure if
> > this is/would be good in c
> <snip>
> > disadvantage is that it breax the rule of c code being explicit - in
> > minor way but
> > ut breaks, for example if i remember ok
> > you then will nt be sure if
> >
> > print()
> >
> > is a 0-argument call of some multi argument call with default
> > arguments - this is disadvantage possibly (probably) disqualifying it
> > in my eye
> 
> Why would it disqualify it in C when it does not in other languages?
> For example, in C++ the meaning of "print();" simply depends on the
> declaration of print.  That might be a "bad idea", but it does not
> disqualify the notion of default arguments.
> 

(not sure if i 100% understand the question0

c has some spirit 

on one side imo c has some rule that says 'you may use some advanced syntax' (hard to express what i want to mean this is only aproximation) to express osme things 

but on the other side there is some rule that c code is explicit (there are no hidden 'folds' in c)

- and those default arguments in c++ style imo looks like such fold

[toc] | [prev] | [next] | [standalone]

#58133

On 15/03/2015 14:18, fir wrote:
> W dniu niedziela, 15 marca 2015 12:25:43 UTC+1 użytkownik Ben Bacarisse napisał:

>> Why would it disqualify it in C when it does not in other languages?
>> For example, in C++ the meaning of "print();" simply depends on the
>> declaration of print.  That might be a "bad idea", but it does not
>> disqualify the notion of default arguments.
>>
>
> (not sure if i 100% understand the question0
>
> c has some spirit
>
> on one side imo c has some rule that says 'you may use some advanced syntax' (hard to express what i want to mean this is only aproximation) to express osme things
>
> but on the other side there is some rule that c code is explicit (there are no hidden 'folds' in c)

There is plenty of implicit stuff in C already:

int a[10];
int b=malloc(40);

You now write b[i] just as you can a[i]; the pointer dereference is 
effectively implicit.

If you have a function f(), and a pointer-to-function g, then you can 
write g() just as you can f(). Again the dereference is automatic. (Just 
to save people the bother of posting, I understand they are both 
function pointers, but in that case, it is the decay of f to a pointer 
that is implicit.)

Because of this it's not immediately obvious what's happening with g() 
or b[i] without looking at their declarations.

Same thing with print(). And once you're familiar with the function 
signature, you will know what is being passed. Default arguments would 
be used when a particular argument value is very common, and is only 
different in unusual cases.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#58135

W dniu niedziela, 15 marca 2015 15:33:00 UTC+1 użytkownik Bart napisał:
> On 15/03/2015 14:18, fir wrote:
> > W dniu niedziela, 15 marca 2015 12:25:43 UTC+1 użytkownik Ben Bacarisse napisał:
> 
> >> Why would it disqualify it in C when it does not in other languages?
> >> For example, in C++ the meaning of "print();" simply depends on the
> >> declaration of print.  That might be a "bad idea", but it does not
> >> disqualify the notion of default arguments.
> >>
> >
> > (not sure if i 100% understand the question0
> >
> > c has some spirit
> >
> > on one side imo c has some rule that says 'you may use some advanced syntax' (hard to express what i want to mean this is only aproximation) to express osme things
> >
> > but on the other side there is some rule that c code is explicit (there are no hidden 'folds' in c)
> 
> There is plenty of implicit stuff in C already:
> 
> int a[10];
> int b=malloc(40);
> 
> You now write b[i] just as you can a[i]; the pointer dereference is 
> effectively implicit.
> 
> If you have a function f(), and a pointer-to-function g, then you can 
> write g() just as you can f(). Again the dereference is automatic. (Just 
> to save people the bother of posting, I understand they are both 
> function pointers, but in that case, it is the decay of f to a pointer 
> that is implicit.)
> 

no no, imo this is not implicit in the way defargs is, this is 100% explicit you have adres (label) and you use [] to dereference ram, this is very raw

(but if you have some thought or examples i may see )

> Because of this it's not immediately obvious what's happening with g() 
> or b[i] without looking at their declarations.
> 
> Same thing with print(). And once you're familiar with the function 
> signature, you will know what is being passed. Default arguments would 
> be used when a particular argument value is very common, and is only 
> different in unusual cases.
> 

ye maybe i know what you mean (or atleast what i have on my mind) - thats why i mentioned two rules, second is being explicid but one allows you to use some constructs, that are somewhat deeper
- for example may have two meanings depending on teh context or are like 
varargs in printf; but there is difference between varargs and defaultargs imo first probably conforms some rules of explicitivnes that defargs
do not - i may most probably say more on this a bit later

> -- 
> Bartc

[toc] | [prev] | [next] | [standalone]

#58136

ps i may add by explicit i for sure not mean non 'contex-differentiable'
language may be very 'context skewed'
and being quite explicit

i ment something other (bit on this 
later, now got a bit occupations)

[toc] | [prev] | [next] | [standalone]

#58138

W dniu niedziela, 15 marca 2015 17:05:57 UTC+1 użytkownik fir napisał:
> ps i may add by explicit i for sure not mean non 'contex-differentiable'
> language may be very 'context skewed'
> and being quite explicit
> 
> i ment something other (bit on this 
> later, now got a bit occupations)

I ment for example some situation where language writes soem implicit code that you could write on your own 

if the defautargs is implemented only by caller side by implicit pushes on calls this is such implicity, if this is implemented by making additional definitions it is yet more implicit, and if this would be unspecified explicitely, this is yet more implicit

(besides that natural c solutions are like more fundamental and wide)

[toc] | [prev] | [next] | [standalone]

#58150

besides that remarks (that ere heavily partial) one there could consider
a bot more general form (mentioned) with any interface to called functions (rest is default)

//foo has 17 args

foo(x=10, y=30); // 15 other args are default

foo(txt="aaa", y=30, z=12);// etc

can be done and could be considered usefull but seems probably wastefull
(not c style , though may be some uglier api style like microsoft etc)

[toc] | [prev] | [next] | [standalone]

#58151

On 15/03/2015 22:03, fir wrote:
> besides that remarks (that ere heavily partial) one there could consider
> a bot more general form (mentioned) with any interface to called functions (rest is default)
>
> //foo has 17 args
>
> foo(x=10, y=30); // 15 other args are default
>
> foo(txt="aaa", y=30, z=12);// etc
>
> can be done and could be considered usefull but seems probably wastefull
> (not c style , though may be some uglier api style like microsoft etc)

Presumably the C style is to have to put in all 17 parameters, usually 
without annotation, which means studying the function docs while writing 
it (and still having to count along to see which argument is which), and 
again when someone else is trying to read it.

Defaults arguments and keyword parameters are fairly straightforward 
enhancements, they are easy to implement (I've done it), and easy for 
users to grasp. In other words, a no-brainer.

However, I believe the proposal in this thread is to only have default 
arguments, and to only allow trailing arguments to be omitted. Still 
useful, but keyword parameters thrown in would have been good too.


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#58154

W dniu niedziela, 15 marca 2015 23:40:55 UTC+1 użytkownik Bart napisał:
> On 15/03/2015 22:03, fir wrote:
> > besides that remarks (that ere heavily partial) one there could consider
> > a bot more general form (mentioned) with any interface to called functions (rest is default)
> >
> > //foo has 17 args
> >
> > foo(x=10, y=30); // 15 other args are default
> >
> > foo(txt="aaa", y=30, z=12);// etc
> >
> > can be done and could be considered usefull but seems probably wastefull
> > (not c style , though may be some uglier api style like microsoft etc)
> 
> Presumably the C style is to have to put in all 17 parameters, usually 
> without annotation, which means studying the function docs while writing 
> it (and still having to count along to see which argument is which), and 
> again when someone else is trying to read it.
> 
> Defaults arguments and keyword parameters are fairly straightforward 
> enhancements, they are easy to implement (I've done it), and easy for 
> users to grasp. In other words, a no-brainer.
> 
> However, I believe the proposal in this thread is to only have default 
> arguments, and to only allow trailing arguments to be omitted. Still 
> useful, but keyword parameters thrown in would have been good too.
> 

wastefull are those default parameters passing

in this example above you can write functions wit 17 args that can be used
to simulate multiple various typecalls/functions realized by one body - could be done, but seems wastefull

the microsoft (winapi) like api is
itself a dengenerate thing (api where
most args are really mostly default),
and here it seem usefull but is still
suboptimal and messy 9at least seems for me)

[toc] | [prev] | [next] | [standalone]

#58212

Bartc <bc@freeuk.com> writes:
> On 15/03/2015 22:03, fir wrote:
>> besides that remarks (that ere heavily partial) one there could
>> consider a bot more general form (mentioned) with any interface to
>> called functions (rest is default)
>>
>> //foo has 17 args
>>
>> foo(x=10, y=30); // 15 other args are default
>>
>> foo(txt="aaa", y=30, z=12);// etc
>>
>> can be done and could be considered usefull but seems probably wastefull
>> (not c style , though may be some uglier api style like microsoft etc)
>
> Presumably the C style is to have to put in all 17 parameters, usually
> without annotation, which means studying the function docs while
> writing it (and still having to count along to see which argument is
> which), and again when someone else is trying to read it.
>
> Defaults arguments and keyword parameters are fairly straightforward
> enhancements, they are easy to implement (I've done it), and easy for
> users to grasp. In other words, a no-brainer.
>
> However, I believe the proposal in this thread is to only have default
> arguments, and to only allow trailing arguments to be omitted. Still
> useful, but keyword parameters thrown in would have been good too.

One problem with keyword parameters is that C doesn't require consistent
parameter names in all declarations.  Parameter names are not part of
the "signature" of a function (because in current C they're irrelevant
to the caller).

For example, given a definition like:

    void func(int x, int y) { /* ... */ }

any of these declarations would be compatible:

    void func(int, int);
    void func(int x, int y);
    void func(int y, int x);

Probably the simplest rule (that would not break existing code) would be
to make named parameters consistent with the most recent visible
declaration.

I'm ignoring old-style non-prototype declarations and definitions.
If default and/or named arguments were added to the language,
presumably they would *not* be supported for old-style definitions
and declarations.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#58213

On 16/03/15 16:35, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
>> On 15/03/2015 22:03, fir wrote:
>>> besides that remarks (that ere heavily partial) one there could
>>> consider a bot more general form (mentioned) with any interface to
>>> called functions (rest is default)
>>>
>>> //foo has 17 args
>>>
>>> foo(x=10, y=30); // 15 other args are default
>>>
>>> foo(txt="aaa", y=30, z=12);// etc
>>>
>>> can be done and could be considered usefull but seems probably wastefull
>>> (not c style , though may be some uglier api style like microsoft etc)
>>
>> Presumably the C style is to have to put in all 17 parameters, usually
>> without annotation, which means studying the function docs while
>> writing it (and still having to count along to see which argument is
>> which), and again when someone else is trying to read it.
>>
>> Defaults arguments and keyword parameters are fairly straightforward
>> enhancements, they are easy to implement (I've done it), and easy for
>> users to grasp. In other words, a no-brainer.
>>
>> However, I believe the proposal in this thread is to only have default
>> arguments, and to only allow trailing arguments to be omitted. Still
>> useful, but keyword parameters thrown in would have been good too.
> 
> One problem with keyword parameters is that C doesn't require consistent
> parameter names in all declarations.  Parameter names are not part of
> the "signature" of a function (because in current C they're irrelevant
> to the caller).
> 
> For example, given a definition like:
> 
>     void func(int x, int y) { /* ... */ }
> 
> any of these declarations would be compatible:
> 
>     void func(int, int);
>     void func(int x, int y);
>     void func(int y, int x);
> 
> Probably the simplest rule (that would not break existing code) would be
> to make named parameters consistent with the most recent visible
> declaration.

That's a simple rule, and means there is no longer any problem.  The
only conceivable alternative is to insist that declarations are
consistent - while I think that would be a great thing, it would break
existing code to no useful purpose.  It would therefore be a fine
optional warning feature for a compiler, but should not be part of the
language.

> 
> I'm ignoring old-style non-prototype declarations and definitions.
> If default and/or named arguments were added to the language,
> presumably they would *not* be supported for old-style definitions
> and declarations.
> 

Seems reasonable - I can't think of any other way it could work.

[toc] | [prev] | [next] | [standalone]

#58237

David Brown <david.brown@hesbynett.no> writes:
> On 16/03/15 16:35, Keith Thompson wrote:
[...]
>> One problem with keyword parameters is that C doesn't require consistent
>> parameter names in all declarations.  Parameter names are not part of
>> the "signature" of a function (because in current C they're irrelevant
>> to the caller).
>> 
>> For example, given a definition like:
>> 
>>     void func(int x, int y) { /* ... */ }
>> 
>> any of these declarations would be compatible:
>> 
>>     void func(int, int);
>>     void func(int x, int y);
>>     void func(int y, int x);
>> 
>> Probably the simplest rule (that would not break existing code) would be
>> to make named parameters consistent with the most recent visible
>> declaration.
>
> That's a simple rule, and means there is no longer any problem.  The
> only conceivable alternative is to insist that declarations are
> consistent - while I think that would be a great thing, it would break
> existing code to no useful purpose.  It would therefore be a fine
> optional warning feature for a compiler, but should not be part of the
> language.

I wouldn't say that there's "no longer any problem".

In current C, the parameter names are meaningless.  The C standard
presents the declaration of the fopen() function as:

    FILE *fopen(const char * restrict filename,
        const char * restrict mode);

but the implementation I use has:

    extern FILE *fopen (const char *__restrict __filename,
        const char *__restrict __modes) ;

which is perfectly valid.

Even if I had a compiler that supports named parameters, I couldn't
write:

    FILE *f = fopen(.filename = "foo.txt", .modes = "r");

Supporting named parameters in portable code would require library
providers to declare parameters consistently.  With this approach,
it would be many years before all implementations are updated to use
consistent parameter names, and code that uses the standard names
would fail to compile under some implementations.  The standard
library would be bad enough; other libraries could be worse.

I had been thinking that matching the most recent visible declaration
would be the best approach, but now I'm thinking that *if* named
parameters were to be added to the language, we'd need to add a
rule requiring names to be defined consistently.  (Presumably if
C had had named parameters from the beginning, this rule would
already have been in place.)  Having two visible declarations
that use different names would become a constraint violation.
A declaration that doesn't provide parameter names would mean you
couldn't used named parameters when calling it (or, perhaps, would no
longer be permitted).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#58274

Keith Thompson wrote:
> David Brown writes:
> > Keith Thompson wrote:
> [...]
> >> One problem with keyword parameters is that C doesn't require consistent
> >> parameter names in all declarations.  Parameter names are not part of
> >> the "signature" of a function (because in current C they're irrelevant
> >> to the caller).
> >> 
> >> For example, given a definition like:
> >> 
> >>     void func(int x, int y) { /* ... */ }
> >> 
> >> any of these declarations would be compatible:
> >> 
> >>     void func(int, int);
> >>     void func(int x, int y);
> >>     void func(int y, int x);
> >> 
> >> Probably the simplest rule (that would not break existing code) would be
> >> to make named parameters consistent with the most recent visible
> >> declaration.
> >
> > That's a simple rule, and means there is no longer any problem.  The
> > only conceivable alternative is to insist that declarations are
> > consistent - while I think that would be a great thing, it would break
> > existing code to no useful purpose.  It would therefore be a fine
> > optional warning feature for a compiler, but should not be part of the
> > language.
> 
> I wouldn't say that there's "no longer any problem".
> 
> In current C, the parameter names are meaningless.  The C standard
> presents the declaration of the fopen() function as:
> 
>     FILE *fopen(const char * restrict filename,
>         const char * restrict mode);
> 
> but the implementation I use has:
> 
>     extern FILE *fopen (const char *__restrict __filename,
>         const char *__restrict __modes) ;
> 
> which is perfectly valid.
> 
> Even if I had a compiler that supports named parameters, I couldn't
> write:
> 
>     FILE *f = fopen(.filename = "foo.txt", .modes = "r");
> 
> Supporting named parameters in portable code would require library
> providers to declare parameters consistently.  With this approach,
> it would be many years before all implementations are updated to use
> consistent parameter names, and code that uses the standard names
> would fail to compile under some implementations.  The standard
> library would be bad enough; other libraries could be worse.
> 
> I had been thinking that matching the most recent visible declaration
> would be the best approach, but now I'm thinking that *if* named
> parameters were to be added to the language, we'd need to add a
> rule requiring names to be defined consistently.  (Presumably if
> C had had named parameters from the beginning, this rule would
> already have been in place.)  Having two visible declarations
> that use different names would become a constraint violation.
> A declaration that doesn't provide parameter names would mean you
> couldn't used named parameters when calling it (or, perhaps, would no
> longer be permitted).

Another solution (which I probably read about here), would be to 
continue to allow inconsistency in parameter names in declarations, but 
to allow use of named parameters in calls only if the parameter names 
are identical all visible declarations. Thus the onus is on the 
programmer who wants to use this feature to get his declarations right. 
Anyone who doesn't care about the new feature can continue to do things 
the current way.

For functions in the standard library, the standard must either say that 
this feature is not available for those functions or specify the 
parameter names that are to be used. In the latter case, it wouldn't be 
a big deal to fix up the header files to use the standard-specified 
names, for any implementor that is striving to adhere to the new 
standard.

However, there is a big problem, exemplified by your declaration of 
fopen above. There's a good reason that your implementation uses names 
like __filename: it's because I am free (with the current standard) to 
write

#define filename "whatever"
#include <stdio.h>

Clearly, stdio.h cannot use 'filename' as a parameter name in the 
declaration of fopen (with the current standard).

If a future standard were to specify parameter names for library 
functions, the names it chooses would have to be reserved for that use. 
(Specifically, it would have to preclude said names from being defined 
as macros.) That's quite a restriction and would certainly break 
existing code, unless the names chosen are already reserved (such as 
'__filename'). I doubt anyone would like to use names like that, which 
is why I suggested above that even if this feature is added for user 
defined functions, the standard might not make it available for library 
functions.

[toc] | [prev] | [next] | [standalone]

#58284

On 17/03/2015 09:09, Philip Lantz wrote:
> Keith Thompson wrote:

>> I had been thinking that matching the most recent visible declaration
>> would be the best approach, but now I'm thinking that *if* named
>> parameters were to be added to the language, we'd need to add a
>> rule requiring names to be defined consistently.

> Another solution (which I probably read about here), would be to
> continue to allow inconsistency in parameter names in declarations, but
> to allow use of named parameters in calls only if the parameter names
> are identical all visible declarations.

Having different sets of a parameter names can be an advantage. For 
example, if you don't like the set of names that has already been 
chosen, or if the provided prototype doesn't use names at all. Different 
names won't change the interface in any way.

However, when default expressions are provided, then allowing such 
expressions to be overridden using a new prototype and a different 
expression, /can/ change what happens when the function is called.

> However, there is a big problem, exemplified by your declaration of
> fopen above. There's a good reason that your implementation uses names
> like __filename: it's because I am free (with the current standard) to
> write
>
> #define filename "whatever"
> #include <stdio.h>
>
> Clearly, stdio.h cannot use 'filename' as a parameter name in the
> declaration of fopen (with the current standard).

The names chosen for parameters exist in their own private name-space so 
should not clash with anything else.

Of course where the function is actually defined, then the usual care 
needs to be taken as the parameter names will be used within the body. 
But this is another reason for allowing names in an exported prototype 
to differ. People who write libraries may not anyway be willing to 
reveal their private naming schemes.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#58334

Bartc wrote:
> Philip Lantz wrote:
> > However, there is a big problem, exemplified by your declaration of
> > fopen above. There's a good reason that your implementation uses names
> > like __filename: it's because I am free (with the current standard) to
> > write
> >
> > #define filename "whatever"
> > #include <stdio.h>
> >
> > Clearly, stdio.h cannot use 'filename' as a parameter name in the
> > declaration of fopen (with the current standard).
> 
> The names chosen for parameters exist in their own private name-space so 
> should not clash with anything else.

Look at my example more closely. The preprocessor doesn't respect name 
spaces.

[toc] | [prev] | [next] | [standalone]

#58216

On 3/16/2015 10:35 AM, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
>> On 15/03/2015 22:03, fir wrote:
>>> besides that remarks (that ere heavily partial) one there could
>>> consider a bot more general form (mentioned) with any interface to
>>> called functions (rest is default)
>>>
>>> //foo has 17 args
>>>
>>> foo(x=10, y=30); // 15 other args are default
>>>
>>> foo(txt="aaa", y=30, z=12);// etc
>>>
>>> can be done and could be considered usefull but seems probably wastefull
>>> (not c style , though may be some uglier api style like microsoft etc)
>>
>> Presumably the C style is to have to put in all 17 parameters, usually
>> without annotation, which means studying the function docs while
>> writing it (and still having to count along to see which argument is
>> which), and again when someone else is trying to read it.
>>
>> Defaults arguments and keyword parameters are fairly straightforward
>> enhancements, they are easy to implement (I've done it), and easy for
>> users to grasp. In other words, a no-brainer.
>>
>> However, I believe the proposal in this thread is to only have default
>> arguments, and to only allow trailing arguments to be omitted. Still
>> useful, but keyword parameters thrown in would have been good too.
>
> One problem with keyword parameters is that C doesn't require consistent
> parameter names in all declarations.  Parameter names are not part of
> the "signature" of a function (because in current C they're irrelevant
> to the caller).
>
> For example, given a definition like:
>
>      void func(int x, int y) { /* ... */ }
>
> any of these declarations would be compatible:
>
>      void func(int, int);
>      void func(int x, int y);
>      void func(int y, int x);
>
> Probably the simplest rule (that would not break existing code) would be
> to make named parameters consistent with the most recent visible
> declaration.

Another simple rule would be to require that keyword parameters are 
identified explicitly in the prototype and require that those be named 
consistently.

For example (using . to identify keywords as seen else thread) the 
following would all be compatible.

void func(int w, int x, int .y, int .z);
void func(int x, int w, int .y, int .z);
void func(int, int, int .y, int .z);

However, the following would not be compatible with the above and would 
require a diagnostic if they both appeared in the same scope.

void func(int w, int x, int .z, int .y);

Martin Shobe

[toc] | [prev] | [next] | [standalone]

#58220

On 2015-03-16, Martin Shobe <martin.shobe@yahoo.com> wrote:
> On 3/16/2015 10:35 AM, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>>> On 15/03/2015 22:03, fir wrote:
>>>> besides that remarks (that ere heavily partial) one there could
>>>> consider a bot more general form (mentioned) with any interface to
>>>> called functions (rest is default)
>>>>
>>>> //foo has 17 args
>>>>
>>>> foo(x=10, y=30); // 15 other args are default
>>>>
>>>> foo(txt="aaa", y=30, z=12);// etc
>>>>
>>>> can be done and could be considered usefull but seems probably wastefull
>>>> (not c style , though may be some uglier api style like microsoft etc)
>>>
>>> Presumably the C style is to have to put in all 17 parameters, usually
>>> without annotation, which means studying the function docs while
>>> writing it (and still having to count along to see which argument is
>>> which), and again when someone else is trying to read it.
>>>
>>> Defaults arguments and keyword parameters are fairly straightforward
>>> enhancements, they are easy to implement (I've done it), and easy for
>>> users to grasp. In other words, a no-brainer.
>>>
>>> However, I believe the proposal in this thread is to only have default
>>> arguments, and to only allow trailing arguments to be omitted. Still
>>> useful, but keyword parameters thrown in would have been good too.
>>
>> One problem with keyword parameters is that C doesn't require consistent
>> parameter names in all declarations.  Parameter names are not part of
>> the "signature" of a function (because in current C they're irrelevant
>> to the caller).
>>
>> For example, given a definition like:
>>
>>      void func(int x, int y) { /* ... */ }
>>
>> any of these declarations would be compatible:
>>
>>      void func(int, int);
>>      void func(int x, int y);
>>      void func(int y, int x);
>>
>> Probably the simplest rule (that would not break existing code) would be
>> to make named parameters consistent with the most recent visible
>> declaration.
>
> Another simple rule would be to require that keyword parameters are 
> identified explicitly in the prototype and require that those be named 
> consistently.
>
> For example (using . to identify keywords as seen else thread) the 
> following would all be compatible.
>
> void func(int w, int x, int .y, int .z);
> void func(int x, int w, int .y, int .z);
> void func(int, int, int .y, int .z);
>
> However, the following would not be compatible with the above and would 
> require a diagnostic if they both appeared in the same scope.
>
> void func(int w, int x, int .z, int .y);
>
> Martin Shobe
>

What would this buy you, over using a structure to pass the arguments?
I'm not sure it would be worth the effort.

A structure as an argument allows some defaulting of arguments as well
as implicit named parameters. Admittedly the default arguments are
limited.


-- 
http://www.softsprocket.com

[toc] | [prev] | [next] | [standalone]

#58228

On 3/16/2015 12:07 PM, Greg Martin wrote:
> On 2015-03-16, Martin Shobe <martin.shobe@yahoo.com> wrote:
>> On 3/16/2015 10:35 AM, Keith Thompson wrote:
>>> Bartc <bc@freeuk.com> writes:
>>>> On 15/03/2015 22:03, fir wrote:
>>>>> besides that remarks (that ere heavily partial) one there could
>>>>> consider a bot more general form (mentioned) with any interface to
>>>>> called functions (rest is default)
>>>>>
>>>>> //foo has 17 args
>>>>>
>>>>> foo(x=10, y=30); // 15 other args are default
>>>>>
>>>>> foo(txt="aaa", y=30, z=12);// etc
>>>>>
>>>>> can be done and could be considered usefull but seems probably wastefull
>>>>> (not c style , though may be some uglier api style like microsoft etc)
>>>>
>>>> Presumably the C style is to have to put in all 17 parameters, usually
>>>> without annotation, which means studying the function docs while
>>>> writing it (and still having to count along to see which argument is
>>>> which), and again when someone else is trying to read it.
>>>>
>>>> Defaults arguments and keyword parameters are fairly straightforward
>>>> enhancements, they are easy to implement (I've done it), and easy for
>>>> users to grasp. In other words, a no-brainer.
>>>>
>>>> However, I believe the proposal in this thread is to only have default
>>>> arguments, and to only allow trailing arguments to be omitted. Still
>>>> useful, but keyword parameters thrown in would have been good too.
>>>
>>> One problem with keyword parameters is that C doesn't require consistent
>>> parameter names in all declarations.  Parameter names are not part of
>>> the "signature" of a function (because in current C they're irrelevant
>>> to the caller).
>>>
>>> For example, given a definition like:
>>>
>>>       void func(int x, int y) { /* ... */ }
>>>
>>> any of these declarations would be compatible:
>>>
>>>       void func(int, int);
>>>       void func(int x, int y);
>>>       void func(int y, int x);
>>>
>>> Probably the simplest rule (that would not break existing code) would be
>>> to make named parameters consistent with the most recent visible
>>> declaration.
>>
>> Another simple rule would be to require that keyword parameters are
>> identified explicitly in the prototype and require that those be named
>> consistently.
>>
>> For example (using . to identify keywords as seen else thread) the
>> following would all be compatible.
>>
>> void func(int w, int x, int .y, int .z);
>> void func(int x, int w, int .y, int .z);
>> void func(int, int, int .y, int .z);
>>
>> However, the following would not be compatible with the above and would
>> require a diagnostic if they both appeared in the same scope.
>>
>> void func(int w, int x, int .z, int .y);

> What would this buy you, over using a structure to pass the arguments?
> I'm not sure it would be worth the effort.

> A structure as an argument allows some defaulting of arguments as well
> as implicit named parameters. Admittedly the default arguments are
> limited.

You get a slightly nicer syntax, no need to explicitly define a 
structure (which also reduces namespace pollution), and the ability to 
default to something other than zero.

For example.

typedef struct func_params
{
     int .y;
     int .z;
} func_params;

void func1(int w, int x, func_params p);
/* func2 wants a default value that isn't 0. It's not supported by this 
method. */
void func2(int w, int x, int .y, int .z);

void parent()
{
     func1(0, 1, (func_params){.z = 4, .y = 3});
     func1(0, 1, (func_params){.y = 3});
     func2(0, 1, .y = 3, .z = 4);
}

would become

void func1(int w, int x, int .y, int .z);
void func2(int w, int x, int .y, int .z = 4);

void parent()
{
     func1(0, 1, .z = 4, .y = 3);
     func1(0, 1, .y = 3);
     func2(0, 1, .y = 3);
}

Admittedly it's not much, so I won't complain if it never happens, but I 
would like to see something like it.

Martin Shobe

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web