How about @ instead of & for references?  Credit
Allen Holub with that idea.

One of the better features of C# is its multidimensional
arrays.  You can have ragged or rectangular arrays,
and use Fortran notation for the rectangular ones (there's
another overload for ()s).

Are longs 64 bits?

--Ivan Frohne

"Ivan Frohne" <frohne@gci.net> wrote in message news:9l9aop$pt8$1@digitaldaemon.com...
> How about @ instead of & for references?  Credit
> Allen Holub with that idea.

What's his rationale?


> One of the better features of C# is its multidimensional
> arrays.  You can have ragged or rectangular arrays,
> and use Fortran notation for the rectangular ones (there's
> another overload for ()s).

This works in D! see:

    www.digitalmars.com/d/float.html


> Are longs 64 bits?

Yes.

"Walter" <walter@digitalmars.com> wrote in message news:9l9guq$t7p$1@digitaldaemon.com...
>
> "Ivan Frohne" <frohne@gci.net> wrote in message news:9l9aop$pt8$1@digitaldaemon.com...
> > How about @ instead of & for references?  Credit
> > Allen Holub with that idea.
>
> What's his rationale?

Here's a quote from "C + C++:  Programming with objects
in C and C++," McGraw-Hill, 1992, by Holub, p. 100:

"Using the & to mean 'reference' is, to my mind, a syntactic mistake on the part of the language designers.  The & usually means 'address of' and using [it] for 'reference to' just adds confusion.  A new operator (@ is a good candidate) should have been introduced to mean 'reference to'."

--Ivan Frohne

I think the rationale was that '@' wasn't available in international character sets. Be that as it may, I'm seriously considering dropping explicit reference types entirely. Reference types will be implicit for arrays, classes, out and inout function parameters. I don't think anyone will miss them!

-Walter


Ivan Frohne wrote in message <9l9vq1$150t$1@digitaldaemon.com>...
>
>"Walter" <walter@digitalmars.com> wrote in message news:9l9guq$t7p$1@digitaldaemon.com...
>>
>> "Ivan Frohne" <frohne@gci.net> wrote in message news:9l9aop$pt8$1@digitaldaemon.com...
>> > How about @ instead of & for references?  Credit
>> > Allen Holub with that idea.
>>
>> What's his rationale?
>
>Here's a quote from "C + C++:  Programming with objects
>in C and C++," McGraw-Hill, 1992, by Holub, p. 100:
>
>"Using the & to mean 'reference' is, to my mind, a syntactic mistake on the part of the language designers.  The & usually means 'address of' and using [it] for 'reference to' just adds confusion.  A new operator (@ is a good candidate) should have been introduced to mean 'reference to'."
>
>--Ivan Frohne
>
>
>
>

Im Artikel <9la3tb$178j$2@digitaldaemon.com> schrieb "Walter" <walter@digitalmars.com>:

> I think the rationale was that '@' wasn't available in international character sets. Be that as it may, I'm seriously considering dropping explicit reference types entirely. Reference types will be implicit for arrays, classes, out and inout function parameters. I don't think anyone will miss them!

I agree. I don't miss them in Java and since class types and dynamic arrays are references already, who needs them?

-- 
Sheldon Simms / sheldon@semanticedge.com

I like the following quotes from the D spec:

  Experienced FORTRAN numerics programmers know that multidimensional
  "rectangular" arrays for things like matrix operations are much
  faster than trying to access them via pointers to pointers resulting
  from "array of pointers to array" semantics.

I just wonder why rectangular arrays must be static as in Fortran? Can we also have *dynamic* rectangular arrays in D as well (of course we need some new syntax here):

    int    matrix[2,3];			// static  rectangular array
    int[,] matrix = new int[2,3];	// dynamic rectangular array

If the implementation for this dynamic rectangular array can also give better performance than the "pointers to pointers" approach, I think people writing numeric applications would be interested in it.

YuQian

Dynamic rectangular arrays are possible, just not implemented in D. You can fake them with a single dimensioned dynamic array, however.

Yu Qian Zhou wrote in message ...
>
>I like the following quotes from the D spec:
>
>  Experienced FORTRAN numerics programmers know that multidimensional
>  "rectangular" arrays for things like matrix operations are much
>  faster than trying to access them via pointers to pointers resulting
>  from "array of pointers to array" semantics.
>
>I just wonder why rectangular arrays must be static as in Fortran? Can we also have *dynamic* rectangular arrays in D as well (of course we need some new syntax here):
>
>    int    matrix[2,3]; // static  rectangular array
>    int[,] matrix = new int[2,3]; // dynamic rectangular array
>
>If the implementation for this dynamic rectangular array can also give better performance than the "pointers to pointers" approach, I think people writing numeric applications would be interested in it.
>
>YuQian
>

I use references all the time to save typing.  For instance:  (C++ code)

#include <vector>
#include <iostream>

struct mystruct
{
  int foo;
};

{
  std::vector<mystruct> myvector;
  for (std::vector<mystruct>::iterator i = myvector.begin(); i !=
myvector.end(); ++i)
  {
     mystruct& ms = (*i);
     std::cout << ms.foo;
  }
}

