On Wed, 13 Sep 2006 06:33:19 +1000, Reiner Pope <reiner.pope@REMOVE.THIS.gmail.com> wrote:

>interface Foo
<SNIP>
>struct Bar : Foo
<SNIP>
>void calc(Foo f) { ... }
>
>How can calc know the type of every struct it is passed unless a separate version of calc is generated for every type (in which case it is just a template)?

Compiler generated proxy object, containing a vtable and a pointer to the struct.

To pass the struct as an interface, you need some kind of reference anyway. You can't just pass the whole struct. A reference to a proxy object would make at least some sense.

Mind you, it's very dodgy, to say the least. I have argued for struct inheritance, but this is not the kind of inheritance I want. I still want structs to be data, not reference-free objects.

-- 
Remove 'wants' and 'nospam' from e-mail.

Steve Horne wrote:
> On Tue, 12 Sep 2006 17:49:44 +0300, Kristian <kjkilpi@gmail.com>
> wrote:
> 
>> C++ const is better than nothing. Hopefully there will be a solution that  will suit everybody, more or less.
Lack of const and requiring people to document their code well is the only painless solution at the moment, I think. That, and switching to a pure functional language.
> 
> But I have mixed feelings about C++ const. It has caught errors for
> me, but not often, and quite often those errors wouldn't exist without
> 'const' anyway. 
How can you call that catching errors?

> Of course I understand the efficiency benefits, but it's not very
> intuitive.
As Walter says, the efficiency benefits are very small because of the aliasing problem and the presence of const_cast. The main two reasons for const are catching errors and documenting code.

> Pointers even need to be told whether it is the pointer that is const
> or the value pointed to, or both for that matter.
> 
This is what I was talking about with the ugliness of const, not the naming system.

  const Fred const * p;

is a bit excessive, don't you think? Not to mention very illegible. D's move to implicit reference semantics for classes means that we can get a  generally-easier-to-read syntax, like is proposed in Javari:

  readonly final Fred p;

where 'readonly' refers to the actual data, and 'final' means that p can't be used as an lval (ie, the pointer itself is const).


> So the dependencies mean you have three options...
> 
> 1.  Make constness into something you think about all the time.
> 2.  Don't do constness at all.
> 3.  Do half-hearted constness and have loads of const-casts,
>     defeating the point.
> 
> And then, your code has to work with someone elses... Someone who has
> a very different approach.
In a way, the choice is made on a language level, which is the concern about const in D. As you have described, it becomes a real nuisance in C++, and the benefits are not always clear.

Just giving a taste of the discussions of const on this newsgroup... <g>

Cheers,

Reiner

Steve Horne wrote:
> On Wed, 13 Sep 2006 06:33:19 +1000, Reiner Pope
> <reiner.pope@REMOVE.THIS.gmail.com> wrote:
> 
>> interface Foo
> <SNIP>
>> struct Bar : Foo
> <SNIP>
>> void calc(Foo f) { ... }
>>
>> How can calc know the type of every struct it is passed unless a separate version of calc is generated for every type (in which case it is just a template)?
> 
> Compiler generated proxy object, containing a vtable and a pointer to
> the struct.
What's the difference between this and a class, then?

> Mind you, it's very dodgy, to say the least. I have argued for struct
> inheritance, but this is not the kind of inheritance I want.
I don't understand what you do want, then. Interface inheritance requires class-like vtables, and once you've got that you've basically got a class, anyway. *Implementation* inheritance can be done using mixins.

Of course, in D, implementation inheritance via mixins is a bit limited -- you can only mix in templates, not structs. I see no technical reason why you couldn't mix in any class, function, or struct that you have the source code for. This basically means implicitly templatizing whatever you want to mix in.

Cheers,

Reiner

On Wed, 13 Sep 2006 19:09:20 +1000, Reiner Pope <reiner.pope@REMOVE.THIS.gmail.com> wrote:

>> Compiler generated proxy object, containing a vtable and a pointer to the struct.
>What's the difference between this and a class, then?

Er - you'd have to write the class yourself?

>> Mind you, it's very dodgy, to say the least. I have argued for struct inheritance, but this is not the kind of inheritance I want.
>I don't understand what you do want, then. Interface inheritance

I never said I want interface support for structs. I just joined in a thread on someone elses idea. Just saying its possible - not that it's a good idea ;-)

The struct inheritance I want allows structs to inherit from structs, adding a few extra data fields. What to do about methods, I don't know. I'm not comfortable with structs having methods anyway - a result of a style developed in C++ where the keywords 'struct' and 'class' tend to imply different things to programmers even though the compiler sees them the same.

