"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9sh8nm$237g$1@digitaldaemon.com...
> > > So the following:
> > >     class A
> > >     {
> > >         static void B() { ... }
> > >     }
> > >     A a;
> > >     A::B();
> > >     a.B();    // the same?
> >
> > Yes.
>
> Are you saying that D supports use of the :: operator?
>
> Sean

No, sorry, A::B() is not allowed. Use A.B()

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sglru$1ae5$2@digitaldaemon.com...
> I believe that extern() property states that function
> has no body, so the following is illegal:
>
>     extern(Windows) int WindowProc() { }
>
> Is it so? If it is, how about WinAPI callbacks?

It is legal, despite what the doc says (!).


> Is it legal to define names for parameters of extern
> function? Is it legal to omit names of parameters
> of implemented function? Like that:
>
>     extern(Windows) int LineTo(HDC hDc, int x, int y);
>     void TimerProc(HWND, uint, uint id, uint) { switch (id) { ... } }

Yes.


> How are function pointers declared? I remember a discussion of this topic not long ago, but what is the official way?

I haven't done that yet.

> Are pointers to methods supported?

No. Pointers to methods are nothing but confusion.

> Are they like in Delphi (kewl)
> or in C++ (almost useless)?

How do they work in Delphi?

"Walter" <walter@digitalmars.com> wrote in message news:9si4hs$2ved$3@digitaldaemon.com...

> > What if class A contains variable B? Will the above code do what we expect it to?
>
> A.super.Y()

This works if A is a direct successor of B. However, the
example is simplified, but in general assume there are
many other classes between A and B in the hierarchy.

Now what? =)

"Walter" <walter@digitalmars.com> wrote in message news:9si4hr$2ved$1@digitaldaemon.com...

> If you are writing assembler routines, the options are:
> 1) use the inline assembler, where you don't care about call/return
> conventions
> 2) declare the external assembler function with C call/return conventions

BTW what's the point in caller cleaning the stack? I always thought that callee, using RET n on x86, for example, can do it faster. Since you aren't going to support C-style varargs...

"Walter" <walter@digitalmars.com> wrote in message news:9si93q$o4$2@digitaldaemon.com...

> > How are function pointers declared? I remember a discussion of this topic not long ago, but what is the official way?
>
> I haven't done that yet.

My suggestion would be something like:

    int(int x, int y) OnMouseMove;

> > Are pointers to methods supported?
>
> No. Pointers to methods are nothing but confusion.

Disagreed. They are really useful for writing callback-
based event-driven system - GUI toolkits are a typical
example of this. Compare VCL, which relies on pointers
to methods, and MFC, which uses map tables. Which one
is easier?

> > Are they like in Delphi (kewl)
> > or in C++ (almost useless)?
>
> How do they work in Delphi?

type
    TButton = class
        OnMouseMove: procedure(x, y: integer) of object;
    end;

    TMyForm = class(TForm)
        cmdOk: TButton;
        ...
        constructor Create;
        procedure cmdOk_MouseMove(x, y: integer);
    end;

    constructor TMyForm.Create;
    begin
        cmdOk.OnMouseMove := cmdOk_MouseMove;
    end;

    procedure TMyForm.cmdOk_MouseMove(x, y: integer)
    begin
        ...
    end;

In other words, in Delphi pointer to method is universal - it can point to any method of any class, whose parameters and return type matches the declaration. Also, unlike C++ one, it does store the pointer to object to which method belongs! But these are technical details, what it gives to programmers is ability to define callbacks for methods in absolutely the same way as for global functions, and compiler takes care of the rest. Nothing close compared to weird and useless C++ method pointers.

The entire VCL library is built on this system - and I believe it's one of the easiest, yet powerful, GUI toolkits for Windows.

BTW in C++Builder, pointers to methods are declared
using __closure keyword. Isn't that funny =)

If module B imports module C, and module A
imports B, does A import C?

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sik7a$7ed$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:9si4hr$2ved$1@digitaldaemon.com...
>
> > If you are writing assembler routines, the options are:
> > 1) use the inline assembler, where you don't care about call/return
> > conventions
> > 2) declare the external assembler function with C call/return
conventions
>
> BTW what's the point in caller cleaning the stack? I always thought that callee, using RET n on x86, for example, can do it faster. Since you aren't going to support C-style varargs...

The code generator can be clever and avoid any stack cleanups at all, which of course is faster.

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sik3l$7e8$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9si4hs$2ved$3@digitaldaemon.com...
>
> > > What if class A contains variable B? Will the above code do what we expect it to?
> >
> > A.super.Y()
>
> This works if A is a direct successor of B. However, the
> example is simplified, but in general assume there are
> many other classes between A and B in the hierarchy.
>
> Now what? =)

A.super.dee.duper.B()

<g>

I would argue in favor of breaking with tradition on the 'int *x, y;' question.  Try listing out some arguments on each side:


For breaking with tradition:
----------------------------

  1) The C way is frequently misunderstood by beginners.

  2) The C way often leads to bugs (even if they are usually caught
     by the compiler, they are still bugs).

  3) The C way associates the * with the variable rather than the
     type;  does anyone really want to be able to have 'int *x, y, *z;'?

  4) The C way requires more typing, admittedly only one more character
     per variable, but more is more.

  5) If one is reading C code and sees 'int *x, y;', there is always
     the nagging feeling that the person who wrote it made a mistake.

  6) In writing actual code, I sometimes want to declare two pointer
     variables;  I almost never want to declare both a pointer and
     a non-pointer.


For staying with tradition:
---------------------------

  1) Compatibility.

  2) It turns out that there is a case where both a pointer and a
     non-pointer are declared simultaneously that occurs fairly
     often, and that is typedef.  For example

	 typedef struct Foo_tag  *FooPointer, Foo;

     (Substitute Hungarian notation for 'FooPointer' if that is your
     preference.)  So the old C way is used sometimes in ways that
     are at least semi-reasonable.


On balance the arguments for breaking with tradition seem stronger than those for staying with tradition.  Or are there some important arguments that are missing?



"Walter" <walter@digitalmars.com> writes:

> "Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message
>
> > Suppose I have the following declaration:
> >     int* x, y;
> > Is y an int or a pointer to int?
> 
> An int. I didn't break away from C on that one. I can be persuaded otherwise.