Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #58112 > unrolled thread
| Started by | jacob navia <jacob@spamsink.net> |
|---|---|
| First post | 2015-03-14 23:11 +0100 |
| Last post | 2015-03-16 22:44 +0100 |
| Articles | 15 on this page of 75 — 18 participants |
Back to article view | Back to comp.lang.c
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 4 of 4 — ← Prev page 1 2 3 [4]
| From | Michael Angelo Ravera <maravera@prodigy.net> |
|---|---|
| Date | 2015-03-16 00:38 -0700 |
| Message-ID | <2c084891-7daf-493b-83ab-2277832b155d@googlegroups.com> |
| In reply to | #58112 |
On Saturday, March 14, 2015 at 3:11:39 PM UTC-7, jacob navia wrote: > 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>); I like being not only to be able to provide default values for seldom used arguments, but also to use sparse arguments to a function. It may be my exposure to the Non-Stop Kernel, but its file system interface had a few functions where one or two of the arguments were required or nearly so, but these functions often returned values of interest. The "modern C" way to do this is to pass a struct to retrieve a large pile of values about most of which you don't care in order to retrieve the value or two about which you do care. And to set just a couple of the values (using the modern C way), you often had to get the large pile values, change the couple that you wanted to change and then set the whole thing (and hope to hell that no one else was trying to change them at the same time). Sometimes there was a bit mask or enumerated list about which values to set or to retrieve. Counting commas was a major pain. So, allowing FILERECINFO (.FNUM fnum, .WRITEOFFSET &woff, .CURRENTLRECL & rec_size) instead of FILERECINFO (fnum,,,,, & rec_size,,,,,,, & woff) /*Did I count those commas right? */ would have done wonders. You can argue that such general purpose function could have a better set of arguments and I wouldn't necessarily disagree, but some functions like this exist in nearly every programming interface.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-16 01:03 -0700 |
| Message-ID | <e35a3be3-6320-4a9d-b12a-d65fd5d16003@googlegroups.com> |
| In reply to | #58160 |
W dniu poniedziałek, 16 marca 2015 08:38:10 UTC+1 użytkownik Michael Angelo Ravera napisał: > On Saturday, March 14, 2015 at 3:11:39 PM UTC-7, jacob navia wrote: > > 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>); > > I like being not only to be able to provide default values for seldom used arguments, but also to use sparse arguments to a function. > > It may be my exposure to the Non-Stop Kernel, but its file system interface had a few functions where one or two of the arguments were required or nearly so, but these functions often returned values of interest. The "modern C" way to do this is to pass a struct to retrieve a large pile of values about most of which you don't care in order to retrieve the value or two about which you do care. And to set just a couple of the values (using the modern C way), you often had to get the large pile values, change the couple that you wanted to change and then set the whole thing (and hope to hell that no one else was trying to change them at the same time). Sometimes there was a bit mask or enumerated list about which values to set or to retrieve. Counting commas was a major pain. So, allowing FILERECINFO (.FNUM fnum, .WRITEOFFSET &woff, .CURRENTLRECL & rec_size) instead of FILERECINFO (fnum,,,,, & rec_size,,,,,,, & woff) /*Did I count those commas right? */ would have done wonders. > > You can argue that such general purpose function could have a better set of arguments and I wouldn't necessarily disagree, but some functions like this exist in nearly every programming interface. you would have to specify arg names not types.. [my opinion is that i agree that for such degenerate api it would be usefull but as i said i see a lite trouble in that that it is a bit wastefull yet a bit implicite so imo not quite in natural spirit of c, smells like other language 'spirit']
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-03-16 09:04 -0500 |
| Message-ID | <i2odgah3ip4jg90hm2bk3pe658lu0ndh8k@4ax.com> |
| In reply to | #58160 |
On Mon, 16 Mar 2015 00:38:00 -0700 (PDT), Michael Angelo Ravera <maravera@prodigy.net> wrote: >On Saturday, March 14, 2015 at 3:11:39 PM UTC-7, jacob navia wrote: >> 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>); > >I like being not only to be able to provide default values for seldom used arguments, but also to use sparse arguments to a function. > >It may be my exposure to the Non-Stop Kernel, but its file system interface had a few functions where one or two of the arguments were required or nearly so, but these functions often returned values of interest. The "modern C" way to do this is to pass a struct to retrieve a large pile of values about most of which you don't care in order to retrieve the value or two about which you do care. And to set just a couple of the values (using the modern C way), you often had to get the large pile values, change the couple that you wanted to change and then set the whole thing (and hope to hell that no one else was trying to change them at the same time). Sometimes there was a bit mask or enumerated list about which values to set or to retrieve. Counting commas was a major pain. So, allowing FILERECINFO (.FNUM fnum, .WRITEOFFSET &woff, .CURRENTLRECL & rec_size) instead of FILERECINFO (fnum,,,,, & rec_size,,,,,,, & woff) /*Did I count those commas right? */ would have done wonders. > >You can argue that such general purpose function could have a better set of arguments and I wouldn't necessarily disagree, but some functions like this exist in nearly every programming interface. One thing that was often very handy in S/370 assembler was the ability to have both positional and keyword parameters. So you can have a few always used parameters positional, with the less common ones being keyword. You could still allow for default values for positional parameters. Perhaps something like: int f(int a, int b=5, int c=6; int .d=1, int .e=2); Which would have three positional parameters, with the latter two optional, and two keyword parameters. Which could be called with: f(1) f(1, 2) f(1, .e=9) f(1, 2, 3, .e=8) f(1, 3, .d=6) etc. You could also have mandatory keyword parameters with something like: int g(int a, int b=5, int c=6; int .d=1, int .e=2, int .f=); Where the f= keyword parameter is mandatory. In your example, allowing the first parameter, the presumably always needed FNUM, to be positional and mandatory would probably lead to reduced clutter for operands commonly known to be required.
[toc] | [prev] | [next] | [standalone]
| From | Michael Angelo Ravera <maravera@prodigy.net> |
|---|---|
| Date | 2015-03-17 00:22 -0700 |
| Message-ID | <3d75c547-89fc-48ad-a1b6-46c0e174e59a@googlegroups.com> |
| In reply to | #58200 |
On Monday, March 16, 2015 at 7:04:58 AM UTC-7, robert...@yahoo.com wrote: > On Mon, 16 Mar 2015 00:38:00 -0700 (PDT), Michael Angelo Ravera > <maravera@prodigy.net> wrote: > > >On Saturday, March 14, 2015 at 3:11:39 PM UTC-7, jacob navia wrote: > >> 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>); > > > >I like being not only to be able to provide default values for seldom used arguments, but also to use sparse arguments to a function. > > > >It may be my exposure to the Non-Stop Kernel, but its file system interface had a few functions where one or two of the arguments were required or nearly so, but these functions often returned values of interest. The "modern C" way to do this is to pass a struct to retrieve a large pile of values about most of which you don't care in order to retrieve the value or two about which you do care. And to set just a couple of the values (using the modern C way), you often had to get the large pile values, change the couple that you wanted to change and then set the whole thing (and hope to hell that no one else was trying to change them at the same time). Sometimes there was a bit mask or enumerated list about which values to set or to retrieve. Counting commas was a major pain. So, allowing FILERECINFO (.FNUM fnum, .WRITEOFFSET &woff, .CURRENTLRECL & rec_size) instead of FILERECINFO (fnum,,,,, & rec_size,,,,,,, & woff) /*Did I count those commas right? */ would have done wonders. > > > >You can argue that such general purpose function could have a better set of arguments and I wouldn't necessarily disagree, but some functions like this exist in nearly every programming interface. > > > One thing that was often very handy in S/370 assembler was the ability > to have both positional and keyword parameters. So you can have a few > always used parameters positional, with the less common ones being > keyword. You could still allow for default values for positional > parameters. Perhaps something like: > > int f(int a, int b=5, int c=6; int .d=1, int .e=2); > > Which would have three positional parameters, with the latter two > optional, and two keyword parameters. > > Which could be called with: > > f(1) > f(1, 2) > f(1, .e=9) > f(1, 2, 3, .e=8) > f(1, 3, .d=6) > > etc. > > You could also have mandatory keyword parameters with something like: > > int g(int a, int b=5, int c=6; int .d=1, int .e=2, int .f=); > > Where the f= keyword parameter is mandatory. > > In your example, allowing the first parameter, the presumably always > needed FNUM, to be positional and mandatory would probably lead to > reduced clutter for operands commonly known to be required. Absolutely agree. FILERECINFO (fnum, .WRITEOFFSET &woff, .CURRENTLRECL & rec_size) would be even better. Using a "#" operator as in "WRITEOFFSET# & woff" would be nice. But, I would settle for ".WRITEOFFSET = & woff". You could even allow the called function to expose local variables and allow the caller to initialize those in the same fashion. It may be bad programming, but the syntax is reasonable. Perhaps, you could even extend the syntax to make an argument (including a default) look like a struct reference FILERECINFO.FNUM=fnum; The question then becomes one of whether this is a statement that is executed or a declaration that is used for all subsequent calls, if any, lexically later in the scope.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-17 01:08 -0700 |
| Message-ID | <640e9dbd-33d5-4993-8b04-0b35cf1c7f2b@googlegroups.com> |
| In reply to | #58270 |
W dniu wtorek, 17 marca 2015 08:22:54 UTC+1 użytkownik Michael Angelo Ravera napisał: > Using a "#" operator as in "WRITEOFFSET# & woff" would be nice. But, I would settle for ".WRITEOFFSET = & woff". You could even allow the called function to expose local variables and allow the caller to initialize those in the same fashion. i also was considering this with locals, this is quite interesting "weird" option
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-19 01:37 -0700 |
| Message-ID | <b65ffdc1-99d4-484d-8692-e303c4c92fb9@googlegroups.com> |
| In reply to | #58271 |
W dniu wtorek, 17 marca 2015 09:08:39 UTC+1 użytkownik fir napisał: > > i also was considering this with locals, > this is quite interesting "weird" option though it would need a serious change of the abi and this is worse thing, also i dont see right now a serious usability (but wasnt thinking too much yet) some problem is that locals are initialised by the calee code - if they are not initialised they are not read so initialise it by the caller seem got no sense so you got two problems 1) how to pass this initialisation value by abi 2) how to off its initialisation - probably that would need the runtime fixup of the function body code and defixup it at end, [or maybe other a bit complex solution][[this way possible other modifications can be do by the caller to calee etc]] - Im not against the code fixups in c (as i said in the "deferred static arrays" thread but, those are special solutions seem one shpuld maybe not overuse it)
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-03-20 00:45 -0700 |
| Message-ID | <bcfd9585-cab8-4f87-8279-e7560504e423@googlegroups.com> |
| In reply to | #58437 |
The only weak point of C I see are not use uint8_t uint16_t uint32_t etc for portability... And something for allow portability for multithread... Yes RaII constructor/ destructor and operator definitions are for me good.. But for these there is C++ already
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-03-17 22:17 -0500 |
| Message-ID | <00rhga161e22l70c5mr1n4bpboup09a7e8@4ax.com> |
| In reply to | #58270 |
On Tue, 17 Mar 2015 00:22:34 -0700 (PDT), Michael Angelo Ravera <maravera@prodigy.net> wrote: >On Monday, March 16, 2015 at 7:04:58 AM UTC-7, robert...@yahoo.com wrote: >> On Mon, 16 Mar 2015 00:38:00 -0700 (PDT), Michael Angelo Ravera >> <maravera@prodigy.net> wrote: >> >> >On Saturday, March 14, 2015 at 3:11:39 PM UTC-7, jacob navia wrote: >> >> 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>); >> > >> >I like being not only to be able to provide default values for seldom used arguments, but also to use sparse arguments to a function. >> > >> >It may be my exposure to the Non-Stop Kernel, but its file system interface had a few functions where one or two of the arguments were required or nearly so, but these functions often returned values of interest. The "modern C" way to do this is to pass a struct to retrieve a large pile of values about most of which you don't care in order to retrieve the value or two about which you do care. And to set just a couple of the values (using the modern C way), you often had to get the large pile values, change the couple that you wanted to change and then set the whole thing (and hope to hell that no one else was trying to change them at the same time). Sometimes there was a bit mask or enumerated list about which values to set or to retrieve. Counting commas was a major pain. So, allowing FILERECINFO (.FNUM fnum, .WRITEOFFSET &woff, .CURRENTLRECL & rec_size) instead of FILERECINFO (fnum,,,,, & rec_size,,,,,,, & woff) /*Did I count those commas right? */ would have done wonders. >> > >> >You can argue that such general purpose function could have a better set of arguments and I wouldn't necessarily disagree, but some functions like this exist in nearly every programming interface. >> >> >> One thing that was often very handy in S/370 assembler was the ability >> to have both positional and keyword parameters. So you can have a few >> always used parameters positional, with the less common ones being >> keyword. You could still allow for default values for positional >> parameters. Perhaps something like: >> >> int f(int a, int b=5, int c=6; int .d=1, int .e=2); >> >> Which would have three positional parameters, with the latter two >> optional, and two keyword parameters. >> >> Which could be called with: >> >> f(1) >> f(1, 2) >> f(1, .e=9) >> f(1, 2, 3, .e=8) >> f(1, 3, .d=6) >> >> etc. >> >> You could also have mandatory keyword parameters with something like: >> >> int g(int a, int b=5, int c=6; int .d=1, int .e=2, int .f=); >> >> Where the f= keyword parameter is mandatory. >> >> In your example, allowing the first parameter, the presumably always >> needed FNUM, to be positional and mandatory would probably lead to >> reduced clutter for operands commonly known to be required. > >Absolutely agree. >FILERECINFO (fnum, .WRITEOFFSET &woff, .CURRENTLRECL & rec_size) >would be even better. > >Using a "#" operator as in "WRITEOFFSET# & woff" would be nice. But, I would settle for ".WRITEOFFSET = & woff". You could even allow the called function to expose local variables and allow the caller to initialize those in the same fashion. It may be bad programming, but the syntax is reasonable. Well, parameters are basically local variables anyway, and if they have defaults, you've achieved the same thing. You just end up with the "exposed" local variables needing to be defined in the list of parameters to the function. The parameters are modifiable just like "real" local variables are, and on most implementations are stored on the stack just like the "real" locals are, although usually on the other side of the return address on the stack. And many implementations can both either, or both, parameters and local variables in registers as they see fit. >Perhaps, you could even extend the syntax to make an argument (including a default) look like a struct reference FILERECINFO.FNUM=fnum; The question then becomes one of whether this is a statement that is executed or a declaration that is used for all subsequent calls, if any, lexically later in the scope. At that point you're adding a bit of minor convenience to the implementation of the function, and I don't think that's worth it. At best such a construct would replace a single assignment within the body of the routine. IMO, the main value for named parameters is for the convenience of the caller by simplifying the interface.
[toc] | [prev] | [next] | [standalone]
| From | Michael Angelo Ravera <maravera@prodigy.net> |
|---|---|
| Date | 2015-03-18 15:55 -0700 |
| Message-ID | <4194e449-cd3d-4899-b088-7ba61453d6ca@googlegroups.com> |
| In reply to | #58379 |
On Tuesday, March 17, 2015 at 8:17:07 PM UTC-7, robert...@yahoo.com wrote: > On Tue, 17 Mar 2015 00:22:34 -0700 (PDT), Michael Angelo Ravera > <maravera@prodigy.net> wrote: > > >On Monday, March 16, 2015 at 7:04:58 AM UTC-7, robert...@yahoo.com wrote: > >> On Mon, 16 Mar 2015 00:38:00 -0700 (PDT), Michael Angelo Ravera > >> <maravera@prodigy.net> wrote: > >> > >> >On Saturday, March 14, 2015 at 3:11:39 PM UTC-7, jacob navia wrote: > >> >> 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>); > >> > > >> >I like being not only to be able to provide default values for seldom used arguments, but also to use sparse arguments to a function. > >> > > >> >It may be my exposure to the Non-Stop Kernel, but its file system interface had a few functions where one or two of the arguments were required or nearly so, but these functions often returned values of interest. The "modern C" way to do this is to pass a struct to retrieve a large pile of values about most of which you don't care in order to retrieve the value or two about which you do care. And to set just a couple of the values (using the modern C way), you often had to get the large pile values, change the couple that you wanted to change and then set the whole thing (and hope to hell that no one else was trying to change them at the same time). Sometimes there was a bit mask or enumerated list about which values to set or to retrieve. Counting commas was a major pain. So, allowing FILERECINFO (.FNUM fnum, .WRITEOFFSET &woff, .CURRENTLRECL & rec_size) instead of FILERECINFO (fnum,,,,, & rec_size,,,,,,, & woff) /*Did I count those commas right? */ would have done wonders. > >> > > >> >You can argue that such general purpose function could have a better set of arguments and I wouldn't necessarily disagree, but some functions like this exist in nearly every programming interface. > >> > >> > >> One thing that was often very handy in S/370 assembler was the ability > >> to have both positional and keyword parameters. So you can have a few > >> always used parameters positional, with the less common ones being > >> keyword. You could still allow for default values for positional > >> parameters. Perhaps something like: > >> > >> int f(int a, int b=5, int c=6; int .d=1, int .e=2); > >> > >> Which would have three positional parameters, with the latter two > >> optional, and two keyword parameters. > >> > >> Which could be called with: > >> > >> f(1) > >> f(1, 2) > >> f(1, .e=9) > >> f(1, 2, 3, .e=8) > >> f(1, 3, .d=6) > >> > >> etc. > >> > >> You could also have mandatory keyword parameters with something like: > >> > >> int g(int a, int b=5, int c=6; int .d=1, int .e=2, int .f=); > >> > >> Where the f= keyword parameter is mandatory. > >> > >> In your example, allowing the first parameter, the presumably always > >> needed FNUM, to be positional and mandatory would probably lead to > >> reduced clutter for operands commonly known to be required. > > > >Absolutely agree. > >FILERECINFO (fnum, .WRITEOFFSET &woff, .CURRENTLRECL & rec_size) > >would be even better. > > > >Using a "#" operator as in "WRITEOFFSET# & woff" would be nice. But, I would settle for ".WRITEOFFSET = & woff". You could even allow the called function to expose local variables and allow the caller to initialize those in the same fashion. It may be bad programming, but the syntax is reasonable. > > > Well, parameters are basically local variables anyway, and if they > have defaults, you've achieved the same thing. You just end up with > the "exposed" local variables needing to be defined in the list of > parameters to the function. > > The parameters are modifiable just like "real" local variables are, > and on most implementations are stored on the stack just like the > "real" locals are, although usually on the other side of the return > address on the stack. And many implementations can both either, or > both, parameters and local variables in registers as they see fit. > > > >Perhaps, you could even extend the syntax to make an argument (including a default) look like a struct reference FILERECINFO.FNUM=fnum; The question then becomes one of whether this is a statement that is executed or a declaration that is used for all subsequent calls, if any, lexically later in the scope. > > > At that point you're adding a bit of minor convenience to the > implementation of the function, and I don't think that's worth it. At > best such a construct would replace a single assignment within the > body of the routine. IMO, the main value for named parameters is for > the convenience of the caller by simplifying the interface. There is, or should be, very little difference between exposing local variables and defining arguments. My point was that, if you permitted setting function arguments to look like a struct assignment, you could set your own set of defaults. That would be whether the argument was declared with a default value or not. I agree that the point of named arguments is to simplify the use of the interface. It makes it possible (with an intrinsic boolean function _present (arg)) for the implementer of function to deal with the fact that an argument was or wasn't passed at all. If, for instance, the function was going to set a number of attributes of an entity (like a file, record, directory, etc), it would be possible to avoid having to set any of the others or leave the fact that other attributes were to remain unchanged to the implementer. Retrieving values in a a large struct may be a pain but works OK, but there is always a possibility of a "lost update" when you have to try to set only a number of attributes and not all of the others when contention is a possibility. To do it right you always have to lock, get, set, and get, verify unlock, and often one at a time or do something else that you either can back out or retry.
[toc] | [prev] | [next] | [standalone]
| From | gwowen <gwowen@gmail.com> |
|---|---|
| Date | 2015-03-16 01:07 -0700 |
| Message-ID | <6d21381d-0549-4920-9590-4646e8287e68@googlegroups.com> |
| In reply to | #58112 |
On Saturday, March 14, 2015 at 10:11:39 PM UTC, jacob navia wrote: > 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>); Seems eminently sensible, and implementable (not least because any C/C++ joint compiler will have the support already). If I'm reading the syntax correctly, default args can be specified only in a prototype, not a definition?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-16 08:18 -0700 |
| Message-ID | <87r3sp0y52.fsf@kst-u.example.com> |
| In reply to | #58162 |
gwowen <gwowen@gmail.com> writes:
> On Saturday, March 14, 2015 at 10:11:39 PM UTC, jacob navia wrote:
>> 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>);
>
> Seems eminently sensible, and implementable (not least because any
> C/C++ joint compiler will have the support already). If I'm reading
> the syntax correctly, default args can be specified only in a
> prototype, not a definition?
A definition provides a prototype. Restricting what you can do in a
definition vs. a separate prototype would be odd.
--
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]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-03-16 17:35 +0000 |
| Message-ID | <87twxkkfqj.fsf@bsb.me.uk> |
| In reply to | #58210 |
Keith Thompson <kst-u@mib.org> writes: > gwowen <gwowen@gmail.com> writes: >> On Saturday, March 14, 2015 at 10:11:39 PM UTC, jacob navia wrote: >>> 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>); >> >> Seems eminently sensible, and implementable (not least because any >> C/C++ joint compiler will have the support already). If I'm reading >> the syntax correctly, default args can be specified only in a >> prototype, not a definition? > > A definition provides a prototype. More accurately, it may provide one (and probably should) but it need not do so. > Restricting what you can do in a > definition vs. a separate prototype would be odd. Ack. Another corner case is the declaration of pointer to a function. I think lcc-win allows default arguments here where C++ does not. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-03-16 17:55 +0000 |
| Subject | Definitions vs. Prototypes (Was: New directions in C: Default arguments) |
| Message-ID | <me75dl$9de$2@news.xmission.com> |
| In reply to | #58210 |
In article <87r3sp0y52.fsf@kst-u.example.com>,
Keith Thompson <kst-u@mib.org> wrote:
...
>A definition provides a prototype. Restricting what you can do in a
>definition vs. a separate prototype would be odd.
Odd, perhaps, but not unheard of.
An example I came across recently. GCC has the ability for you to specify,
via certain magic incantations, that your own functions have the same sort
of "format to args" checking that the builtin *printf() functions do.
But, surprisingly (to me anyway), you can't do it on the actual function
definition. So, you have to code it like this:
/* Both gcc & clang reject it if you try to do the "attribute" thing on the
* function definition itself... */
someType *some_fun(somethingT *something,somethingElseT somethingElse,char *fmt, ...)
__attribute__ ((format (printf, 3, 4)));
someType *some_fun(somethingT *something,somethingElseT somethingElse,char *fmt, ...)
{
...
}
--
But the Bush apologists hope that you won't remember all that. And they
also have a theory, which I've been hearing more and more - namely,
that President Obama, though not yet in office or even elected, caused the
2008 slump. You see, people were worried in advance about his future
policies, and that's what caused the economy to tank. Seriously.
(Paul Krugman - Addicted to Bush)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2015-03-16 20:21 +0000 |
| Message-ID | <20150316131246.369@kylheku.com> |
| In reply to | #58112 |
On 2015-03-14, jacob navia <jacob@spamsink.net> wrote: > Default arguments are used in Python, Fortran, the “Mathematica” > language, Lisp, Ruby. Tcl/tk, Visual Basic. Note conspicuous absence of C++. > 1.6.2 Syntax > return-type fnName(arg1,arg2,arg3=<expr>,arg4=<expr>); Note striking similarity to C++. Haha!
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2015-03-16 22:44 +0100 |
| Message-ID | <me7is6$pjg$1@speranza.aioe.org> |
| In reply to | #58247 |
Le 16/03/2015 21:21, Kaz Kylheku a écrit : > On 2015-03-14, jacob navia <jacob@spamsink.net> wrote: >> Default arguments are used in Python, Fortran, the “Mathematica” >> language, Lisp, Ruby. Tcl/tk, Visual Basic. > > Note conspicuous absence of C++. > >> 1.6.2 Syntax >> return-type fnName(arg1,arg2,arg3=<expr>,arg4=<expr>); > > Note striking similarity to C++. Haha! > So what? As I have said many times, why use an incompatible syntax between this proposed enhancements and c++? But OBVIOUSLY I should have done something incompatible so that users of both languages get annoyed? No way for me to be right. If I would have proposed something incompatible you would scream at me for that same reason
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web