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

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

scanf design

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

Contents

  scanf design "Bill Cuningham" <nospam@nspam.invalid> - 2016-12-11 16:42 -0500
    Re: scanf design Noob <root@127.0.0.1> - 2016-12-11 22:55 +0100
      Re: scanf design "Bill Cuningham" <nospam@nspam.invalid> - 2016-12-11 17:03 -0500
    Re: scanf design Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 22:05 +0000
    Re: scanf design Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-11 14:43 -0800
      Re: scanf design "Bill Cunningham" <nospam@nspam.invalid> - 2016-12-12 12:25 -0500
        Re: scanf design Keith Thompson <kst-u@mib.org> - 2016-12-12 11:15 -0800
          Re: scanf design Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 13:17 -0800
            Re: scanf design Keith Thompson <kst-u@mib.org> - 2016-12-12 14:02 -0800
              Re: scanf design Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 15:06 -0800
                Re: scanf design fir <profesor.fir@gmail.com> - 2016-12-12 15:58 -0800
                  Re: scanf design fir <profesor.fir@gmail.com> - 2016-12-12 16:10 -0800
                  Re: scanf design fir <profesor.fir@gmail.com> - 2016-12-12 16:10 -0800
                  Re: scanf design fir <profesor.fir@gmail.com> - 2016-12-12 16:22 -0800
                    Re: scanf design fir <profesor.fir@gmail.com> - 2016-12-15 07:30 -0800
                      Re: scanf design fir <profesor.fir@gmail.com> - 2016-12-15 07:56 -0800
                        Re: scanf design fir <profesor.fir@gmail.com> - 2016-12-15 08:21 -0800
      Re: scanf design "Bill Cunningham" <nospam@nspam.invalid> - 2016-12-12 13:18 -0500
        Re: scanf design Keith Thompson <kst-u@mib.org> - 2016-12-12 11:37 -0800

#98911 — scanf design

    I have notice over time, and the last few days I have been thinking 
about this in particular. scanf's design. It wants the value of the address 
a pointer points to. Hum now I notice many functions want a pointer's 
address. But not so many an address pointed at.

    What exactly do the designer's have in mind here when it comes to scanf 
and dealing with pointers. Or am I just seeing something that's not there.

int a;
scant ("%x\n",&a);

Should want a hex value or convert to a hex value. I can't remember scanf 
I've never really looked into greatly.

Bill

[toc] | [next] | [standalone]

#98914

On 11/12/2016 22:42, Bill Cuningham wrote:

Did you change your name?!

You used to be Bill Cunningham (with 2 'n')

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

#98917

"Noob" <root@127.0.0.1> wrote in message news:o2khu7$jqj$1@dont-email.me...
> On 11/12/2016 22:42, Bill Cuningham wrote:
>
> Did you change your name?!
>
> You used to be Bill Cunningham (with 2 'n')

    No I guess I made a mistake it should be 2 n's. And scanf is the 
function not scant.

Bill

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

#98919

"Bill Cuningham" <nospam@nspam.invalid> writes:

>     I have notice over time, and the last few days I have been thinking 
> about this in particular. scanf's design. It wants the value of the address 
> a pointer points to.

The value of the address a pointer points to is just a long-winded way
of saying the value of the pointer.

> Hum now I notice many functions want a pointer's address.

No, that's quite rare.  The most common situation is just a pointer,
i.e. an address.

> But not so many an address pointed at.

That's a bit vague.

>     What exactly do the designer's have in mind here when it comes to scanf 
> and dealing with pointers.

They expect you to pass a pointer to an object of the right type.  It's
much simpler is you always just use the word "pointer" and don't tie
yourself in knots using two very similar meaning words.

-- 
Ben.

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

#98931

On Sunday, December 11, 2016 at 9:42:45 PM UTC, Bill Cuningham wrote:
> I have notice over time, and the last few days I have been thinking 
> about this in particular. scanf's design. It wants the value of the 
> address a pointer points to. Hum now I notice many functions want 
> a pointer's address. But not so many an address pointed at.
> 
No, it's rare. Normally we pass in values, either directly or via
arrays, and get the results back either in the function's return 
type or in a buffer.
So normally pointers are named variables that point to buffers
of several values.


But scanf is a bit unusual in that it returns a flexible number of 
values of flexible type. So you see the & operator used heavily.
It's relatively rare to see the & operator used in most code.

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

#99090

