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

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

CAlive and char* p1, p2 --vs-- char *p1, p2

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

Contents

  CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 19:40 -0700
    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-10-30 19:50 -0700
      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 19:56 -0700
        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-10-31 13:00 -0700
    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 11:23 +0000
      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 07:45 -0700
        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 15:02 +0000
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 10:52 -0700
            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 20:01 +0000
              Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 13:51 -0700
                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 21:43 +0000
                  Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 17:04 -0700
                    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 01:17 +0000
                      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 19:20 -0700
                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-10-31 16:02 -0700
                  Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 17:06 -0700
    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Bartc <bc@freeuk.com> - 2015-10-31 13:54 +0000
      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 07:52 -0700
        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Richard Damon <Richard@Damon-Family.org> - 2015-10-31 11:16 -0400
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 10:08 -0700
            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Richard Damon <Richard@Damon-Family.org> - 2015-10-31 14:00 -0400
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-31 17:41 +0000
            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 11:03 -0700
              Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 20:04 +0000
                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 13:56 -0700
                  Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 21:49 +0000
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-31 12:20 -0700
    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-01 04:17 +0000
      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Chad <cdalten@gmail.com> - 2015-11-01 00:02 -0700
    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ian Collins <ian-news@hotmail.com> - 2015-11-01 20:30 +1300
    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 David Brown <david.brown@hesbynett.no> - 2015-11-01 23:48 +0100
      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 16:54 -0800
        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 David Brown <david.brown@hesbynett.no> - 2015-11-02 02:05 +0100
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 17:12 -0800
            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 17:23 -0800
      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-02 02:28 -0800
        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:57 +0000
        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 08:11 -0800
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Gareth Owen <gwowen@gmail.com> - 2015-11-10 18:34 +0000
            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 10:55 -0800
          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-10 21:08 -0800
            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 05:14 -0800
              Re: CAlive and char* p1, p2 --vs-- char *p1, p2 BartC <bc@freeuk.com> - 2015-11-12 13:31 +0000
                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 06:21 -0800
              Re: CAlive and char* p1, p2 --vs-- char *p1, p2 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-12 14:29 +0000
                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 06:36 -0800
                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-11-12 06:45 -0800
                  Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 06:48 -0800
                    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 David Brown <david.brown@hesbynett.no> - 2015-11-12 15:59 +0100
                      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 07:03 -0800
                      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-12 16:21 +0000
                        Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-11-12 09:09 -0800
                          Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 09:16 -0800
                            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 09:46 -0800
                            Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-11-12 09:51 -0800
                              Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 10:01 -0800
                                Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-11-12 11:10 -0800
                                  Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 11:31 -0800
                                    Re: CAlive and char* p1, p2 --vs-- char *p1, p2 supercat@casperkitty.com - 2015-11-12 12:14 -0800
                                      Re: CAlive and char* p1, p2 --vs-- char *p1, p2 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 12:18 -0800

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

#74391 — CAlive and char* p1, p2 --vs-- char *p1, p2

What a difference a whitespace makes!

-----
CAlive makes pointer declarations more logical.

    (1)  If the * is located directly beside the type (no whitespaces
         between the type and *), it defines every item thereafter to
         be a pointer to that type.

    (2)  If, however, the * is located at least one whitespace away from
         the type, the * only applies to the first variable, and then
         must be explicitly applied to any other variables that need to
         be pointers.

For example:

    char*   p1, p2, p3;
    // p1, p2, and p3 are all char* variables

    char    *p4, p5, *p6;
    // p4 and p6 are char*, but p5 is just char

-----
This feature was included in deference to the D programming language and
Walter Bright who, back in 2006, unknowingly first introduced me to the
idea that pointer symbols should always be next to the type for pointer
declarations.

Thank you, Walter, for opening my eyes.

Best regards,
Rick C. Hodgin

[toc] | [next] | [standalone]

#74392

I liked:

  Var P1,P2: ^Byte;

Common Pascal dialects could accommodate any combination of arrays, pointers,
and other types in ways that made things a lot clearer than C.

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

#74393

