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

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

A postfix pointer deference

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

Contents

  A postfix pointer deference luser droog <luser.droog@gmail.com> - 2016-11-03 22:43 -0700
    Re: A postfix pointer deference fir <profesor.fir@gmail.com> - 2016-11-04 02:09 -0700
      Re: A postfix pointer deference fir <profesor.fir@gmail.com> - 2016-11-04 02:22 -0700
    Re: A postfix pointer deference Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-04 10:36 +0000
      Re: A postfix pointer deference luser droog <luser.droog@gmail.com> - 2016-11-04 08:53 -0700
        Re: A postfix pointer deference Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-04 16:44 +0000

#95728 — A postfix pointer deference

#define REF [0]

char *s = "hello";
for(int i=0,n=strlen(s); i<n; i++)
    putchar(s++ REF);

--  
don't dream it
be it

[toc] | [next] | [standalone]

#95732

W dniu piątek, 4 listopada 2016 06:43:46 UTC+1 użytkownik luser droog napisał:
> #define REF [0]
> 
> char *s = "hello";
> for(int i=0,n=strlen(s); i<n; i++)
>     putchar(s++ REF);
> 

what else could be said to this postfix dereference things
(i write here as when threads reach about 200 it loads to slowly
in google groups)

if some got

int*** p;

then we talk about 3 pointers (p, *p, **p) and value, (***p)
from longer time i considering putting convence where p would 
mean the final value [form some reasons i takled before, mosty, you usually need a quick and convenient way of using final value even if you use pointers]

((
more i even consider an idea of skiping all ** to get to value even in more
complex cases like

int**[]*[]* p;
 ))

though this convention bring some troubles and maybe may need that though if type syntax was defined as provided accas syntax maybe still would have
to be redefined..

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

#95733

W dniu piątek, 4 listopada 2016 10:09:41 UTC+1 użytkownik fir napisał:
> W dniu piątek, 4 listopada 2016 06:43:46 UTC+1 użytkownik luser droog napisał:
> > #define REF [0]
> > 
> > char *s = "hello";
> > for(int i=0,n=strlen(s); i<n; i++)
> >     putchar(s++ REF);
> > 
> 
> what else could be said to this postfix dereference things
> (i write here as when threads reach about 200 it loads to slowly
> in google groups)
> 
> if some got
> 
> int*** p;
> 
> then we talk about 3 pointers (p, *p, **p) and value, (***p)
> from longer time i considering putting convence where p would 
> mean the final value [form some reasons i takled before, mosty, you usually need a quick and convenient way of using final value even if you use pointers]
> 
> ((
> more i even consider an idea of skiping all ** to get to value even in more
> complex cases like
> 
> int**[]*[]* p;
>  ))
> 
> though this convention bring some troubles and maybe may need that though if type syntax was defined as provided accas syntax maybe still would have
> to be redefined..

it may be little sad (as for me it is wuite not a firs time ehene some case that seem problemless after a while seem problematic again) butat least some new small idee appear for fun: one could consider both prefix and postfix conventions both working diofferent way p* would mean for example outer pointer in sequence when where *p could mean iner pointer in sequence
(same with arrays a[] []a ) - though i write it as fun not for real consideration yet

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

#95735

luser droog <luser.droog@gmail.com> writes:

> #define REF [0]
>
> char *s = "hello";
> for(int i=0,n=strlen(s); i<n; i++)
>     putchar(s++ REF);

Why?  The usual idiom is *s++ and the whole loop would, most likely, not
be written using a counter:

  while (*s) putchar(*s++);

(I'm sure the putchar is just an example otherwise I'd suggest
fputs(s, stdout);)

Also, I'm not sure how the macro is helping.  Is the whole thing
intended to be a bit mysterious?

-- 
Ben.

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

#95757

On Friday, November 4, 2016 at 5:36:31 AM UTC-5, Ben Bacarisse wrote:
> luser droog <luser.droog@gmail.com> writes:
> 
> > #define REF [0]
> >
> > char *s = "hello";
> > for(int i=0,n=strlen(s); i<n; i++)
> >     putchar(s++ REF);
> 
> Why?  The usual idiom is *s++ and the whole loop would, most likely, not
> be written using a counter:
> 
>   while (*s) putchar(*s++);
> 
> (I'm sure the putchar is just an example otherwise I'd suggest
> fputs(s, stdout);)
> 
> Also, I'm not sure how the macro is helping.  Is the whole thing
> intended to be a bit mysterious?

In another thread there was a lot of talk about needing a postfix 
deref operator like Pascal. I just wanted to point out (without 
directly engaging anyone in that thread) that we already have one.

The macro just kinda wrote itself. I had no specific plan requiring
it. Without it, the message could well have been just the 3 characters
"[0]".

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

#95766

luser droog <luser.droog@gmail.com> writes:

> On Friday, November 4, 2016 at 5:36:31 AM UTC-5, Ben Bacarisse wrote:
>> luser droog <luser.droog@gmail.com> writes:
>> 
>> > #define REF [0]
>> >
>> > char *s = "hello";
>> > for(int i=0,n=strlen(s); i<n; i++)
>> >     putchar(s++ REF);
>> 
>> Why?  The usual idiom is *s++ and the whole loop would, most likely, not
>> be written using a counter:
>> 
>>   while (*s) putchar(*s++);
>> 
>> (I'm sure the putchar is just an example otherwise I'd suggest
>> fputs(s, stdout);)
>> 
>> Also, I'm not sure how the macro is helping.  Is the whole thing
>> intended to be a bit mysterious?
>
> In another thread there was a lot of talk about needing a postfix 
> deref operator like Pascal. I just wanted to point out (without 
> directly engaging anyone in that thread) that we already have one.

Ah, I see.  Yes, C almost has one, but since BartC dislikes the fact
that, in some situations, * needs ()s he's unlikely to want to use [0].

I say "almost" because there is a corner case where *E is permitted but
E[0] is not: &*E is a no-op (other than checking the type of E) but
&E[0] requires that E+0 is permitted, and that fails for incomplete
types even though the result is surely obvious.

-- 
Ben.

[toc] | [prev] | [standalone]

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

csiph-web