"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message 
news:96650663-827e-4f89-b78f-7b42a2516ef3@googlegroups.com...
> On Sunday, December 11, 2016 at 9:42:45 PM UTC, Bill Cuningham wrote:
>> I have notice over time, and the last few days I have been thinking
>> about this in particular. scanf's design. It wants the value of the
>> address a pointer points to. Hum now I notice many functions want
>> a pointer's address. But not so many an address pointed at.
>>
> No, it's rare. Normally we pass in values, either directly or via
> arrays, and get the results back either in the function's return
> type or in a buffer.
> So normally pointers are named variables that point to buffers
> of several values.
>
>
> But scanf is a bit unusual in that it returns a flexible number of
> values of flexible type. So you see the & operator used heavily.
> It's relatively rare to see the & operator used in most code.

    So there's probably inside the body of scanf a lot of pointeres being 
used. I am going to use scanf more. I usually use fgets to stdin as the 3rd 
parameter. A bit odd probably.
    Here's how I usually use scanf when I have;

int a;
scanf("%d\n",&a);

But I have never done this, if it's legal;

int a;
int *pa==&a;
scanf("d\n",&pa);

So that '&' being there. Is for for passing pointer and other values, 
addresses and type  (int, double) values?

Bill

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

#99112

"Bill Cunningham" <nospam@nspam.invalid> writes:
> "Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message 
> news:96650663-827e-4f89-b78f-7b42a2516ef3@googlegroups.com...
>> On Sunday, December 11, 2016 at 9:42:45 PM UTC, Bill Cuningham wrote:
>>> I have notice over time, and the last few days I have been thinking
>>> about this in particular. scanf's design. It wants the value of the
>>> address a pointer points to. Hum now I notice many functions want
>>> a pointer's address. But not so many an address pointed at.
>>>
>> No, it's rare. Normally we pass in values, either directly or via
>> arrays, and get the results back either in the function's return
>> type or in a buffer.
>> So normally pointers are named variables that point to buffers
>> of several values.
>>
>> But scanf is a bit unusual in that it returns a flexible number of
>> values of flexible type. So you see the & operator used heavily.
>> It's relatively rare to see the & operator used in most code.

I don't know how rare it is, but using the & operator certainly isn't
unusual.  For example, one common convention is for functions to return
an int with the value zero to indicate success, and non-zero to indicate
failure, with any other information being passed back via pointers.

>     So there's probably inside the body of scanf a lot of pointeres being 
> used. I am going to use scanf more. I usually use fgets to stdin as the 3rd 
> parameter. A bit odd probably.
>     Here's how I usually use scanf when I have;
>
> int a;
> scanf("%d\n",&a);
>
> But I have never done this, if it's legal;
>
> int a;
> int *pa==&a;
> scanf("d\n",&pa);
>
> So that '&' being there. Is for for passing pointer and other values, 
> addresses and type  (int, double) values?

I presume you meant "%d\n" rather than "d\n".  No, that's not at all
valid.  &pa is the address of a pointer object; it's of type int**.
"%d" requires an argument of type int*.

You could legitimately write: scanf("%d\n", pa), which (given that
pa==&a) is equivalent to scanf("%d\n", &a).

It is possible to use scanf to read a pointer value from a text
representation, but that's hardly ever useful.

scanf is tricky.  It's probably ok if you're not concerned about input
errors, but the corner cases will eventually bite you.

Oh, and you haven't said why you have that trailing \n in the format
string, but it probably doesn't do what you think it does.  Hint: a
space would do exactly the same thing.  I suggest reading the
documentation for scanf to find what what that is.

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

#99135

On Monday, December 12, 2016 at 7:14:35 PM UTC, Keith Thompson wrote:
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>> Malcolm
> >> But scanf is a bit unusual in that it returns a flexible number of
> >> values of flexible type. So you see the & operator used heavily.
> >> It's relatively rare to see the & operator used in most code.
> 
> I don't know how rare it is, but using the & operator certainly isn't
> unusual.  For example, one common convention is for functions to return
> an int with the value zero to indicate success, and non-zero to indicate
> failure, with any other information being passed back via pointers.
> 
If you use that convention than, yes, unary & becomes common.

But it's not very common to see that convention. Partly because it
is more natural to write

if(getcheckstate(checkbox) == true)
  makebackup();

rather than