On Friday, October 30, 2015 at 10:50:49 PM UTC-4, supe...@casperkitty.com wrote:
> I liked:
> 
>   Var P1,P2: ^Byte;

In CAlive:

    char* P1, P2;

> Common Pascal dialects could accommodate any combination of arrays, pointers,
> and other types in ways that made things a lot clearer than C.

Best regards,
Rick C. Hodgin

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

#74481

On Friday, October 30, 2015 at 9:56:40 PM UTC-5, Rick C. Hodgin wrote:
> On Friday, October 30, 2015 at 10:50:49 PM UTC-4, supercat wrote:
> > I liked:
> > 
> >   Var P1,P2: ^Byte;
> 
> In CAlive:
> 
>     char* P1, P2;

I recognize that's your intention.  I would argue against using that syntax
on the principle that code which looks like an existing language construct
should act exactly like the existing language construct, and code which does
not act exactly like an existing language construct should avoid looking like
one.

If you want to keep the general style of the C syntax, I would suggest that
you add a rule requiring that all variables declared in a single declaration
must have the same type, and also allow the use of a : to make clear that
everything to the left applies to everything to the right.  Thus, the above
declaration could be written as either

    char *P1, *P2;  // With any combination of whitespace
    char* : P1, P2; // Likewise

You could use other punctuation if you prefer; the point would be to pick
something which could not be mistaken for C code with a different meaning.

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

#74421

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>
> CAlive makes pointer declarations more logical.
>
>     (1)  If the * is located directly beside the type (no whitespaces
>          between the type and *), it defines every item thereafter to
>          be a pointer to that type.
>
>     (2)  If, however, the * is located at least one whitespace away from
>          the type, the * only applies to the first variable, and then
>          must be explicitly applied to any other variables that need to
>          be pointers.
>
> For example:
>
>     char*   p1, p2, p3;
>     // p1, p2, and p3 are all char* variables
>
>     char    *p4, p5, *p6;
>     // p4 and p6 are char*, but p5 is just char

What will the following mean:

  char* *p, q;
  char ** p, q;
  char *const* p, q;

Incredibly, you've seized the chance to make C's baroque type
declarations even more confusing than they already are and, against the
odds, you've done it.

At this point I'd suggest that we are being had, but experience of
Usenet suggests that there's usually another explanation.

<snip>
-- 
Ben.

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

#74434

On Saturday, October 31, 2015 at 7:23:55 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> <snip>
> > CAlive makes pointer declarations more logical.
> >
> >     (1)  If the * is located directly beside the type (no whitespaces
> >          between the type and *), it defines every item thereafter to
> >          be a pointer to that type.
> >
> >     (2)  If, however, the * is located at least one whitespace away from
> >          the type, the * only applies to the first variable, and then
> >          must be explicitly applied to any other variables that need to
> >          be pointers.
> >
> > For example:
> >
> >     char*   p1, p2, p3;
> >     // p1, p2, and p3 are all char* variables
> >
> >     char    *p4, p5, *p6;
> >     // p4 and p6 are char*, but p5 is just char
> 
> What will the following mean:
> 
> 01:  char* *p, q;
> 02:  char ** p, q;
> 03:  char *const* p, q;

01:  p is char**, q is char*.
02:  p is char**, q is char.
03:  Syntax error at ^

> Incredibly, you've seized the chance to make C's baroque type
> declarations even more confusing than they already are and, against the
> odds, you've done it.

Saying something is a particular way doesn't make it so.

> At this point I'd suggest that we are being had, but experience of
> Usenet suggests that there's usually another explanation.

It's a good idea.  The * placement should mean and not be an arbitrarily
placeable quantity.

Best regards,
Rick C. Hodgin

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

