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

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.

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

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

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.

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