if(getcheckstate(checkbox, &checkflag) == ok)
{
    if(checkflag == true)
      makebackup();
}
else
{
   /* we know the dialog is visible because of preceding code,
      so what exactly is it supposed to mean for the checkbox
      to have a non-valid checkstate? What do we do here? */
}   

Another issue is that with the first snippet, all we need know
is that getcheckstate returns some sort of integer. In
the second snippet, checkflag might be a bool, or a bool_t, 
or an XFlagType. And you've got to get it right.

I rarely use unary & in code written entirely by myself,
though an exception is to return width and height for
functions which create images of dimensions not controlled by
caller.

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

#99139

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, December 12, 2016 at 7:14:35 PM UTC, Keith Thompson wrote:
>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>> Malcolm
>> >> But scanf is a bit unusual in that it returns a flexible number of
>> >> values of flexible type. So you see the & operator used heavily.
>> >> It's relatively rare to see the & operator used in most code.
>> 
>> I don't know how rare it is, but using the & operator certainly isn't
>> unusual.  For example, one common convention is for functions to return
>> an int with the value zero to indicate success, and non-zero to indicate
>> failure, with any other information being passed back via pointers.
>> 
> If you use that convention than, yes, unary & becomes common.
>
> But it's not very common to see that convention.

It certainly is in the programming I do.

>                                                  Partly because it
> is more natural to write
>
> if(getcheckstate(checkbox) == true)
>   makebackup();

Drop the "== true".

> rather than
>
> if(getcheckstate(checkbox, &checkflag) == ok)
> {
>     if(checkflag == true)
>       makebackup();
> }
> else
> {
>    /* we know the dialog is visible because of preceding code,
>       so what exactly is it supposed to mean for the checkbox
>       to have a non-valid checkstate? What do we do here? */
> }   

It means that there was a problem getting the state.  What we do here
depends on the application, but some kind of error handling is obviously
needed.  If you don't need a way to distinguish valid date from error
conditions, I suppose the simpler approach is ok.

> Another issue is that with the first snippet, all we need know
> is that getcheckstate returns some sort of integer. In
> the second snippet, checkflag might be a bool, or a bool_t, 
> or an XFlagType. And you've got to get it right.

Yes, you have to get the type right.  That's part of programming.

> I rarely use unary & in code written entirely by myself,
> though an exception is to return width and height for
> functions which create images of dimensions not controlled by
> caller.

In any case, the convention I mentioned (functions that return a status
indicator) was just one example of where unary & would commonly be used.
There are plenty of others.  I suspect your code is atypical.

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

#99146

On Monday, December 12, 2016 at 10:01:49 PM UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> In any case, the convention I mentioned (functions that return a status
> indicator) was just one example of where unary & would commonly be used.
> There are plenty of others.  I suspect your code is atypical.
>
I haven't done a count, but whilst I've certainly seen the convention
that the return type is always a success / fail error flag, it's
not terribly common.

My code doesn't need it. Because I always separate out functions
("Malcolm-functions") from IO. Malcolm functions cannot fail,
unless they run out of memory, and only a minority need to allocate
memory (the constructor / destructor pattern is common, but
then out of memory is indicated by the constructor returning a null
pointer). Of the minority that allocate memory, most can't fail
in normal use on functioning desktop systems because they don't 
ask for enough memory - the OS will kick up a fuss long before
the function asks for and is refused the last few hundred bytes.

So the use of error flags is very limited. If you need an error
flag, it's often better to demand that caller supply you with a
workspace buffer instead. That frees up the return value for its
natural use in a function that queries or calculates something.

If I was designing C from scratch I would allow syntax like

r1, r2 = quadratic_roots(a, b, c);
if(!isnan(r1) && !isnan(r2)) 


In fact I write this function

double roots[2];
Nroots = quadratic_roots(a, b, c, roots);
if(Nroots == 2)

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

#99151