#74436

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Saturday, October 31, 2015 at 7:23:55 AM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> <snip>
>> > CAlive makes pointer declarations more logical.
>> >
>> >     (1)  If the * is located directly beside the type (no whitespaces
>> >          between the type and *), it defines every item thereafter to
>> >          be a pointer to that type.
>> >
>> >     (2)  If, however, the * is located at least one whitespace away from
>> >          the type, the * only applies to the first variable, and then
>> >          must be explicitly applied to any other variables that need to
>> >          be pointers.
>> >
>> > For example:
>> >
>> >     char*   p1, p2, p3;
>> >     // p1, p2, and p3 are all char* variables
>> >
>> >     char    *p4, p5, *p6;
>> >     // p4 and p6 are char*, but p5 is just char
>> 
>> What will the following mean:
>> 
>> 01:  char* *p, q;
>> 02:  char ** p, q;
>> 03:  char *const* p, q;
>
> 01:  p is char**, q is char*.
> 02:  p is char**, q is char.
> 03:  Syntax error at ^

Why the syntax error?

>> Incredibly, you've seized the chance to make C's baroque type
>> declarations even more confusing than they already are and, against the
>> odds, you've done it.
>
> Saying something is a particular way doesn't make it so.

No, of course not.  Nor does not giving a reasoned explanation mean that
a statement is wrong.  In this case it simply means that I know you are
immune to reason (or maybe you just pretend to be), and I am conserving
effort.

<snip>
-- 
Ben.

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

#74457

On Saturday, October 31, 2015 at 11:02:19 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Saturday, October 31, 2015 at 7:23:55 AM UTC-4, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> <snip>
> >> > CAlive makes pointer declarations more logical.
> >> >
> >> >     (1)  If the * is located directly beside the type (no whitespaces
> >> >          between the type and *), it defines every item thereafter to
> >> >          be a pointer to that type.
> >> >
> >> >     (2)  If, however, the * is located at least one whitespace away from
> >> >          the type, the * only applies to the first variable, and then
> >> >          must be explicitly applied to any other variables that need to
> >> >          be pointers.
> >> >
> >> > For example:
> >> >
> >> >     char*   p1, p2, p3;
> >> >     // p1, p2, and p3 are all char* variables
> >> >
> >> >     char    *p4, p5, *p6;
> >> >     // p4 and p6 are char*, but p5 is just char
> >> 
> >> What will the following mean:
> >> 
> >> 01:  char* *p, q;
> >> 02:  char ** p, q;
> >> 03:  char *const* p, q;
> >
> > 01:  p is char**, q is char*.
> > 02:  p is char**, q is char.
> > 03:  Syntax error
> 
> Why the syntax error?

The CAlive parser would see the source code sequence:

    char *const* p, q;

Broken out to:

    [char][whitespace][*][const][*][whitespace][p][,][whitespace][q][;]

Reduced to:  [char][*][const][*][p][,][q]
Reduced to:  [char][*const]<!--error-->[*][p][,][q]

It would not see a comma between [*const] and [*], and would attach
the syntax error to the line and component, and it would stop parsing
at that point, and insert an inquiry for the statement.

Best regards,
Rick C. Hodgin

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

#74482

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Saturday, October 31, 2015 at 11:02:19 AM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> 
>> > On Saturday, October 31, 2015 at 7:23:55 AM UTC-4, Ben Bacarisse wrote:
<snip>
>> >> What will the following mean:
<snip>
>> >> 03:  char *const* p, q;
<snip>
>> > 03:  Syntax error
>> 
>> Why the syntax error?
>
> The CAlive parser would see the source code sequence:
>
>     char *const* p, q;
>
> Broken out to:
>
>     [char][whitespace][*][const][*][whitespace][p][,][whitespace][q][;]
>
> Reduced to:  [char][*][const][*][p][,][q]
> Reduced to:  [char][*const]<!--error-->[*][p][,][q]
>
> It would not see a comma between [*const] and [*], and would attach
> the syntax error to the line and component, and it would stop parsing
> at that point, and insert an inquiry for the statement.

I think you missed my point.  My question was *why* you decided that
this would be a syntax error.  In C it declares p to be pointer to a
const pointer to char.

-- 
Ben.

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

#74494

