www.digitalmars.com         C & C++   DMDScript  

D - multiple declarations

reply "Walter" <walter digitalmars.com> writes:
I finally got around to addressing the problems of multiple declarations in
one statement.

    www.digitalmars.com/d/declaration.html
Feb 04 2002
next sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a3n5b2$20oo$1 digitaldaemon.com...

 I finally got around to addressing the problems of multiple declarations

 one statement.

     www.digitalmars.com/d/declaration.html

I like it. Ahem... Typo: "Declaration syntax generally reads left to right" ... "Arrays, when lexically next to each other, read right to left" "right" and "left" are switched, I believe. You know... the other right and the other left :) The thing with the arrays is nasty. But I only see two alternatives. For: x[0]; // is a int[5] x[0][0]; // Is the "first" element x[4][2]; // Is the "last" element We have: int[3][5] x; // Array of 5 arrays of 3 ints. int[3]*[5] x; // x is an array of 5 pointers to arrays of 3 ints which inverts the indices in the type specifier. Or inverting everything: [5][3]int x; // Array of 5 arrays of 3 ints. [5]*[3]int x; // x is an array of 5 pointers to arrays of 3 ints which deviates even more from C/C++. And talking about changing syntax, I'd consider: int(char)* x; // x is a pointer to a function taking a char argument // and returning an int int(char)*[] x; // x is an array of pointers to functions // taking a char argument and returning an int Salutaciones, JCAB
Feb 04 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Juan Carlos Arevalo Baeza wrote:

    which inverts the indices in the type specifier. Or inverting everything:

 [5][3]int x; // Array of 5 arrays of 3 ints.
 [5]*[3]int x; // x is an array of 5 pointers to arrays of 3 ints

This might actually be a good idea, but I'm going to modify it some. Make all of the declarations be around the type, but each marker goes on the side where you use it. Since the * and & operators go on the left, force *'s to be on the left; since array indexes must go on the right, force them to be there. Things always read right-to-left, and if you want otherwise, use parens: int x; // int *int x; // ptr to int **int x; // ptr to ptr to int int[] x; // array of ints (*int)[] x; // array of ptrs to int *int[] x; // ptr to array of ints int[3] x; // array of 3 ints int[3][5] x; // 3 arrays of 5 ints *int[3][5] x; // ptr to 3 arrays of 5 ints (*int[3])[5] x; // array of 5 ptrs to arrays of 3 ints Function pointers abandon the C syntax for the same paradigm. If you put the parens on the type instead of the variable, you can avoid C's abiguity between functions and function pointers. Perhaps, like class variables, you don't have to specify that it is a pointer - thus we have "function references" instead of "function pointers": int(char) x; // reference to a function taking char and returning int int(char)[5] x; // array of 5 references to functions taking char and returning int *int(char) x; // let's make this a SYNTAX ERROR, since 99% of programmers won't remember the spec anyway... (*int)(char) x; // reference to a function taking char and returning pointer to int *(int(char)) x; // ptr to reference to a function taking char and returning pointer to int int[5](char) x; // reference to a function taking char and returning array of 5 ints (int[5](char))[3] x; // array of 3 references to functions taking char and returning arrays of 5 ints -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Feb 06 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C615A5D.92D6B8F deming-os.org...

 *int x;        // ptr to int
 **int x;        // ptr to ptr to int

Not so bad. Still I'd prefer int*. Just a matter of personal taste, I believe.
 Function pointers abandon the C syntax for the same paradigm.  If you put

 parens on the type instead of the variable, you can avoid C's abiguity

 functions and function pointers.  Perhaps, like class variables, you don't

 specify that it is a pointer - thus we have "function references" instead

 "function pointers":

 int(char) x;    // reference to a function taking char and returning int
 int(char)[5] x;    // array of 5 references to functions taking char and

Agreed.
 *int(char) x;    // let's make this a SYNTAX ERROR, since 99% of

What's wrong with it?
Feb 06 2002
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Pavel Minayev wrote:

 *int(char) x;    // let's make this a SYNTAX ERROR, since 99% of

What's wrong with it?

My thought was that it would be so rarely used that very, very few programmers would know whether the line above is "ptr to a reference to a function returning int" or "reference to a function returning ptr to int". Thus, every time somebody uses the syntax, everybody will have to go look it up in the spec. IMHO, it would be easier to just say "this is a syntax error, you must use parentheses to clarify". -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Feb 06 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a3rrdo$306$1 digitaldaemon.com...
 Not so bad. Still I'd prefer int*. Just a matter of personal taste,
 I believe.