W dniu wtorek, 13 grudnia 2016 00:07:05 UTC+1 użytkownik Malcolm McLean napisał:
> On Monday, December 12, 2016 at 10:01:49 PM UTC, Keith Thompson wrote:
> > Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >
> > In any case, the convention I mentioned (functions that return a status
> > indicator) was just one example of where unary & would commonly be used.
> > There are plenty of others.  I suspect your code is atypical.
> >
> I haven't done a count, but whilst I've certainly seen the convention
> that the return type is always a success / fail error flag, it's
> not terribly common.
> 
> My code doesn't need it. Because I always separate out functions
> ("Malcolm-functions") from IO. Malcolm functions cannot fail,
> unless they run out of memory, and only a minority need to allocate
> memory (the constructor / destructor pattern is common, but
> then out of memory is indicated by the constructor returning a null
> pointer). Of the minority that allocate memory, most can't fail
> in normal use on functioning desktop systems because they don't 
> ask for enough memory - the OS will kick up a fuss long before
> the function asks for and is refused the last few hundred bytes.
> 
> So the use of error flags is very limited. If you need an error
> flag, it's often better to demand that caller supply you with a
> workspace buffer instead. That frees up the return value for its
> natural use in a function that queries or calculates something.
> 
> If I was designing C from scratch I would allow syntax like
> 
> r1, r2 = quadratic_roots(a, b, c);
> if(!isnan(r1) && !isnan(r2)) 
> 
> 

here incidentally it would be more logical to get something like 

double[] root = quadratic_roots(a, b, c); 

//where root is full array i mean also denotes .end 
or .length information 
(physical realisation could involve hand managing 
of stacks 

so it could be in reality 

stack(3) double[] root = quadratic_roots(a, b, c); 

or other)

> In fact I write this function
> 
> double roots[2];
> Nroots = quadratic_roots(a, b, c, roots);
> if(Nroots == 2)

in present c i would do it

doubles root = quadratic_roots(a, b, c);

where struct doubles {double* beg; double* end; };
(more suuitable for longer list but still)
pointing to static inner area of quadratic_roots
9one need to remember that it can be rewritten but 
in reality coder probably handle it with not much
trouble)

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

#99152

W dniu wtorek, 13 grudnia 2016 00:58:30 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 13 grudnia 2016 00:07:05 UTC+1 użytkownik Malcolm McLean napisał:
> > On Monday, December 12, 2016 at 10:01:49 PM UTC, Keith Thompson wrote:
> > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> > >
> > > In any case, the convention I mentioned (functions that return a status
> > > indicator) was just one example of where unary & would commonly be used.
> > > There are plenty of others.  I suspect your code is atypical.
> > >
> > I haven't done a count, but whilst I've certainly seen the convention
> > that the return type is always a success / fail error flag, it's
> > not terribly common.
> > 
> > My code doesn't need it. Because I always separate out functions
> > ("Malcolm-functions") from IO. Malcolm functions cannot fail,
> > unless they run out of memory, and only a minority need to allocate
> > memory (the constructor / destructor pattern is common, but
> > then out of memory is indicated by the constructor returning a null
> > pointer). Of the minority that allocate memory, most can't fail
> > in normal use on functioning desktop systems because they don't 
> > ask for enough memory - the OS will kick up a fuss long before
> > the function asks for and is refused the last few hundred bytes.
> > 
> > So the use of error flags is very limited. If you need an error
> > flag, it's often better to demand that caller supply you with a
> > workspace buffer instead. That frees up the return value for its
> > natural use in a function that queries or calculates something.
> > 
> > If I was designing C from scratch I would allow syntax like
> > 
> > r1, r2 = quadratic_roots(a, b, c);
> > if(!isnan(r1) && !isnan(r2)) 
> > 
> > 
> 
> here incidentally it would be more logical to get something like 
> 
> double[] root = quadratic_roots(a, b, c); 
> 
> //where root is full array i mean also denotes .end 
> or .length information 
> (physical realisation could involve hand managing 
> of stacks 
> 
> so it could be in reality 
> 
> stack(3) double[] root = quadratic_roots(a, b, c); 
> 
> or other)
> 
> > In fact I write this function
> > 
> > double roots[2];
> > Nroots = quadratic_roots(a, b, c, roots);
> > if(Nroots == 2)
> 
> in present c i would do it
> 
> doubles root = quadratic_roots(a, b, c);
> 
> where struct doubles {double* beg; double* end; };
> (more suuitable for longer list but still)
> pointing to static inner area of quadratic_roots
> 9one need to remember that it can be rewritten but 
> in reality coder probably handle it with not much
> trouble)

one could also consider 

 quadratic_roots(a, b, c);
 
 if(quadratic_roots.n==0) printf("\nno roots");
 if(quadratic_roots.n==1) printf("\nr1 = %f", quadratic_roots.r1 );
 if(quadratic_roots.n==2) printf("\nr1 = %f r2 = %f", quadratic_roots.r1, quadratic_roots.r2 );