On Saturday, October 31, 2015 at 4:01:37 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Saturday, October 31, 2015 at 11:02:19 AM UTC-4, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> 
> >> > On Saturday, October 31, 2015 at 7:23:55 AM UTC-4, Ben Bacarisse wrote:
> <snip>
> >> >> What will the following mean:
> <snip>
> >> >> 03:  char *const* p, q;
> <snip>
> >> > 03:  Syntax error
> >> 
> >> Why the syntax error?
> >
> > The CAlive parser would see the source code sequence:
> >
> >     char *const* p, q;
> >
> > Broken out to:
> >
> >     [char][whitespace][*][const][*][whitespace][p][,][whitespace][q][;]
> >
> > Reduced to:  [char][*][const][*][p][,][q]
> > Reduced to:  [char][*const]<!--error-->[*][p][,][q]
> >
> > It would not see a comma between [*const] and [*], and would attach
> > the syntax error to the line and component, and it would stop parsing
> > at that point, and insert an inquiry for the statement.
> 
> I think you missed my point.  My question was *why* you decided that
> this would be a syntax error.  In C it declares p to be pointer to a
> const pointer to char.

CAlive does not support crossing types in a single step like that, as
with one pointer.

CAlive allows pointers, and pointer-to-pointers of the same type, but
in order to cross a type it must go through something, such as a class,
angel, or struct, which serves to document the operation taking place,
so as to indicate clearly what it's doing (by its associated name), and
why the subsequent layers of data are required to get there.

-----
If you'll remember, many moons ago...

We've had this discussion before.  I made the comment that in all of
my programming experience I've never seen the need to go further than
pointers, and pointers-to-pointers.  You and several others replied
with examples asking me how I would do this or that.  I demonstrated
my replies to which there was disagreement, stating it was better to
create some kind of convoluted type that is not only hard on the eyes,
but must also be de-referenced half a dozen times to actually reach
data.  Well, no thank you.  Not on my watch.  :-)

Best regards,
Rick C. Hodgin

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

#74501

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Saturday, October 31, 2015 at 4:01:37 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> 
>> > On Saturday, October 31, 2015 at 11:02:19 AM UTC-4, Ben Bacarisse wrote:
>> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> >> 
>> >> > On Saturday, October 31, 2015 at 7:23:55 AM UTC-4, Ben Bacarisse wrote:
>> <snip>
>> >> >> What will the following mean:
>> <snip>
>> >> >> 03:  char *const* p, q;
>> <snip>
>> >> > 03:  Syntax error
>> >> 
>> >> Why the syntax error?
>> >
>> > The CAlive parser would see the source code sequence:
>> >
>> >     char *const* p, q;
>> >
>> > Broken out to:
>> >
>> >     [char][whitespace][*][const][*][whitespace][p][,][whitespace][q][;]
>> >
>> > Reduced to:  [char][*][const][*][p][,][q]
>> > Reduced to:  [char][*const]<!--error-->[*][p][,][q]
>> >
>> > It would not see a comma between [*const] and [*], and would attach
>> > the syntax error to the line and component, and it would stop parsing
>> > at that point, and insert an inquiry for the statement.
>> 
>> I think you missed my point.  My question was *why* you decided that
>> this would be a syntax error.  In C it declares p to be pointer to a
>> const pointer to char.
>
> CAlive does not support crossing types in a single step like that, as
> with one pointer.
>
> CAlive allows pointers, and pointer-to-pointers of the same type, but
> in order to cross a type it must go through something, such as a class,
> angel, or struct, which serves to document the operation taking place,
> so as to indicate clearly what it's doing (by its associated name), and
> why the subsequent layers of data are required to get there.

OK.  In short you've decided that CAlive can't directly declare a
pointer to a pointer that is const.  That pushes the question to why you
decided this, but let's not go down that rabbit hole.

> If you'll remember, many moons ago...
>
> We've had this discussion before.  I made the comment that in all of
> my programming experience I've never seen the need to go further than
> pointers, and pointers-to-pointers.

The type I asked about is a pointer to a pointer.

<snip>
-- 
Ben.

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

#74508

