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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#58234

On 16/03/2015 17:07, Greg Martin wrote:
> On 2015-03-16, Martin Shobe <martin.shobe@yahoo.com> wrote:

>> 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 seriously think using a struct is nearly as good as using 
named/default arguments? OK, let's look at the disadvantages of using 
structs:

(1) You now have to create a corresponding struct for each of the 
hundreds of functions you might want to use named arguments for.

(2) You have to maintain a function parameter list *and* its struct.

(3) Each function, especially if applying this retroactively to an 
existing application, now has to be rewritten to use a single struct 
argument.

(4) Within each function, each a, b, c, d parameter now has to be 
written x.a, x.b, x.c, c.d etc.

(5) You have the extra overheads of passing a struct by value.

(6) In the caller, you either have to declare and initialise a struct 
separately, then pass it as fn(&s), which now becomes unreadable, or..

(7) ...use the ugly compound literal syntax (Martin gave an example of 
what that looks like.

(8) You can't now /optionally/ use either normal arguments to a 
function, or default/named parameters; it's all or nothing. Which means 
if introducing this to an existing application, you have to rewrite it.

(9) As you pointed out, you don't have much choice about default values 
(actually I'm not even sure that 0 is guaranteed with compound literals).

(10) In all, it will be such a painful, ungainly and unreadable way of 
doing it, that no-one will bother.

Of course using proper named/default arguments has its own disadvantage:

(1) You have to name the parameters in the function prototype, if one is 
used.

Once done however, you don't have to change anything else; you can 
optionally use the feature on a call-by-call basis. It is also easier to 
write, more readable, and requires little maintenance beyond what is 
needed anyway when a function interface changes.

-- 
Bartc

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

#58236

On 2015-03-16, Bartc <bc@freeuk.com> wrote:
> On 16/03/2015 17:07, Greg Martin wrote:
>> On 2015-03-16, Martin Shobe <martin.shobe@yahoo.com> wrote:
>
>>> 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 seriously think using a struct is nearly as good as using 
> named/default arguments? OK, let's look at the disadvantages of using 
> structs:
>

Specifically, to adding a separate syntax for the purpose.

> (1) You now have to create a corresponding struct for each of the 
> hundreds of functions you might want to use named arguments for.
>
> (2) You have to maintain a function parameter list *and* its struct.
>

No, that isn't the case at all - the parameter list is the structure.

> (3) Each function, especially if applying this retroactively to an 
> existing application, now has to be rewritten to use a single struct 
> argument.

As would be the case with new syntax. In addition all compilers would
have to support it for it to be of any value.

>
> (4) Within each function, each a, b, c, d parameter now has to be 
> written x.a, x.b, x.c, c.d etc.
>
> (5) You have the extra overheads of passing a struct by value.
>

Pass a pointer.

> (6) In the caller, you either have to declare and initialise a struct 
> separately, then pass it as fn(&s), which now becomes unreadable, or..
>
> (7) ...use the ugly compound literal syntax (Martin gave an example of 
> what that looks like.
>
> (8) You can't now /optionally/ use either normal arguments to a 
> function, or default/named parameters; it's all or nothing. Which means 
> if introducing this to an existing application, you have to rewrite it.
>

Yes and adding a new syntax means rewriting the code as well.

> (9) As you pointed out, you don't have much choice about default values 
> (actually I'm not even sure that 0 is guaranteed with compound literals).
>
> (10) In all, it will be such a painful, ungainly and unreadable way of 
> doing it, that no-one will bother.
>

It has the value of currently being possible and I believe people do
pass structs, or at least pointers to said, as arguments.

> Of course using proper named/default arguments has its own disadvantage:
>
> (1) You have to name the parameters in the function prototype, if one is 
> used.
>
> Once done however, you don't have to change anything else; you can 
> optionally use the feature on a call-by-call basis. It is also easier to 
> write, more readable, and requires little maintenance beyond what is 
> needed anyway when a function interface changes.
>

Not if a new syntax is introduced.

-- 
http://www.softsprocket.com

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

#58239

On 3/16/2015 1:30 PM, Greg Martin wrote:
> On 2015-03-16, Bartc <bc@freeuk.com> wrote:
>> On 16/03/2015 17:07, Greg Martin wrote:
>>> On 2015-03-16, Martin Shobe <martin.shobe@yahoo.com> wrote:
>> (3) Each function, especially if applying this retroactively to an
>> existing application, now has to be rewritten to use a single struct
>> argument.

> As would be the case with new syntax. In addition all compilers would
> have to support it for it to be of any value.

No. The new syntax would not be creating any struct argument. I'll 
further expand on the example I supplied you earlier.

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

void parent()
{
     /* Generated code equivalent to
        func1(0, 1, 3, 4); */
     func1(0, 1, .z = 4, .y = 3);
     /* Generated code equivalent to
        func1(0, 1, 3, 0); */
     func1(0, 1, .y = 3);
     /* Generated code equivalent to
        func1(0, 1, 3, 4); */
     func2(0, 1, .y = 3);
}

No need for any new structures or calling conventions.

>> Once done however, you don't have to change anything else; you can
>> optionally use the feature on a call-by-call basis. It is also easier to
>> write, more readable, and requires little maintenance beyond what is
>> needed anyway when a function interface changes.

> Not if a new syntax is introduced.

If we are using the new syntax as I mentioned, only those functions that 
will be using the keyword and default parameters would need to be 
changed. Those that aren't using keyword and default parameters can stay 
unchanged.

Martin Shobe

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

#58241

On 2015-03-16, Martin Shobe <martin.shobe@yahoo.com> wrote:
> On 3/16/2015 1:30 PM, Greg Martin wrote:
>> On 2015-03-16, Bartc <bc@freeuk.com> wrote:
>>> On 16/03/2015 17:07, Greg Martin wrote:
>>>> On 2015-03-16, Martin Shobe <martin.shobe@yahoo.com> wrote:
>>> (3) Each function, especially if applying this retroactively to an
>>> existing application, now has to be rewritten to use a single struct
>>> argument.
>
>> As would be the case with new syntax. In addition all compilers would
>> have to support it for it to be of any value.
>
> No. The new syntax would not be creating any struct argument. I'll 
> further expand on the example I supplied you earlier.
>

I didn't say it would. 

> void func1(int w, int x, int .y, int .z);
> void func2(int w, int x, int .y, int .z = 4);
>
> void parent()
> {
>      /* Generated code equivalent to
>         func1(0, 1, 3, 4); */
>      func1(0, 1, .z = 4, .y = 3);
>      /* Generated code equivalent to
>         func1(0, 1, 3, 0); */
>      func1(0, 1, .y = 3);
>      /* Generated code equivalent to
>         func1(0, 1, 3, 4); */
>      func2(0, 1, .y = 3);
> }
>
> No need for any new structures or calling conventions.
>

Again,I didn't suggest a new structure was required.You introduced a new
syntax and I said I saw little value in making that change vs. using
what is currently available.

>>> Once done however, you don't have to change anything else; you can
>>> optionally use the feature on a call-by-call basis. It is also easier to
>>> write, more readable, and requires little maintenance beyond what is
>>> needed anyway when a function interface changes.
>
>> Not if a new syntax is introduced.
>
> If we are using the new syntax as I mentioned, only those functions that 
> will be using the keyword and default parameters would need to be 
> changed. Those that aren't using keyword and default parameters can stay 
> unchanged.
>

Yes.



-- 
http://www.softsprocket.com

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

#58245

On 3/16/2015 2:35 PM, Greg Martin wrote:
> On 2015-03-16, Martin Shobe <martin.shobe@yahoo.com> wrote:
>> On 3/16/2015 1:30 PM, Greg Martin wrote:
>>> On 2015-03-16, Bartc <bc@freeuk.com> wrote:
>>>> On 16/03/2015 17:07, Greg Martin wrote:
>>>>> On 2015-03-16, Martin Shobe <martin.shobe@yahoo.com> wrote:
>>>> (3) Each function, especially if applying this retroactively to an
>>>> existing application, now has to be rewritten to use a single struct
>>>> argument.

>>> As would be the case with new syntax. In addition all compilers would
>>> have to support it for it to be of any value.

>> No. The new syntax would not be creating any struct argument. I'll
>> further expand on the example I supplied you earlier.

> I didn't say it would.

Then what were you saying? The statement you responded to was about 
rewriting functions to use a single struct argument. Your response 
indicated to me that you thought the syntax below would be doing the same.

>> void func1(int w, int x, int .y, int .z);
>> void func2(int w, int x, int .y, int .z = 4);
>>
>> void parent()
>> {
>>       /* Generated code equivalent to
>>          func1(0, 1, 3, 4); */
>>       func1(0, 1, .z = 4, .y = 3);
>>       /* Generated code equivalent to
>>          func1(0, 1, 3, 0); */
>>       func1(0, 1, .y = 3);
>>       /* Generated code equivalent to
>>          func1(0, 1, 3, 4); */
>>       func2(0, 1, .y = 3);
>> }

>> No need for any new structures or calling conventions.

> Again,I didn't suggest a new structure was required.You introduced a new
> syntax and I said I saw little value in making that change vs. using
> what is currently available.

Then I don't understand what you meant by, "As would be the case with 
new syntax. In addition all compilers would have to support it for it to 
be of any value." The "As would be the case" coming in response to 
pointing out the need for a struct in your proposal indicates, to me, 
that you were talking about the need to add a struct. This is further 
reinforced by "all compilers would have to support it." as, if there was 
a struct involved, the compilers would have to agree about how that 
struct is defined. So, what would be the case with the new syntax and 
why would all compilers need to support it to be useful?

Martin Shobe

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

#58249

On 2015-03-16, Martin Shobe <martin.shobe@yahoo.com> wrote:
> On 3/16/2015 2:35 PM, Greg Martin wrote:
>> On 2015-03-16, Martin Shobe <martin.shobe@yahoo.com> wrote:
>>> On 3/16/2015 1:30 PM, Greg Martin wrote:
>>>> On 2015-03-16, Bartc <bc@freeuk.com> wrote:
>>>>> On 16/03/2015 17:07, Greg Martin wrote:
>>>>>> On 2015-03-16, Martin Shobe <martin.shobe@yahoo.com> wrote:
>>>>> (3) Each function, especially if applying this retroactively to an
>>>>> existing application, now has to be rewritten to use a single struct
>>>>> argument.
>
>>>> As would be the case with new syntax. In addition all compilers would
>>>> have to support it for it to be of any value.
>
>>> No. The new syntax would not be creating any struct argument. I'll
>>> further expand on the example I supplied you earlier.
>
>> I didn't say it would.
>
> Then what were you saying? The statement you responded to was about 
> rewriting functions to use a single struct argument. Your response 
> indicated to me that you thought the syntax below would be doing the same.
>

I was saying if you use the syntax below you have to rewrite the
functions to support it, which was what BartC had suggested would be the
case to convert to using a struct.
This seems quite obvious. 

>>> void func1(int w, int x, int .y, int .z);
>>> void func2(int w, int x, int .y, int .z = 4);
>>>
>>> void parent()
>>> {
>>>       /* Generated code equivalent to
>>>          func1(0, 1, 3, 4); */
>>>       func1(0, 1, .z = 4, .y = 3);
>>>       /* Generated code equivalent to
>>>          func1(0, 1, 3, 0); */
>>>       func1(0, 1, .y = 3);
>>>       /* Generated code equivalent to
>>>          func1(0, 1, 3, 4); */
>>>       func2(0, 1, .y = 3);
>>> }
>
>>> No need for any new structures or calling conventions.
>
>> Again,I didn't suggest a new structure was required.You introduced a new
>> syntax and I said I saw little value in making that change vs. using
>> what is currently available.
>
> Then I don't understand what you meant by, "As would be the case with 
> new syntax. In addition all compilers would have to support it for it to 
> be of any value." The "As would be the case" coming in response to 
> pointing out the need for a struct in your proposal indicates, to me, 
> that you were talking about the need to add a struct. This is further 
> reinforced by "all compilers would have to support it." as, if there was 
> a struct involved, the compilers would have to agree about how that 
> struct is defined. So, what would be the case with the new syntax and 
> why would all compilers need to support it to be useful?
>>
No. You can all ready pass a structure, or pointer to such and have
named parameters. I'm not suggesting changing anything. The difference
between:
struct point {
	int x;
	int y;
};
void func (int a, int b, struct point* p);

and 
void func (int a, int b, int .x, int .y);

isn't sufficient for me to care about. To use either would require
changing a function that wasn't already defined that way.

-- 
http://www.softsprocket.com

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

#58244

On 16/03/2015 18:30, Greg Martin wrote:
> On 2015-03-16, Bartc <bc@freeuk.com> wrote:

>> (1) You now have to create a corresponding struct for each of the
>> hundreds of functions you might want to use named arguments for.
>>
>> (2) You have to maintain a function parameter list *and* its struct.

OK, that's true. Then the disadvantage is that you /lose/ the list of 
parameters at the point of function declaration (but presumably the 
accompanying struct will be nearby, unless it's possible to define the 
struct /within/ the parameter list).

>> (5) You have the extra overheads of passing a struct by value.
>>
>
> Pass a pointer.

Well some implementations would already do that. Then calling the 
function involves populating the struct, including the default zero 
arguments. (If the struct is not passed as const, then the called 
function could override all the fields of the struct.)

But on platforms such as x64 which would pass arguments in registers, 
this means they're back to having to pass args in memory, unless a 
compiler is clever enough to convert a value struct argument to multiple 
scalar arguments.

(You also lose the ability to apply const to individual parameters.)

> Yes and adding a new syntax means rewriting the code as well.

> Not if a new syntax is introduced.

No new syntax is needed for named parameters; parameters can already be 
named, but that is optional for prototypes.

But a new syntax is needed for default values.

This is an example using current C:

void draw_circle(int posx, int posy, int radius,
                  int thickness, int colour,
                  int solid, int solidcolour) {...}

draw_circle(120,100, 50, 1, black, 0, 0);

This is the same example with default values specified, but not made use 
of in the call:

void draw_circle(int posx=sx/2, int posy=sy/2, int radius=20,
                  int thickness=1, int colour=black,
                  int solid=0, int solidcolour=red) {...}

draw_circle(120,100, 50, 2, black, 0, 0);

Notice the call-code needn't change at all. However, to make use of 
named/default arguments, the same call can also be written as:

draw_circle(120, 100, 50);

And using positional params and defaults, or, using keyword args:

draw_circle(radius:50, posx:120, posy:100);

(Using a made-up ":" syntax for keyword args.) Now it's possible to have 
fun and just write:

  draw_circle(solid:1);

and hopefully a solid red 20-pixel diameter circle, outlined in black, 
will appear in the centre of the output.

-- 
Bartc

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

#58246

On 2015-03-16, Bartc <bc@freeuk.com> wrote:
> On 16/03/2015 18:30, Greg Martin wrote:
>> On 2015-03-16, Bartc <bc@freeuk.com> wrote:
>
>>> (1) You now have to create a corresponding struct for each of the
>>> hundreds of functions you might want to use named arguments for.
>>>
>>> (2) You have to maintain a function parameter list *and* its struct.
>
> OK, that's true. Then the disadvantage is that you /lose/ the list of 
> parameters at the point of function declaration (but presumably the 
> accompanying struct will be nearby, unless it's possible to define the 
> struct /within/ the parameter list).
>
>>> (5) You have the extra overheads of passing a struct by value.
>>>
>>
>> Pass a pointer.
>
> Well some implementations would already do that. Then calling the 
> function involves populating the struct, including the default zero 
> arguments. (If the struct is not passed as const, then the called 
> function could override all the fields of the struct.)
>
> But on platforms such as x64 which would pass arguments in registers, 
> this means they're back to having to pass args in memory, unless a 
> compiler is clever enough to convert a value struct argument to multiple 
> scalar arguments.
>
> (You also lose the ability to apply const to individual parameters.)
>
>> Yes and adding a new syntax means rewriting the code as well.
>
>> Not if a new syntax is introduced.
>
> No new syntax is needed for named parameters; parameters can already be 
> named, but that is optional for prototypes.
>

I agree, however, the post I was reponding to was suggesting a new
syntax.

> But a new syntax is needed for default values.
>
> This is an example using current C:
>
> void draw_circle(int posx, int posy, int radius,
>                   int thickness, int colour,
>                   int solid, int solidcolour) {...}
>
> draw_circle(120,100, 50, 1, black, 0, 0);
>
> This is the same example with default values specified, but not made use 
> of in the call:
>
> void draw_circle(int posx=sx/2, int posy=sy/2, int radius=20,
>                   int thickness=1, int colour=black,
>                   int solid=0, int solidcolour=red) {...}
>
> draw_circle(120,100, 50, 2, black, 0, 0);
>
> Notice the call-code needn't change at all. However, to make use of 
> named/default arguments, the same call can also be written as:
>
> draw_circle(120, 100, 50);
>
> And using positional params and defaults, or, using keyword args:
>
> draw_circle(radius:50, posx:120, posy:100);
>
> (Using a made-up ":" syntax for keyword args.) Now it's possible to have 
> fun and just write:
>
>   draw_circle(solid:1);
>
> and hopefully a solid red 20-pixel diameter circle, outlined in black, 
> will appear in the centre of the output.
>

When using JavaScript and Python I find the most interesting aspect of
their parameter passing stems from their object and dict syntax. They
introduce all kinds of interesting ways to approach problems. I also
love lambdas and argument binding et al but for some reason I don't feel
I miss them in C.


-- 
http://www.softsprocket.com

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

#58248

On 16/03/2015 19:55, Greg Martin wrote:

> When using JavaScript and Python I find the most interesting aspect of
> their parameter passing stems from their object and dict syntax. They
> introduce all kinds of interesting ways to approach problems. I also
> love lambdas and argument binding et al but for some reason I don't feel
> I miss them in C.

Maybe you haven't used the MS' Win32 API much, where the functions can 
easily have a dozen or more parameters.

Unfortunately to use default/keyword arguments with those, even if C 
were to acquire such a feature, means updating the Windows header files 
to add in all the parameter names and defaults needed.

-- 
bartc

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

#58250

On 2015-03-16, Bartc <bc@freeuk.com> wrote:
> On 16/03/2015 19:55, Greg Martin wrote:
>
>> When using JavaScript and Python I find the most interesting aspect of
>> their parameter passing stems from their object and dict syntax. They
>> introduce all kinds of interesting ways to approach problems. I also
>> love lambdas and argument binding et al but for some reason I don't feel
>> I miss them in C.
>
> Maybe you haven't used the MS' Win32 API much, where the functions can 
> easily have a dozen or more parameters.
>
> Unfortunately to use default/keyword arguments with those, even if C 
> were to acquire such a feature, means updating the Windows header files 
> to add in all the parameter names and defaults needed.
>

It's funny you should say that. Despite not having used that api since
the 90's it did come to mind reading this thread. Yes, I think that
might make me long for default arguments. 
 
-- 
http://www.softsprocket.com

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

#58251

W dniu poniedziałek, 16 marca 2015 21:23:53 UTC+1 użytkownik Bart napisał:
> On 16/03/2015 19:55, Greg Martin wrote:
> 
> > When using JavaScript and Python I find the most interesting aspect of
> > their parameter passing stems from their object and dict syntax. They
> > introduce all kinds of interesting ways to approach problems. I also
> > love lambdas and argument binding et al but for some reason I don't feel
> > I miss them in C.
> 
> Maybe you haven't used the MS' Win32 API much, where the functions can 
> easily have a dozen or more parameters.
> 
> Unfortunately to use default/keyword arguments with those, even if C 
> were to acquire such a feature, means updating the Windows header files 
> to add in all the parameter names and defaults needed.
> 
[some note] (i put it here though it is a bt random place not answer to the above)

as i mentioned i personally see some value in those named/annotated args *
(though with some reserve too) ..and
see yet more bit reserve to default 
args
(maybe not default args itself but
some kinds of its usage

[* as this is clear abstract interfacing alternative to ordinal passing]

for example for me seem a bit unnatural to wrap larger argument list function into shorter one 9and this way works those default args)
more natural for me would be (matbe) opposite i mean wrap longer around the shorter

besides that all, its wery vorth noting
imo that passing args is at all like wastefull - more economic (probably better) would be passing only one pointer to structure of args not long set of values of pointers ([!]) In reality it seems though that c solution is said 
like passing seperate values where really
it may be considered as one pointer passing (this pointer is esp) and building ad hoc structure of args
[imo it would be good to consider 
such elements in seperatyion (building args structure on acallerside then passing one pointer, and accessing args thru this pointer - considerng this in separation could allow for optimistations of reutilising those argument structures)

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

#58238

Martin Shobe <martin.shobe@yahoo.com> writes:
> On 3/16/2015 10:35 AM, Keith Thompson wrote:
[...]
>> 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);

Perhaps I've missed something in this thread, but I don't recall anyone
suggesting using the '.' notation in the function declaration, only in
calls (using a syntax similar to the existing syntax for designators in
compound literals and initializer lists).

It looks like you're making a distinction between parameters that can be
named and parameters that can't.  That doesn't strike me as useful.

Assuming the language supports named parameters in calls, how is it
useful to allow the author of a function declaration to forbid the use
of named notation for some parameters?

-- 
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]

#58240

On 3/16/2015 1:44 PM, Keith Thompson wrote:
> Martin Shobe <martin.shobe@yahoo.com> writes:
>> On 3/16/2015 10:35 AM, Keith Thompson wrote:
> [...]
>>> 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);
>
> Perhaps I've missed something in this thread, but I don't recall anyone
> suggesting using the '.' notation in the function declaration, only in
> calls (using a syntax similar to the existing syntax for designators in
> compound literals and initializer lists).

See message <i2odgah3ip4jg90hm2bk3pe658lu0ndh8k@4ax.com> by Robert Wessel.

> It looks like you're making a distinction between parameters that can be
> named and parameters that can't.  That doesn't strike me as useful.

Yes, I'm making that distinction.

> Assuming the language supports named parameters in calls, how is it
> useful to allow the author of a function declaration to forbid the use
> of named notation for some parameters?

In this case to avoid the problems in legacy code where prototypes 
didn't have to have names or might be inconsistently named. If I were 
starting a language from scratch, I wouldn't make such a distinction.

Martin Shobe

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

#58118

On 14/03/2015 22:11, 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>);

Keyword arguments too? They seem to go hand-in-hand with default arguments.

-- 
Bartc

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

#58122

W dniu niedziela, 15 marca 2015 02:33:59 UTC+1 użytkownik Bart napisał:
> On 14/03/2015 22:11, 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>);
> 
> Keyword arguments too? They seem to go hand-in-hand with default arguments.
> 
imo this is a good question, also a bit hard to answer but probably, the answer is yes, keyword arguments would be more usefull (and no they are not coming in pair too much)