this is acces to inner statics, my other old invention (already 10 years or so) - maybe this way it would be slightly faster, im not sure

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

#99153

W dniu wtorek, 13 grudnia 2016 00:58:30 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 13 grudnia 2016 00:07:05 UTC+1 użytkownik Malcolm McLean napisał:
> > On Monday, December 12, 2016 at 10:01:49 PM UTC, Keith Thompson wrote:
> > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> > >
> > > In any case, the convention I mentioned (functions that return a status
> > > indicator) was just one example of where unary & would commonly be used.
> > > There are plenty of others.  I suspect your code is atypical.
> > >
> > I haven't done a count, but whilst I've certainly seen the convention
> > that the return type is always a success / fail error flag, it's
> > not terribly common.
> > 
> > My code doesn't need it. Because I always separate out functions
> > ("Malcolm-functions") from IO. Malcolm functions cannot fail,
> > unless they run out of memory, and only a minority need to allocate
> > memory (the constructor / destructor pattern is common, but
> > then out of memory is indicated by the constructor returning a null
> > pointer). Of the minority that allocate memory, most can't fail
> > in normal use on functioning desktop systems because they don't 
> > ask for enough memory - the OS will kick up a fuss long before
> > the function asks for and is refused the last few hundred bytes.
> > 
> > So the use of error flags is very limited. If you need an error
> > flag, it's often better to demand that caller supply you with a
> > workspace buffer instead. That frees up the return value for its
> > natural use in a function that queries or calculates something.
> > 
> > If I was designing C from scratch I would allow syntax like
> > 
> > r1, r2 = quadratic_roots(a, b, c);
> > if(!isnan(r1) && !isnan(r2)) 
> > 
> > 
> 
> here incidentally it would be more logical to get something like 
> 
> double[] root = quadratic_roots(a, b, c); 
> 
> //where root is full array i mean also denotes .end 
> or .length information 
> (physical realisation could involve hand managing 
> of stacks 
> 
> so it could be in reality 
> 
> stack(3) double[] root = quadratic_roots(a, b, c); 
> 
> or other)
> 
> > In fact I write this function
> > 
> > double roots[2];
> > Nroots = quadratic_roots(a, b, c, roots);
> > if(Nroots == 2)
> 
> in present c i would do it
> 
> doubles root = quadratic_roots(a, b, c);
> 
> where struct doubles {double* beg; double* end; };
> (more suuitable for longer list but still)
> pointing to static inner area of quadratic_roots
> 9one need to remember that it can be rewritten but 
> in reality coder probably handle it with not much
> trouble)

one could also consider 

 quadratic_roots(a, b, c);
 
 if(quadratic_roots.n==0) printf("\nno roots");
 if(quadratic_roots.n==1) printf("\nr1 = %f", quadratic_roots.r1 );
 if(quadratic_roots.n==2) printf("\nr1 = %f r2 = %f", quadratic_roots.r1, quadratic_roots.r2 );

this is acces to inner statics, my other old invention (already 10 years or so) - maybe this way it would be slightly faster, im not sure

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

#99157

W dniu wtorek, 13 grudnia 2016 00:58:30 UTC+1 użytkownik fir napisał:
> 
> in present c i would do it
> 
> doubles root = quadratic_roots(a, b, c);
> 
> where struct doubles {double* beg; double* end; };
> (more suuitable for longer list but still)