Now just imagine a more complex function that uses ms many times... the savings in typing and increased readability quickly add up.

If you provide some kind of "with" statement ala pascal it would solve much of the need for references, otherwise I'd suggest keeping them, they're very convenient.  If I had to choose between Pascal's "with" clause and references I'd definitely choose to keep references.  They'd be unnecessary in parameter lists since a const reference may be auto-generated by "in" parameters, and non-const reference auto-generated by "inout" parameters. I'm not 100% sure how exactly "out" parameters would work since they imply ignorance of the current state of the object, yet that object has to be passed in, so may have already been initialized etc.

What are the results of doing something like this in D?:  (Admittedly this
is a contrived example.)

class A
{
private:
  Resource r;
public:
  this() { r=AllocResource(); }
  ~this() { DeallocResource(r); }
}

void GimmeAnA(out A a)
{
  a = new A;
}

{
  A aresult;
  GimmeAnA(a);
}

Does aresult get constructed, then an assignment happen from the result of GimmeAnA, or since it's an out parameter does the compiler ignore any previous value in aresult and construct it directly inside GimmeAnA?  What if aresult were used before the call to GimmeAnA?

Sean

"Walter" <walter@digitalmars.com> wrote in message news:9la3tb$178j$2@digitaldaemon.com...
> I think the rationale was that '@' wasn't available in international character sets. Be that as it may, I'm seriously considering dropping explicit reference types entirely. Reference types will be implicit for arrays, classes, out and inout function parameters. I don't think anyone will miss them!
>
> -Walter

You will rarely need to use a pointer in D. All instances of class objects are on the heap, so all the programmer sees are implicit references to them.

And D does support the with statement!

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9ri1vc$1jin$1@digitaldaemon.com...
> I use references all the time to save typing.  For instance:  (C++ code)
>
> #include <vector>
> #include <iostream>
>
> struct mystruct
> {
>   int foo;
> };
>
> {
>   std::vector<mystruct> myvector;
>   for (std::vector<mystruct>::iterator i = myvector.begin(); i !=
> myvector.end(); ++i)
>   {
>      mystruct& ms = (*i);
>      std::cout << ms.foo;
>   }
> }
>
> Now just imagine a more complex function that uses ms many times... the savings in typing and increased readability quickly add up.
>
> If you provide some kind of "with" statement ala pascal it would solve
much
> of the need for references, otherwise I'd suggest keeping them, they're
very
> convenient.  If I had to choose between Pascal's "with" clause and references I'd definitely choose to keep references.  They'd be
unnecessary
> in parameter lists since a const reference may be auto-generated by "in" parameters, and non-const reference auto-generated by "inout" parameters. I'm not 100% sure how exactly "out" parameters would work since they imply ignorance of the current state of the object, yet that object has to be passed in, so may have already been initialized etc.
>
> What are the results of doing something like this in D?:  (Admittedly this
> is a contrived example.)
>
> class A
> {
> private:
>   Resource r;
> public:
>   this() { r=AllocResource(); }
>   ~this() { DeallocResource(r); }
> }
>
> void GimmeAnA(out A a)
> {
>   a = new A;
> }
>
> {
>   A aresult;
>   GimmeAnA(a);
> }
>
> Does aresult get constructed, then an assignment happen from the result of GimmeAnA, or since it's an out parameter does the compiler ignore any previous value in aresult and construct it directly inside GimmeAnA?  What if aresult were used before the call to GimmeAnA?
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:9la3tb$178j$2@digitaldaemon.com...
> > I think the rationale was that '@' wasn't available in international character sets. Be that as it may, I'm seriously considering dropping explicit reference types entirely. Reference types will be implicit for arrays, classes, out and inout function parameters. I don't think anyone will miss them!
> >
> > -Walter
>
>
>

"Sean L. Palmer" wrote:
> 
> I use references all the time to save typing.  For instance:  (C++ code)
> 
> [...]
>
>   for (std::vector<mystruct>::iterator i = myvector.begin(); i !=
> myvector.end(); ++i)
>   {
>      mystruct& ms = (*i);
>      std::cout << ms.foo;
>   }
> }
> 
> Now just imagine a more complex function that uses ms many times... the savings in typing and increased readability quickly add up.

Hm, this is getting towards matters of personal style, but I disagree with this for a number of reasons.

- Saving yourself typing frequently means reduced readability for the other programmers who have to deal with your code. Rather than "ms" or "i" I'd prefer to see "element" or (if it's, say, a vector of wombats) "wombat" as the name of the iterator. If you have carpal tunnel syndrome, I could cut you some slack, I guess, but on the whole, I find long identifiers to be more readable in the long run.

- In your example, you've traded away "i->foo" to get "ms.foo", which is no savings to length or readability no matter how many times you make the substitution :)

- If you're intending to do a lot more to ms in the loop, then it may be that you should factor that series of operations into a member function of mystruct, so the loop body becomes:

  i->DoWhatWombatsDo();  // or ms.DoWhatWombatsDo();

- Last but not least, STL provides the "for_each()" mechanism to clean up exactly this idiom. I myself am guilty of not having learned to use it yet.

-RB