And I'm not all that fussed about struct inheritance either. Just can't leave things alone when people disagree with me ;-)

-- 
Remove 'wants' and 'nospam' from e-mail.

On Wed, 13 Sep 2006 19:02:27 +1000, Reiner Pope <reiner.pope@REMOVE.THIS.gmail.com> wrote:

>> But I have mixed feelings about C++ const. It has caught errors for me, but not often, and quite often those errors wouldn't exist without 'const' anyway.
>How can you call that catching errors?

That's down to the definition of 'error', of course. Trying to call a non-const method for a const object is an error, by definition, in C++. The fact that you only wanted read a value is besides the point.

Letter of the law vs. practical reality. Be careful what you say, or the language lawyers will come for you ;-)

-- 
Remove 'wants' and 'nospam' from e-mail.

Reiner Pope wrote:
> BCS wrote:
> 
[...]
>>
>> No, because the type of a struct is always known, the required value for the interface's function table can be found at compile time and all that is needed is to attach it to a reference to the struct.
> 
> I don't understand you. How would it work?
> 
> Suppose you had this code:
> 
> interface Foo
> {
>     int foo();
> }
> 
> struct Bar : Foo
> {
>     int foo() { ... }
>     ...
> }
> 


If I understand it correctly interfaces variables are a fat pointer, sort of like a delegate. They could be implemented something like this:

struct Interface
{
	void* context;
	void*[] v_table;
}

When a class implements an interface it creates a static array containing  pointers to it's methods. A reference to this array is placed in that classes v-table. When an interface instance is needed something like this is done:

class C : Foo {...}
C c = new C;
Interface i;

		// set context
i.context = c;
		// set v-table
i.v_table = c.vtbl[C.Foo_index];

When an interface is used to call a method it ends up looking something like this (omitting a bunch of casts):

i.v_table[Foo.foo_index](i.context);


The only reason that the v-table for the interface is referenced by way of the v-table of the class is that the actual type of the class isn't known until run time. For a struct, that isn't the case, the type is always known. Their for, something like this can be done.

Bar bar;

		// set context
i.context = &bar;
		// set v-table
i.v_table = Bar.Foo_vtbl];

this doesn't require any v-table in Foo

> void calc(Foo f) { ... }
>
> How can calc know the type of every struct it is passed unless a
> separate version of calc is generated for every type (in which case it
> is just a template)?

a function that uses an interface NEVER knowns the type of the underlying data. In fact the only way it ever uses it is by passing it as a context to one of the function accessed by way of the v-table referenced in the /interface/

this is analogous to a function taking a delegate not caring what the context of that delegate is.

>
> Cheers,
>
> Reiner

On Wed, 13 Sep 2006 12:02:27 +0300, Reiner Pope <reiner.pope@REMOVE.THIS.gmail.com> wrote:
> Steve Horne wrote:
[snip]
>> Pointers even need to be told whether it is the pointer that is const
>> or the value pointed to, or both for that matter.
>>
> This is what I was talking about with the ugliness of const, not the naming system.
>
>    const Fred const * p;
>

Yep, that one doesn't look nice. (And it's a bit confusing too.)


> is a bit excessive, don't you think? Not to mention very illegible. D's move to implicit reference semantics for classes means that we can get a   generally-easier-to-read syntax, like is proposed in Javari:
>
>    readonly final Fred p;
>
> where 'readonly' refers to the actual data, and 'final' means that p can't be used as an lval (ie, the pointer itself is const).

That's indeed more readable. I woundn't mind using it or something similar.


From time to time I wish that C++ would have a readonly specifier that works like this:

class Obj {
    void f() {
        int m_size = 10;  //ok
    }

    readonly int m_size;
}

void func() {
    Obj o = new Obj;
    int v;

    v = o.m_size;  //ok
    o.m_size = 5;  //error
}

'm_size' can be accessed inside 'Obj' as normal, but outside the class the variable cannot be modified. Of course, I could provide a read property (that is, a function in C++) for accessing 'm_size' (in addition to a write property), but when it's not necessary, this way is simplier (and a little bit faster, etc.).

In D this, however, is not needed because you can use properties to wrap member variables.
(Hopefully the properties will be extended to support the same methods that can be applied to variables also... ;) )

Kristian wrote:
> ...

Those "physical types", are called value types.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

On Sat, 23 Sep 2006 00:35:07 +0300, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:

> Kristian wrote:
>  > ...
>
> Those "physical types", are called value types.
>
>


Hehheh, so they are. Sometimes it's just too hard to come up with the correct term... ;)