• Jeffrey Drake (21/21) Aug 16 2001 I read the specificiation like so many other ./ and I liked most of it.
• Ben Cohen (7/8) Aug 17 2001 How about doing the following instead:
• Chris Friesen (10/20) Aug 17 2001 I like that syntax. That way, everything on one variable declaration li...
• Sean L. Palmer (28/43) Nov 03 2001 I disagree... the typespec should be able to be read either left to righ...
• Ben Cohen (10/18) Nov 05 2001 It is certainly no less clear than "int (*array)[3]"; the difference is
• Ben Cohen (6/10) Nov 05 2001 This also has the advantage that you don't have to worry about precedenc...

"Jeffrey Drake" <jpt.d home.com> writes:

I read the specificiation like so many other ./ and I liked most of it.

I do believe in the necessity for templates and operator overloads.

An example of each would be this comparison:
Borland C++ builder has a Collection class in its VCL. The basic way of how
it worked was you had to derive a class off of collectionitem to be able to
use it. I think that is a waste of time. STL has a nice vector class (and a
whole bunch of others) that can store the same info in one line of code for
yourself.

Operator overloads are nice in cout and cin. I use cout and cin to a nice
ability, sometimes prefering printf though.

I don't like the int[3] *array; thing. I think it is backwards.

I think it makes more sense the normal way because you have:

'pointer to 3 elements' rather than '3 elements pointed by'.

Also, not having a bitfield but having a bit type... that seems a little
wrong. Maybe finding a better bit field syntax would be better.

A nice feature would be support for nth digit numbers. 32bit and 64bit
numbers common now are nice, but would be much better to have direct support
for 2048 bit numbers for those that want that 1+ million$ prize for cracking
the 2048 bit number. (:-)

Regards,
Jeffrey Drake

"Ben Cohen" <bc skygate.co.uk> writes:

In article <9lieuo$s7r$1 digitaldaemon.com>, "Jeffrey Drake"
<jpt.d home.com> wrote:

 I don't like the int[3] *array; thing. I think it is backwards.

How about doing the following instead:

*int[3] array;

This would then avoid this problem:

int*  int_p1, int_p2;

where I might think int_p2 has type int* but actually has type int.

Chris Friesen <cfriesen nortelnetworks.com> writes:

Ben Cohen wrote:
 
 In article <9lieuo$s7r$1 digitaldaemon.com>, "Jeffrey Drake"
 <jpt.d home.com> wrote:
 
 I don't like the int[3] *array; thing. I think it is backwards.

 How about doing the following instead:
 *int[3] array;
 This would then avoid this problem:
 int*  int_p1, int_p2;
 where I might think int_p2 has type int* but actually has type int.

I like that syntax.  That way, everything on one variable declaration line has
exactly the same type, and it's even lexically clearer: "make a pointer to and
array of three ints and call it array"

Chris


-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen nortelnetworks.com

"Sean L. Palmer" <spalmer iname.com> writes:

I disagree... the typespec should be able to be read either left to right or
right to left, but no mixing, please.

Either

*[3]int array;   // left to right.. pointer to array of 3 ints

or

int[3]* array;   // right to left... pointer to array of 3 ints

I prefer right-to-left, as it seems more natural to a C programmer, which is
the group of people D will appeal to.  Pascal did left to right, but it was
much wordier.  Also right-to-left allows multidimensional arrays to work in
a way more people understand.

I don't see how you can consider this:

*int[3] array;  // mixed... make a pointer to an array of 3 ints

to be "lexically clearer".  Once you start considering pointers to functions
that return pointers to arrays, or other complicated typespecs, readability
becomes an important factor to consider.  Mixing the order also makes the
parser more complicated.

BTW I'm 100% against allowing the declaration of multiple different types of
variables in one declaration.  If you want an int and an int*, do it on two
separate lines:

int myint;
int* myintptr;

or on one line:

int myint;  int* myintptr;

Sean

"Chris Friesen" <cfriesen nortelnetworks.com> wrote in message
news:3B7D19AC.C864270 nortelnetworks.com...
 Ben Cohen wrote:
 In article <9lieuo$s7r$1 digitaldaemon.com>, "Jeffrey Drake"
 <jpt.d home.com> wrote:

 I don't like the int[3] *array; thing. I think it is backwards.

 How about doing the following instead:
 *int[3] array;
 This would then avoid this problem:
 int*  int_p1, int_p2;
 where I might think int_p2 has type int* but actually has type int.

 I like that syntax.  That way, everything on one variable declaration line

has
 exactly the same type, and it's even lexically clearer: "make a pointer to

and
 array of three ints and call it array"

 Chris

"Ben Cohen" <bc skygate.co.uk> writes:

In article <9s2enb$21o6$1 digitaldaemon.com>, "Sean L. Palmer"
<spalmer iname.com> wrote:

 I don't see how you can consider this:
 
 *int[3] array;  // mixed... make a pointer to an array of 3 ints
 
 to be "lexically clearer".  Once you start considering pointers to
 functions that return pointers to arrays, or other complicated
 typespecs, readability becomes an important factor to consider.  Mixing
 the order also makes the parser more complicated.

It is certainly no less clear than "int (*array)[3]"; the difference is
that the type modifiers are all attached to the base type, not the
identifier (so that all the identifiers after the base type must be of
identical types).

Of course, I agree that "int[3]* array" is clearer still, but I would want
"int[3]* array1, array2" to mean "int (*array1)[3], (*array2)[3]" (from
C), not anything else.  This might confuse C programmers -- but would be
more consistent overall.

"Ben Cohen" <bc skygate.co.uk> writes:

In article <9s5mmq$19ua$1 digitaldaemon.com>, "Ben Cohen"
<bc skygate.co.uk> wrote:

 Of course, I agree that "int[3]* array" is clearer still, but I would
 want "int[3]* array1, array2" to mean "int (*array1)[3], (*array2)[3]"
 (from C), not anything else.  This might confuse C programmers -- but
 would be more consistent overall.

This also has the advantage that you don't have to worry about precedence;
is "*int[3] array" the same as "(*int)[3] array" or "*(int[3]) array"?
If you do it from right to left there is no possibility for confusion.

I think Walter wants to do it that way; see the thread "D Syntax Queries".