"Walter" <walter@digitalmars.com> wrote in news:b3fdlo$kp1$1@digitaldaemon.com:

Walter,

here are three issues I encountered with DMD 0.56 and 0.57:

The template argument deduction seems to be broken. The Object type is ignored by the compiler.

class A { }
class B : A { }

template TFoo(T : A) { }
instance TFoo(B);

Causes this error message:
instance TFoo(B ) does not match any template declaration


--

DMD.zip contains the compiler twice: See file "DMD\.EXE".


--

I compiled some D code that compiles and runs fine, if the option -O is not
used. If option -O is turned on, the compiler says:
Internal error: ..\ztc\cgcod.c 2198



Farmer

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b3j9no$38n$1@digitaldaemon.com...
> > See the next example
> > www.digitalmars.com/d/ctod.html#traversal which is a (again, greatly
> > simplified) piece of code from my own work.
> .. and then there's for example a (not "the") Java way:
> static void findMember( Map[] symtables, String id ) {
>    for (int s=0; s<symtables.length; ++s) {
>       Symbol s = (Symbol) symtables[s].get(id);
>       if (s!=null) {
>         // do whatever you want here
>       }
>    }
> }
> No need for any inline functions or nested functions or whatever other
> functions :)
> I'm sorry, but the days for programming recursive pointer traversal
> algorithms have long been over for Java programmers.

No, it's just been hidden away inside the implementation of the get(id) function, and *that* code will need some sort of context pointer. Consider also the case of applying an arbitrary function to each member of the table (see the example in www.digitalmars.com/d/cpptod.html).

> I'm using Java as an
> example here, I'm sure there are other languages that can do the same.
> Regardless of whether you like Java or not, if possible it would be nice
to
> have examples that compare D features with state-of-the-art options in
other
> languages. The fact that they occur in production code doesn't
automatically
> mean they are a good (I won't say 'the right', there are always
trade-offs )
> approach
>
> As an objective person looking at D, I would be looking for features that help me solve problems that are not addressed adequately by what I am
using
> today. Less lines of code, better maintainable code, better runtime
support,
> "if you do it like this you automagically get <nifty feature>", all of
these
> can be reasons. Until now the examples provided have not been convincing
to
> me.

Ok, how in Java do you apply an arbitrary piece of code to all the elements in some generic container?

"Dan Liebgold" <Dan_member@pathlink.com> wrote in message news:b3j9p5$39b$1@digitaldaemon.com...
> D, it seems, is designed for practical performance to be of higher
priority that
> theoretically powerful constructs that complicate implementation, like
lexical
> scoping.

Correct. Also, D tries to avoid features that are overly complex to implement.

> BTW, I believe that is the ultimate downfall of first class functions.

Implementing lexical closure would kill off the uses of nested functions in the examples I used, because the performance would be unacceptable.

"Farmer" <itsFarmer.@freenet.de> wrote in message news:Xns932EE4CF28753itsFarmer@63.105.9.61...
> I compiled some D code that compiles and runs fine, if the option -O is
not
> used. If option -O is turned on, the compiler says: Internal error: ..\ztc\cgcod.c 2198

I need an example. Thanks! -Walter

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b3j9no$38n$1@digitaldaemon.com...
> As an objective person looking at D, I would be looking for features that help me solve problems that are not addressed adequately by what I am
using
> today. Less lines of code, better maintainable code, better runtime
support,
> "if you do it like this you automagically get <nifty feature>", all of
these
> can be reasons. Until now the examples provided have not been convincing
to
> me.

Here's another one. Suppose we have in our generic library a function to perform numerical integration:

------------------------------------------
// Integrate f(x) from x1..x2 by dx

real integrate(real delegate(real x) f, real x1, real x2, real dx)
{
    real sum = 0.0;

    for (real x = x1; x < x2; x += dx)
    {
        real y1, y2;

        y1 = f(x);
        y2 = f(x + dx);
        sum += (y1 + y2) * dx / 2.0;
    }
    return sum;
}
---------------------------------------------

Then, in our application code, we want to integrate from 0..x a polynomial of the form:

    f(x) = a + b*x + c*x**2 + ...