when default args seem to break the rule of being explicite keyword args for me seem not to break it as it is only way
of expressing what to pass on caller side

though what exactly it should look like 
(if do) is another question

(ps im not totally against about default args, im not sure for some sub elements, some thing may depend on what and how etc)

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

#58152

On 15/03/15 02:33, Bartc wrote:
> On 14/03/2015 22:11, 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>);
>
> Keyword arguments too? They seem to go hand-in-hand with default arguments.
>

I think keyword argument support would be a useful addition to C and 
C++, and could be done without the kind of serious changes Jacob is 
suggesting here.

Of preference, I'd like to be able to write things like:

int foo(int x, int y);

foo(.y = 1, .x = 2);		// Same as foo(2, 1)
foo(1, .y = 2);			// Same as foo(1, 2)

But I'd settle for simply being allowed to write:

foo(.x = 1, .y = 2);		// Same as foo(1, 2)
foo(.y = 1, .x = 2);		// Error message!

That would drastically reduce the risk of errors when working with 
functions with lots of parameters, involve no changes to the code 
generation, and be pretty simple for a compiler to parse and check.

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

#58155

W dniu niedziela, 15 marca 2015 23:46:05 UTC+1 użytkownik David Brown napisał:
> On 15/03/15 02:33, Bartc wrote:
> > On 14/03/2015 22:11, 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>);
> >
> > Keyword arguments too? They seem to go hand-in-hand with default arguments.
> >
> 
> I think keyword argument support would be a useful addition to C and 
> C++, and could be done without the kind of serious changes Jacob is 
> suggesting here.
> 
> Of preference, I'd like to be able to write things like:
> 
> int foo(int x, int y);
> 
> foo(.y = 1, .x = 2);		// Same as foo(2, 1)
> foo(1, .y = 2);			// Same as foo(1, 2)
> 
> But I'd settle for simply being allowed to write:
> 
> foo(.x = 1, .y = 2);		// Same as foo(1, 2)
> foo(.y = 1, .x = 2);		// Error message!
> 
> That would drastically reduce the risk of errors when working with 
> functions with lots of parameters, involve no changes to the code 
> generation, and be pretty simple for a compiler to parse and check.