this is application of the chunk idea to a bit different domain than pure strings  (i was not sayin on this before 
(nor much thinking on this too) so maybe worth mentioning 
- obvious cases when you need fiond something and biuld a list or so

typedef  struct {  int* beg; int* end; }   ints;

ints list = find_near_ships(int who, float dist);


where internal ram of find_near_ships could be static of size of max contained ships att all, or internally reallocked on precalculations (this way precalculation steps would slow down things slightly, or one could do 
few lines more to grow reallock pool only on overflow) 
- i somewhat tested it all and may ack that it works quite well and is quite handy too, didint noticed any trouble 
as for thiose tests

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

#99505

> 
> ints list = find_near_ships(int who, float dist);
> 
> 

BTw it seems that "ints a" (for a type full array of int)  looks better than "int a[]" or "int[] a" - that may maybe suggest that "[]" in typenames was mistake/wrong decision
and for examle "int array a;" and "typedef int array ints;" ints a;" would look better (for some cases there would be need to provide size but for some not 

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

#99510

W dniu czwartek, 15 grudnia 2016 16:30:55 UTC+1 użytkownik fir napisał:
> > 
> > ints list = find_near_ships(int who, float dist);
> > 
> > 
> 
> BTw it seems that "ints a" (for a type full array of int)  looks better than "int a[]" or "int[] a" - that may maybe suggest that "[]" in typenames was mistake/wrong decision
> and for examle "int array a;" and "typedef int array ints;" ints a;" would look better (for some cases there would be need to provide size but for some not

it seems sometimes operator "overloading" is good but sometimes it seems bad and here this overload of []
seems bad to me, tight now even "int a[10]" or "int[10] a"
somewhat seem to be bad to me, even "int(10) a" seems
to be a bit better right now - though this is a subtle thing

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

#99512

W dniu czwartek, 15 grudnia 2016 16:56:26 UTC+1 użytkownik fir napisał:
> W dniu czwartek, 15 grudnia 2016 16:30:55 UTC+1 użytkownik fir napisał:
> > > 
> > > ints list = find_near_ships(int who, float dist);
> > > 
> > > 
> > 
> > BTw it seems that "ints a" (for a type full array of int)  looks better than "int a[]" or "int[] a" - that may maybe suggest that "[]" in typenames was mistake/wrong decision
> > and for examle "int array a;" and "typedef int array ints;" ints a;" would look better (for some cases there would be need to provide size but for some not
> 
> it seems sometimes operator "overloading" is good but sometimes it seems bad and here this overload of []
> seems bad to me, tight now even "int a[10]" or "int[10] a"
> somewhat seem to be bad to me, even "int(10) a" seems
> to be a bit better right now - though this is a subtle thing

yet still thinking if variable initialisation should not go 
(maybe optionally) in such syntax

int a(1), b(10), c(12); //int a=1, b=10, c=12;

this is somewhat more logical and maybe even far more logical

if so here

int(10) a,b,c; could mean a,b,c are ints initialised to 10
and for array it would need

int arrray(10) a; //array of 10 uninitialised ints
or
(int arrray 10) a;

ot typedef int array ints;

ints(10) a;
ints a;

//some notes for loops 

for int i(0 to 10)  a[i] = i; 
for int i(0,1,2,5,10, 100, 102)  a[n] = i; //?

(sobject to form later)

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

#99101

"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message 
news:96650663-827e-4f89-b78f-7b42a2516ef3@googlegroups.com...
> On Sunday, December 11, 2016 at 9:42:45 PM UTC, Bill Cuningham wrote:
>> I have notice over time, and the last few days I have been thinking
>> about this in particular. scanf's design. It wants the value of the
>> address a pointer points to. Hum now I notice many functions want
>> a pointer's address. But not so many an address pointed at.
>>
> No, it's rare. Normally we pass in values, either directly or via
> arrays, and get the results back either in the function's return
> type or in a buffer.
> So normally pointers are named variables that point to buffers
> of several values.
>
>
> But scanf is a bit unusual in that it returns a flexible number of
> values of flexible type. So you see the & operator used heavily.
> It's relatively rare to see the & operator used in most code.

In the manual it speaks of "pointer arguments". Now a dumb ass like me isn't 
going to be too sure of what that means. And it takes scanf(const char 
*format,...) and the ellipsis. Variable arguments.

    I know I am responding to you Malcom but this is for anyone to answer. 
Is '&' not always used? it's all I've seen used. Very useful function.

Bill

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

#99118

"Bill Cunningham" <nospam@nspam.invalid> writes:
> "Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message 
> news:96650663-827e-4f89-b78f-7b42a2516ef3@googlegroups.com...
[...]
>> But scanf is a bit unusual in that it returns a flexible number of
>> values of flexible type. So you see the & operator used heavily.
>> It's relatively rare to see the & operator used in most code.
>
> In the manual it speaks of "pointer arguments". Now a dumb ass like me isn't 
> going to be too sure of what that means. And it takes scanf(const char 
> *format,...) and the ellipsis. Variable arguments.
>
>     I know I am responding to you Malcom but this is for anyone to answer. 
> Is '&' not always used? it's all I've seen used. Very useful function.

Most scanf format specifies require a corresponding argument of some
specific pointer type.  Let's say it's FOO* (where FOO could be char,
int, double, or whatever).  One way to obtain the required value of type
FOO* is to apply the unary & operator to the name of an object of type
FOO.  There are other ways that don't require the use of unary &.

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

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

csiph-web