Here's a function to do it with coeff[] representing the a, b, c coefficients:

-----------------------------------------------

real integrate_polynomial(real coeff[], real x)
{
    real f(real x)
    {
        real y = 0.0;
        real xp = 1.0;

        for (int i = 0; i < coeff.length; i++)
        {
            y += coeff[i] * xp;
            xp *= x;
        }
        return y;
    }

    return integrate(f, 0, x, .01);
}
----------------------------------------
Notice how the function f(x) can be written to arbitrarilly reference other
data in a typesafe manner, without any need to modify the generic library
routine.
I don't know of a better way in C, C++, C# or Java to do this. (Overlooking
numerical improvements, which isn't the point here.)

"Farmer" <itsFarmer.@freenet.de> wrote in message news:Xns932EE4CF28753itsFarmer@63.105.9.61...
> DMD.zip contains the compiler twice: See file "DMD\.EXE".

Fixed.

Walter wrote:
> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:b3gis9$1bf0$1@digitaldaemon.com...
> 
>>>In earlier versions, the & was required. In 0.57, either will work. I'm
>>>thinking of obsoleting the & version.
>>
>>Removing that would make properties impossible.
> 
> Please elaborate.

You wouldn't be able to differentiate between a property access and a function pointer access.  For example:

   class Class
   {
       void *method () { }
   }

   Class object = new Class;
   void *pointer = object.method;

Am I getting the pointer to the method or the pointer from the method? This decision could be deferred to the semantic phase, but that's pretty late to be making such an important decision on what code is representing.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3E5D5FAD.80605@users.sourceforge.net...
> You wouldn't be able to differentiate between a property access and a function pointer access.  For example:
>
>     class Class
>     {
>         void *method () { }
>     }
>
>     Class object = new Class;
>     void *pointer = object.method;
>
> Am I getting the pointer to the method or the pointer from the method? This decision could be deferred to the semantic phase, but that's pretty late to be making such an important decision on what code is representing.

Ah, I see what you mean.

> -----------------------------------------------
>
> real integrate_polynomial(real coeff[], real x)
> {
>     real f(real x)
>     {
>         real y = 0.0;
>         real xp = 1.0;
>
>         for (int i = 0; i < coeff.length; i++)
>         {
>             y += coeff[i] * xp;
>             xp *= x;
>         }
>         return y;
>     }
>
>     return integrate(f, 0, x, .01);
> }
> ----------------------------------------
> Notice how the function f(x) can be written to arbitrarilly reference
other
> data in a typesafe manner, without any need to modify the generic library
> routine.
> I don't know of a better way in C, C++, C# or Java to do this.
(Overlooking
> numerical improvements, which isn't the point here.)

I won't say it's better, but in Java you can do more or less the same:

real integrate_polynomial( final real coeff[], real x)
{
    Fuction f = new Function() {
        public int evaluate( real x )
        {
         real y = 0.0;
         real xp = 1.0;

         for (int i = 0; i < coeff.length; i++)
         {
             y += coeff[i] * xp;
             xp *= x;
         }
         return y;
         }
     };

     return integrate(f, 0, x, .01);
 }

Note the 'final' to make coeff accessible. Alternatively, I could pass it as an argument to the constructor of f, but then I would need to define it as a datamember too.

That is, you create a function object implementing some 'Function' interface which has an 'evaluate' method. One possible advantage here is that the D program you wrote only supports single argument functions f(x). If I wanted to also have f(x,y), I could add this to the interface, whereas in D it would have to be a different delegate (-parameter). In this sense I think interfaces (and anonymous implementations as shown above) are more generic that function pointers / delegates

BTW, now that I'm thinking about this: One of the worse features of Java IMO is the rediculous amount of resources (memory) it uses for simple things. The garbage collector is good, but it allocates so many small objects (the example I gave allocates one for the function object).

The advantage is though that I can return this object from my function, and use it elsewhere. What happens if I return a reference to a nested function delegate in D? Is it still valid, is there also some memory allocated underneath? You would expect it to go out of scope, so the compiler should issue a warning "returning reference to local function" or something