this style is like annotation and this optional annotative value is good, though
it somewhat seems that obj-c-like 'divided' function names looks nicer

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

#58171

On 16/03/15 00:21, fir wrote:
> W dniu niedziela, 15 marca 2015 23:46:05 UTC+1 użytkownik David Brown napisał:
>> On 15/03/15 02:33, Bartc wrote:
>>> On 14/03/2015 22:11, 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>);
>>>
>>> Keyword arguments too? They seem to go hand-in-hand with default arguments.
>>>
>>
>> I think keyword argument support would be a useful addition to C and 
>> C++, and could be done without the kind of serious changes Jacob is 
>> suggesting here.
>>
>> Of preference, I'd like to be able to write things like:
>>
>> int foo(int x, int y);
>>
>> foo(.y = 1, .x = 2);		// Same as foo(2, 1)
>> foo(1, .y = 2);			// Same as foo(1, 2)
>>
>> But I'd settle for simply being allowed to write:
>>
>> foo(.x = 1, .y = 2);		// Same as foo(1, 2)
>> foo(.y = 1, .x = 2);		// Error message!
>>
>> That would drastically reduce the risk of errors when working with 
>> functions with lots of parameters, involve no changes to the code 
>> generation, and be pretty simple for a compiler to parse and check.
> 
> this style is like annotation and this optional annotative value is good, though
> it somewhat seems that obj-c-like 'divided' function names looks nicer
> 