On Saturday, October 31, 2015 at 5:43:44 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Saturday, October 31, 2015 at 4:01:37 PM UTC-4, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> 
> >> > On Saturday, October 31, 2015 at 11:02:19 AM UTC-4, Ben Bacarisse wrote:
> >> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> >> 
> >> >> > On Saturday, October 31, 2015 at 7:23:55 AM UTC-4, Ben Bacarisse wrote:
> >> <snip>
> >> >> >> What will the following mean:
> >> <snip>
> >> >> >> 03:  char *const* p, q;
> >> <snip>
> >> >> > 03:  Syntax error
> >> >> 
> >> >> Why the syntax error?
> >> >
> >> > The CAlive parser would see the source code sequence:
> >> >
> >> >     char *const* p, q;
> >> >
> >> > Broken out to:
> >> >
> >> >     [char][whitespace][*][const][*][whitespace][p][,][whitespace][q][;]
> >> >
> >> > Reduced to:  [char][*][const][*][p][,][q]
> >> > Reduced to:  [char][*const]<!--error-->[*][p][,][q]
> >> >
> >> > It would not see a comma between [*const] and [*], and would attach
> >> > the syntax error to the line and component, and it would stop parsing
> >> > at that point, and insert an inquiry for the statement.
> >> 
> >> I think you missed my point.  My question was *why* you decided that
> >> this would be a syntax error.  In C it declares p to be pointer to a
> >> const pointer to char.
> >
> > CAlive does not support crossing types in a single step like that, as
> > with one pointer.
> >
> > CAlive allows pointers, and pointer-to-pointers of the same type, but
> > in order to cross a type it must go through something, such as a class,
> > angel, or struct, which serves to document the operation taking place,
> > so as to indicate clearly what it's doing (by its associated name), and
> > why the subsequent layers of data are required to get there.
> 
> OK.  In short you've decided that CAlive can't directly declare a
> pointer to a pointer that is const.  That pushes the question to why you
> decided this, but let's not go down that rabbit hole.

CAlive allows:

    const char** p;

I was under the impression "char* const* p" was a char pointer to a
constant pointer, meaning the value of p could not change, not the
thing p was pointing to.

> > If you'll remember, many moons ago...
> >
> > We've had this discussion before.  I made the comment that in all of
> > my programming experience I've never seen the need to go further than
> > pointers, and pointers-to-pointers.
> 
> The type I asked about is a pointer to a pointer.

Best regards,
Rick C. Hodgin

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

#74513

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Saturday, October 31, 2015 at 5:43:44 PM UTC-4, Ben Bacarisse wrote:
<snip>
>> >> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> >> >> 
>> >> >> > On Saturday, October 31, 2015 at 7:23:55 AM UTC-4, Ben Bacarisse wrote:
>> >> <snip>
>> >> >> >> What will the following mean:
>> >> <snip>
>> >> >> >> 03:  char *const* p, q;
>> >> <snip>
>> >> >> > 03:  Syntax error
<snip>
>> OK.  In short you've decided that CAlive can't directly declare a
>> pointer to a pointer that is const.  That pushes the question to why you
>> decided this, but let's not go down that rabbit hole.
>
> CAlive allows:
>
>     const char** p;
>
> I was under the impression "char* const* p" was a char pointer to a
> constant pointer, meaning the value of p could not change, not the
> thing p was pointing to.

No, that's not what it is.  Did you not say that you intend to support
C?  If so you will need to know it's type rules and you'll need to allow
valid C declarations.

<snip>
-- 
Ben.

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

#74515

On Saturday, October 31, 2015 at 9:17:17 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Saturday, October 31, 2015 at 5:43:44 PM UTC-4, Ben Bacarisse wrote:
> <snip>
> >> >> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> >> >> 
> >> >> >> > On Saturday, October 31, 2015 at 7:23:55 AM UTC-4, Ben Bacarisse wrote:
> >> >> <snip>
> >> >> >> >> What will the following mean:
> >> >> <snip>
> >> >> >> >> 03:  char *const* p, q;
> >> >> <snip>
> >> >> >> > 03:  Syntax error
> <snip>
> >> OK.  In short you've decided that CAlive can't directly declare a
> >> pointer to a pointer that is const.  That pushes the question to why you
> >> decided this, but let's not go down that rabbit hole.
> >
> > CAlive allows:
> >
> >     const char** p;
> >
> > I was under the impression "char* const* p" was a char pointer to a
> > constant pointer, meaning the value of p could not change, not the
> > thing p was pointing to.
> 
> No, that's not what it is.  Did you not say that you intend to support
> C?  If so you will need to know it's type rules and you'll need to allow
> valid C declarations.