That's the trouble. I am just *so* used to the C style, it's hard to break away from it.
Feb 08 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a3rrdo$306$1 digitaldaemon.com...
 Not so bad. Still I'd prefer int*. Just a matter of personal taste,
 I believe.

That's the trouble. I am just *so* used to the C style, it's hard to break away from it.

I understand. But, IMHO, this is so much superior...it has automatic internal clarity and better handles most of the odd special cases that C and D struggle with. In particular, I am saddened by the mixing of right-hand and left-hand rules in the D spec...it's a cludge that will lead to massive coder confusion in the future. :( I don't mean this as any attack...it's just that I think that D will thrive only as much as it is easy to use. Mixed array and pointer declarations are not easy to use :( -- The Villagers are Online! http://villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Feb 09 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C65304F.B889FE3F deming-os.org...
 In particular, I am saddened by the mixing of right-hand and left-hand

 in the D spec...it's a cludge that will lead to massive coder confusion in

 future. :(  I don't mean this as any attack...it's just that I think that

 will thrive only as much as it is easy to use.  Mixed array and pointer
 declarations are not easy to use :(

Yes, it's a kludge, and I have misgivings about it too.
Feb 09 2002
parent reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Walter wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3C65304F.B889FE3F deming-os.org...
 In particular, I am saddened by the mixing of right-hand and left-hand

 in the D spec...it's a cludge that will lead to massive coder confusion in

 future. :(  I don't mean this as any attack...it's just that I think that

 will thrive only as much as it is easy to use.  Mixed array and pointer
 declarations are not easy to use :(

Yes, it's a kludge, and I have misgivings about it too.

May I second that? I believe elegant declaration of intricate data types and structures inevitably leads to simpler and more direct (and less error prone) programming. I recall with horrors the difficulty I've had in C creating just the oddball declaration I needed to make a very elegant algorithm simple to implement and optimally efficient at runtime. All too often, the declarations became too complex to write in "clean" C, forcing me to resort to cascaded typedefs and macros to make them even exist, much less work. I feel D should bend over backwards to make even the nastiest, most complex declaration completely unambiguous and, of vastly greater importance, as easy as possible to understand and use. Such beastly declarations are relatively rare, but when you need them, you typically also need clarity even more. The price of having to learn a new way to write such rare and complex declarations should be more than offset by the reduced error and hassle in creating and using them! Convoluted C declarations really feel more like torture than code. A kluge, just like the C preprocessor, designed to permit a slightly smaller compiler to be built. Is this something that should be carried "forward" in D? Want to see an extremely powerful declaration syntax? Look at APL. ;^) For a powerful but simple declaration syntax, look at PL1 or PL/M. -BobC
Feb 10 2002
parent reply "Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> writes:
"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3C6631AE.344B648B yahoo.com...

 May I second that?  I believe elegant declaration of intricate data types

 structures inevitably leads to simpler and more direct (and less error

 programming.

 Want to see an extremely powerful declaration syntax?  Look at APL.  ;^)

 a powerful but simple declaration syntax, look at PL1 or PL/M.

Or Pascal: ComplexVar: pointer to array[9] of pointer to array[5] of array[8] of pointer to string; Verbose, yes, but it was as simple and clear as I can think it to be. What I was proposing is this, only using the C++ style: *[9]*[5][8]*string ComplexVar; Salutaciones, JCAB http://www.JCABs-Rumblings.com
Feb 10 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> wrote in message
news:a46cqm$22mt$1 digitaldaemon.com...
    Verbose, yes, but it was as simple and clear as I can think it to be.
 What I was proposing is this, only using the C++ style:

 *[9]*[5][8]*string ComplexVar;

Your suggestion is excellent, I'm just not ready to give up the basic type being on the left. Call me an old curmudgeon <g>.
Feb 10 2002
next sibling parent reply "Serge K" <skarebo programmer.net> writes:
    Verbose, yes, but it was as simple and clear as I can think it to be.
 What I was proposing is this, only using the C++ style:

 *[9]*[5][8]*string ComplexVar;

Your suggestion is excellent, I'm just not ready to give up the basic type being on the left. Call me an old curmudgeon <g>.

Than how about my suggestion? ;-D (Well, maybe it's not the nicest one. But it's quite regular...) "Basic Type" [ arrays/pointers hierarchy : Left-to-Right ] VariableName; int[3][5] x; // x is an array of 3 arrays of 5 ints int[3]*[5] x; // x is an array of 3 pointers to arrays of 5 ints int*[] x; // x is a pointer to an array of ints int[]* x; // x is an array of pointers to ints
Feb 11 2002
parent "Walter" <walter digitalmars.com> writes:
"Serge K" <skarebo programmer.net> wrote in message
news:a482jr$2q3a$1 digitaldaemon.com...
    Verbose, yes, but it was as simple and clear as I can think it to



 What I was proposing is this, only using the C++ style:

 *[9]*[5][8]*string ComplexVar;

Your suggestion is excellent, I'm just not ready to give up the basic


 being on the left. Call me an old curmudgeon <g>.

Than how about my suggestion? ;-D (Well, maybe it's not the nicest one. But it's quite regular...) "Basic Type" [ arrays/pointers hierarchy : Left-to-Right ] VariableName; int[3][5] x; // x is an array of 3 arrays of 5 ints int[3]*[5] x; // x is an array of 3 pointers to arrays of 5 ints int*[] x; // x is a pointer to an array of ints int[]* x; // x is an array of pointers to ints

sorry <g>
Feb 11 2002
prev sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a47t8g$2mio$1 digitaldaemon.com...

 Your suggestion is excellent, I'm just not ready to give up the basic type
 being on the left. Call me an old curmudgeon <g>.

I second that =)
Feb 11 2002
prev sibling next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a3n5b2$20oo$1 digitaldaemon.com...
 I finally got around to addressing the problems of multiple declarations

 one statement.

     www.digitalmars.com/d/declaration.html

Seems fine. Function pointers could be better, but it doesn't really matters much, since they work fine.
Feb 04 2002
parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a3o14i$2fe8$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:a3n5b2$20oo$1 digitaldaemon.com...
 I finally got around to addressing the problems of multiple declarations

 one statement.

     www.digitalmars.com/d/declaration.html

Seems fine. Function pointers could be better, but it doesn't really matters much, since they work fine.

The only saving grace with function pointers is they are rarely declared, so it isn't worth spending too much effort on them. They work like in C, and that's good enough. Arrays are a different matter. I use arrays all the time, and so improving the declaration syntax for them pays off.
Feb 05 2002
prev sibling next sibling parent reply "D" <s_nudds hotmail.com> writes:
Declaration syntax generally reads right to left, not left to right....:

Walter <walter digitalmars.com> wrote in message
news:a3n5b2$20oo$1 digitaldaemon.com...
 I finally got around to addressing the problems of multiple declarations

 one statement.

     www.digitalmars.com/d/declaration.html

Feb 05 2002
parent "Walter" <walter digitalmars.com> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3o76d$2iue$1 digitaldaemon.com...
 Declaration syntax generally reads right to left, not left to right....:

Depends on which side you're looking at it from <g>.
Feb 05 2002
prev sibling parent reply "Serge K" <skarebo programmer.net> writes:
Well, you are replacing clumsy C declaration syntax with more clean one,
but it still follows kind of dynamic rule:
"Declaration syntax generally reads left to right",
except "Arrays, when lexically next to each other, read right to left".

How about making it static?
Each declaration contains some "basic" (or underlaying) type name optionally
followed by the arrays/pointers hierarchy. Type name probably should remain
at the first position (otherwise it'll end up with something like Pascal;),
but all in between can be ordered strictly left to right.

"Basic Type"  [ arrays/pointers hierarchy : Left-to-Right ]  VariableName;

int[3][5] x;	// x is an array of 3 arrays of 5 ints
int[3]*[5] x;	// x is an array of 3 pointers to arrays of 5 ints
int*[] x;	// x is a pointer to an array of ints
int[]* x;	// x is an array of pointers to ints

What do you think?
Feb 05 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
I'm all for it.  In fact I suggested the very same thing a few weeks ago.
The only major difference from what I can tell between this and the current
D syntax for typespecs is that D allows the array specification to come
after the variable (for minimal C compatibility I suppose).  I believe the
examples you give all work in D as it's currently specified.

Sean

"Serge K" <skarebo programmer.net> wrote in message
news:a3qnl7$22pd$1 digitaldaemon.com...
 Well, you are replacing clumsy C declaration syntax with more clean one,
 but it still follows kind of dynamic rule:
 "Declaration syntax generally reads left to right",
 except "Arrays, when lexically next to each other, read right to left".

 How about making it static?
 Each declaration contains some "basic" (or underlaying) type name

 followed by the arrays/pointers hierarchy. Type name probably should

 at the first position (otherwise it'll end up with something like

 but all in between can be ordered strictly left to right.

 "Basic Type"  [ arrays/pointers hierarchy : Left-to-Right ]  VariableName;

 int[3][5] x; // x is an array of 3 arrays of 5 ints
 int[3]*[5] x; // x is an array of 3 pointers to arrays of 5 ints
 int*[] x; // x is a pointer to an array of ints
 int[]* x; // x is an array of pointers to ints

 What do you think?

Feb 06 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a3qvu7$27a5$1 digitaldaemon.com...
 I'm all for it.  In fact I suggested the very same thing a few weeks ago.
 The only major difference from what I can tell between this and the

 D syntax for typespecs is that D allows the array specification to come
 after the variable (for minimal C compatibility I suppose).  I believe the
 examples you give all work in D as it's currently specified.

Nah. For example, int*[] is an array of pointers now, while int[]* is a pointer to array. He suggests to reverse them. I personally consider the syntax that is there now somewhat more "intuitive" - even though it's a bit more complicated.
Feb 06 2002
parent reply "Serge K" <skarebo programmer.net> writes:
 Nah. For example, int*[] is an array of pointers now, while
 int[]* is a pointer to array. He suggests to reverse them.
 I personally consider the syntax that is there now somewhat
 more "intuitive" - even though it's a bit more complicated.

More "intuitive" - means more like C#? ;-P Yeah, C/C++ programmers have to develop their intuition to recognize complex declarations. But anyhow - sometimes I have to use the language manual to decipher some really nasty construction... Don't condemn the next generation of the programmers to such hell!
Feb 06 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Serge K" <skarebo programmer.net> wrote in message
news:a3rc7f$2cgv$1 digitaldaemon.com...
 Nah. For example, int*[] is an array of pointers now, while
 int[]* is a pointer to array. He suggests to reverse them.
 I personally consider the syntax that is there now somewhat
 more "intuitive" - even though it's a bit more complicated.

More "intuitive" - means more like C#? ;-P

More like C/C++.
 Yeah, C/C++ programmers have to develop their intuition to recognize

 declarations.
 But anyhow - sometimes I have to use the language manual to decipher some
 really nasty construction...

Do you have to declare arrays to pointers of arrays so frequently anyhow? =)
 Don't condemn the next generation of the programmers to such hell!

Well I'm still this generation...
Feb 06 2002
prev sibling parent reply "Serge K" <skarebo programmer.net> writes:
 I'm all for it.  In fact I suggested the very same thing a few weeks ago.
 The only major difference from what I can tell between this and the

 D syntax for typespecs is that D allows the array specification to come
 after the variable (for minimal C compatibility I suppose).

Ability to put array specification after variable name seems to be quite useless "syntactic sugar" (since "declaration declaring multiple declarations" cannot declare variables with different type). The only practical reason to use such ability is to write something like this: int a[3], b[2], c; // currently not allowed.
 I believe the examples you give all work in D as it's currently specified.

No, currently it works in a quite opposite & mixed way.. ;-) It's just in my opinion the language specifications should have as less "special cases" as possible.
Feb 06 2002
parent "Sean L. Palmer" <spalmer iname.com> writes:
"Serge K" <skarebo programmer.net> wrote in message
news:a3raqb$2bvt$1 digitaldaemon.com...
 I'm all for it.  In fact I suggested the very same thing a few weeks


 The only major difference from what I can tell between this and the

 D syntax for typespecs is that D allows the array specification to come
 after the variable (for minimal C compatibility I suppose).

Ability to put array specification after variable name seems to be quite useless "syntactic sugar" (since "declaration declaring multiple declarations" cannot declare variables with different type). The only practical reason to use such ability is to write something like this:

I agree.
 int  a[3], b[2], c; // currently not allowed.

 I believe the examples you give all work in D as it's currently


 No, currently it works in a quite opposite & mixed way.. ;-)
 It's just in my opinion the language specifications should have as less
 "special cases" as possible.

I agree here too... case in point is how I failed to notice it's different from D syntax. It's subtle stuff like that which causes program bugs, so the simpler the typespec/declaration syntax, the better. Either straight right-to-left order, or straight left-to-right order, please. Sean
Feb 06 2002