I haven't used Objective C, but from the little I've seen, "looks nicer"
is not how I would describe it...

But yes, if re-ordering the keyword arguments (or "named arguments", if
you prefer) is disallowed, then the use of argument names becomes an
annotation.  The point is that such annotations would be useful in
making code more readable, and in allowing the compiler to do more
static error checking.

It may even be preferable to ban re-ordering, to enforce consistency in
the code.

And I would want to have keyword arguments before any default arguments,
even though it would be less flexible than languages like Python - it
would make implementation simpler and clearer.  So even if you allow
re-ordering of keyword arguments, you can't use keyword arguments to
override some of the defaults without also overriding all earlier arguments:

int foo(int a, int b = b1, int c = c1, int d = d1);

foo(c = 3, b = 1, a = 2);		// Allowed, with d default
foo(a = 1, d = 2);			// Not allowed


The point of this is that "foo" can be compiled as something like :

foo_b :
	b = b1
foo_c :
	c = c1
foo_d :
	d = d1
foo :
	// implementation of foo

Then the function has multiple entry points, depending on how many
default arguments are used.

(I don't know if default arguments in C++ are implemented in this way.)

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

#58177

On 16/03/2015 10:41, David Brown wrote:

> But yes, if re-ordering the keyword arguments (or "named arguments", if
> you prefer) is disallowed, then the use of argument names becomes an
> annotation.  The point is that such annotations would be useful in
> making code more readable, and in allowing the compiler to do more
> static error checking.

An intriguing idea. But C already allows annotation using comments, 
perhaps with a bit more clutter than using a dedicated feature:

foo(/*a=*/ 1, /*b=*/ 2);

foo (1,   // a
      2    // b
     );

> It may even be preferable to ban re-ordering, to enforce consistency in
> the code.
>
> And I would want to have keyword arguments before any default arguments,
> even though it would be less flexible than languages like Python - it
> would make implementation simpler and clearer.  So even if you allow
> re-ordering of keyword arguments, you can't use keyword arguments to
> override some of the defaults without also overriding all earlier arguments:
>
> int foo(int a, int b = b1, int c = c1, int d = d1);
>
> foo(c = 3, b = 1, a = 2);		// Allowed, with d default
> foo(a = 1, d = 2);			// Not allowed
>

Sorry, you've made a straightforward, easy-to-understand and use feature 
into something that is impossible. I don't see what you're trying to 
achieve with these restrictions. Why *shouldn't* I be able to provide 
values for only a and d arguments, and in any order?

The point of this is that "foo" can be compiled as something like :
>
> foo_b :
> 	b = b1
> foo_c :
> 	c = c1
> foo_d :
> 	d = d1
> foo :
> 	// implementation of foo
>
> Then the function has multiple entry points, depending on how many
> default arguments are used.
>
> (I don't know if default arguments in C++ are implemented in this way.)

As I implement them, it's just a conventional function call. The 
default/keyword argument feature simply decides the argument values to 
push. Inside the called function it is also conventional.

Using your own example:

  int foo(int a, int b = b1, int c = c1, int d = d1);

then  foo(c = 3, b = 1, a = 2); is simply compiled as:

       foo(2, 1, 3, d1);

while foo(a = 1, d = 2); is compiled as:

       foo(1, b1, c1, 2);

Any problem with that?

-- 
Bartc

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

#58183

On 16/03/15 12:13, Bartc wrote:
> On 16/03/2015 10:41, David Brown wrote:
> 
>> But yes, if re-ordering the keyword arguments (or "named arguments", if
>> you prefer) is disallowed, then the use of argument names becomes an
>> annotation.  The point is that such annotations would be useful in
>> making code more readable, and in allowing the compiler to do more
>> static error checking.
> 
> An intriguing idea. But C already allows annotation using comments,
> perhaps with a bit more clutter than using a dedicated feature:
> 
> foo(/*a=*/ 1, /*b=*/ 2);
> 
> foo (1,   // a
>      2    // b
>     );

There are three things wrong with this - it is a lot more clutter than
my suggestion (and readability is key), it is not part of the language
and thus not checked by the compiler, and it abuses an existing feature
(comments).

Some static error checkers ("lint" programs) can use stylised comments
like this for extra checking.  But programs quickly become a mess - it's
hard to figure out what is the actual code, because of all the
weird-looking comments.  It is even worse if you try to combine
different types of comments such as static error checker comments,
doxygen documentation comments, and "ordinary" comments.

> 
>> It may even be preferable to ban re-ordering, to enforce consistency in
>> the code.
>>
>> And I would want to have keyword arguments before any default arguments,
>> even though it would be less flexible than languages like Python - it
>> would make implementation simpler and clearer.  So even if you allow
>> re-ordering of keyword arguments, you can't use keyword arguments to
>> override some of the defaults without also overriding all earlier
>> arguments:
>>
>> int foo(int a, int b = b1, int c = c1, int d = d1);
>>
>> foo(c = 3, b = 1, a = 2);        // Allowed, with d default
>> foo(a = 1, d = 2);            // Not allowed
>>
> 
> Sorry, you've made a straightforward, easy-to-understand and use feature
> into something that is impossible. I don't see what you're trying to
> achieve with these restrictions. Why *shouldn't* I be able to provide
> values for only a and d arguments, and in any order?

The main point is that if you can't re-order the arguments, the compiler
doesn't have to deal with the possibility.  The naming becomes merely an
annotation for error checking - it doesn't affect code generation at all.

The other issue is that it would enforce consistency in the code.  It
means you could not do something like this:

extern int foo(int b, int a);

foo(a = 1, b = 2);
foo(1, 2);	// Looks like it is the same as  foo(a = 1, b = 2)


> 
> The point of this is that "foo" can be compiled as something like :
>>
>> foo_b :
>>     b = b1
>> foo_c :
>>     c = c1
>> foo_d :
>>     d = d1
>> foo :
>>     // implementation of foo
>>
>> Then the function has multiple entry points, depending on how many
>> default arguments are used.
>>
>> (I don't know if default arguments in C++ are implemented in this way.)
> 
> As I implement them, it's just a conventional function call. The
> default/keyword argument feature simply decides the argument values to
> push. Inside the called function it is also conventional.
> 
> Using your own example:
> 
>  int foo(int a, int b = b1, int c = c1, int d = d1);
> 
> then  foo(c = 3, b = 1, a = 2); is simply compiled as:
> 
>       foo(2, 1, 3, d1);
> 
> while foo(a = 1, d = 2); is compiled as:
> 
>       foo(1, b1, c1, 2);
> 
> Any problem with that?
> 

No, that is equally possible.  It's a question of where the extra code
should go - at the caller site, or the callee site.  There is no single
correct answer to that.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web