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


in

 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


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

Agreed.


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


programmers won't

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


 programmers won't

 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


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 :(


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


 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 :(


 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


and

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


prone)

 programming.

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


For

 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






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


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


in

 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


 in

 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


in

 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


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


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.


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.




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 like C/C++.


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


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


current

 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




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).


 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




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.


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