All in good time, Ben.  I do not code like that (char *const* p"), so
it's foreign to me and my understanding.  I'm sure there are a few
hundred other things which are C/C++ specific quirks that I don't know
as well.

When I get to the point where I'm adding -c90 and -c99 support, I'll
fix everything up.  For now, I'm focused on CAlive.  It provides support
for all of the concepts I've ever used in C/C++ programming, and adding
additional abilities should be fairly straight-forward as it is a
flexible framework being designed from inception to support front-ends
for compiling other languages.  All of the abilities RDC will expose
relate back to programming fundamentals.  If I don't understand it by
syntax, I likely do by concept, and it will eventually be accounted
for.  And if not, then it will be my loss.

Best regards,
Rick C. Hodgin

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

#74505

> "Rick C. Hodgin"  wrote in message 
> news:aef40968-6979-4aa4-84ef-485075c3187c@googlegroups.com...

> > On Saturday, October 31, 2015 at 4:01:37 PM UTC-4, Ben Bacarisse wrote:
[...]
> > I think you missed my point.  My question was *why* you decided that
> > this would be a syntax error.  In C it declares p to be pointer to a
> > const pointer to char.

> CAlive does not support crossing types in a single step like that, as
> with one pointer.

Why not?

>> 03:  char *const* p, q;

Is perfectly fine. Why call it "C"Alive when this declaration cannot be 
handled?

Humm...

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

#74509

On Saturday, October 31, 2015 at 7:03:25 PM UTC-4, Chris M. Thomasson wrote:
> > "Rick C. Hodgin"  wrote in message 
> > news:aef40968-6979-4aa4-84ef-485075c3187c@googlegroups.com...
> 
> > > On Saturday, October 31, 2015 at 4:01:37 PM UTC-4, Ben Bacarisse wrote:
> [...]
> > > I think you missed my point.  My question was *why* you decided that
> > > this would be a syntax error.  In C it declares p to be pointer to a
> > > const pointer to char.
> 
> > CAlive does not support crossing types in a single step like that, as
> > with one pointer.
> 
> Why not?

I think I was mistaken in understanding what "char* const* p" meant.

But, to answer your question, I don't want things more than a **
away from some fixed thing.  I don't want to create a complex type
that is multiple levels of things deep, and then use it that way.
I want things to point to things which point to things, each of
which convey context and help document the activity.

> >> 03:  char *const* p, q;
> 
> Is perfectly fine. Why call it "C"Alive when this declaration cannot be 
> handled?
> 
> Humm...

I could be defined as const char** p.

Best regards,
Rick C. Hodgin

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

#74432

On 31/10/2015 02:40, Rick C. Hodgin wrote:
> What a difference a whitespace makes!
>
> -----
> CAlive makes pointer declarations more logical.
>
>      (1)  If the * is located directly beside the type (no whitespaces
>           between the type and *), it defines every item thereafter to
>           be a pointer to that type.
>
>      (2)  If, however, the * is located at least one whitespace away from
>           the type, the * only applies to the first variable, and then
>           must be explicitly applied to any other variables that need to
>           be pointers.
>
> For example:
>
>      char*   p1, p2, p3;
>      // p1, p2, and p3 are all char* variables
>
>      char    *p4, p5, *p6;
>      // p4 and p6 are char*, but p5 is just char

Sorry, no. That's not going to work.

(1) is a good idea. Don't spoil it with a silly one.

>
> -----
> This feature was included in deference to the D programming language and
> Walter Bright who, back in 2006, unknowingly first introduced me to the
> idea that pointer symbols should always be next to the type for pointer
> declarations.

AFAIK D doesn't make white space significant as in your example (2), it 
works like your example (1):

  int* p, q ,r;

Here p, q, r are all pointers to int.

You can't mix pointers and non-pointers in the same declaration, or 
different levels of pointer. That was a bad idea even in C.

-- 
Bartc

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

#74435

On Saturday, October 31, 2015 at 9:54:31 AM UTC-4, Bart wrote:
> On 31/10/2015 02:40, Rick C. Hodgin wrote:
> > What a difference a whitespace makes!
> >
> > -----
> > CAlive makes pointer declarations more logical.
> >
> >      (1)  If the * is located directly beside the type (no whitespaces
> >           between the type and *), it defines every item thereafter to
> >           be a pointer to that type.
> >
> >      (2)  If, however, the * is located at least one whitespace away from
> >           the type, the * only applies to the first variable, and then
> >           must be explicitly applied to any other variables that need to
> >           be pointers.
> >
> > For example:
> >
> >      char*   p1, p2, p3;
> >      // p1, p2, and p3 are all char* variables
> >
> >      char    *p4, p5, *p6;
> >      // p4 and p6 are char*, but p5 is just char
> 
> Sorry, no. That's not going to work.
> 
> (1) is a good idea. Don't spoil it with a silly one.

I assume by silly one you mean (2).  It's how C/C++ work today.  And
whereas I think it is somewhat silly, it does make a modicum of sense.

> > -----
> > This feature was included in deference to the D programming language and
> > Walter Bright who, back in 2006, unknowingly first introduced me to the
> > idea that pointer symbols should always be next to the type for pointer
> > declarations.
> 
> AFAIK D doesn't make white space significant as in your example (2), it 
> works like your example (1):
> 
>   int* p, q ,r;
> 
> Here p, q, r are all pointers to int.

That's where I took the basic idea from.  In CAlive, if the * is touching,
the type then a type*, but if it's not touching the type, it's just a type,
with the * character modifying the first variable (as it is in C/C++ today).

> You can't mix pointers and non-pointers in the same declaration, or 
> different levels of pointer. That was a bad idea even in C.

I can do that.  And I am doing that.  I provides backward compatibility
with existing code, and is desirable in some cases.

My primary goal in adding this feature is to make the code clear.  The
* should be near the thing that's a pointer.  If it's near the type,
it's conveyed that way.  If it's near the variable, it's conveyed that
way.

Best regards,
Rick C. Hodgin

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

#74438

On 10/31/15 10:52 AM, Rick C. Hodgin wrote:
>
> My primary goal in adding this feature is to make the code clear.  The
> * should be near the thing that's a pointer.  If it's near the type,
> it's conveyed that way.  If it's near the variable, it's conveyed that
> way.
>
> Best regards,
> Rick C. Hodgin
>

Rick,
Can I ask if you have written the Grammar to handle this to see how 
complicated it is to implement? Or if you are going to skip some of the 
normal formal steps of design, as real parser to decode 'real' 
declarations (things with the full complexity of the language you are 
proposing)?

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

#74450

On Saturday, October 31, 2015 at 11:16:27 AM UTC-4, Richard Damon wrote:
> On 10/31/15 10:52 AM, Rick C. Hodgin wrote:
> >
> > My primary goal in adding this feature is to make the code clear.  The
> > * should be near the thing that's a pointer.  If it's near the type,
> > it's conveyed that way.  If it's near the variable, it's conveyed that
> > way.
> >
> > Best regards,
> > Rick C. Hodgin
> >
> 
> Rick,
> Can I ask if you have written the Grammar to handle this to see how 
> complicated it is to implement? Or if you are going to skip some of the 
> normal formal steps of design, as real parser to decode 'real' 
> declarations (things with the full complexity of the language you are 
> proposing)?

Ah, the age-old, "Do you still beat your wife?" style of question.

I'll answer your question, Richard Damon, in song:

    https://www.youtube.com/watch?v=TLs4MGTTXRU

...and in deference and acknowledgement to God, and of my sincere
internal drive and desire to give the Lord the best of what He
first gave me in all areas.

And to directly answer your question:  I have a plan.  I've poked and
prodded it in my mind, and have coded a portion of it, and so far it
bears up to scrutiny.  It just takes deep concentration to implement,
and with a regular full-time job, a two-hour commute, family and church
time ... it doesn't leave many contiguous hours for the deeper aspects
of development.  So, I've had to work around that.

Best regards,
Rick C. Hodgin

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

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

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

csiph-web