strtr:
> Is it possible to have different vpointers/monitors pointing to the same object?

I think this questions is meaningless. Those pointers don't point to objects.

And the "is" operator compared class references, not vpointers/monitors.

Bye,
bearophile

bearophile Wrote:

> strtr:
> > Is it possible to have different vpointers/monitors pointing to the same object?
> 
> I think this questions is meaningless. Those pointers don't point to objects.
> 
> And the "is" operator compared class references, not vpointers/monitors.
> 
> Bye,
> bearophile

The subject wasn't for nothing :)
How I understand it now, vptr points to the Class's vtable.
This would mean they should be the same for references to the same object or can these references also hold a pointer to a pointer to the vtable?
I'm not sure where the monitor points to, though.

The problem surfaces when I wanted to do a simple check for objects equality between references. I though I should use "is" for this. But to my astonishment it failed even though I know the references point to the same object, I think.
I checked whether the references pointed to the same object by giving all objects a unique value and changing this value via one of the references and then checking whether the value was the same for the other reference.
Conclusion: two references fail "is", but changing the value via one of the references also changed the value got via the other reference.

My solution for now is simply checking for equality via this unique value but I hoped I could use "is" for this :)

I suspect I totally misunderstand something; hope to learn something again :)

Time ago I have told Walter that adding images with pointers and boxes to the D docs, that represent the main data structures used in D, can help a lot the understanding and usage of D.

When you *see* the data structure in an image, understanding what happens and how to write program gets easy. So I'd like to see images of the virtual table, an object, interface, etc.

A class reference is a pointer, that is the index (an integer number) of the first byte of RAM of a segment of RAM.

The segment of ram contains the class instance data, plus two more pointers at its start, one to the virtual table, and one to the monitor. The virtual table is a struct that contains indirect pointers to the virtual functions and more. I don't know the layout of the virtual tables in dmd. And I have no idea how the monitor is structured, it's a mystery for me still. I am learning still.

All the instances of a single class point to the same virtual table. Instances of different classes contain pointers to different virtual tables. All objects in D have a pointer to VPT, even classes with no virtual methods. (Structs have no pointer to monitor and vtbl, but they can have a pointer to outer scope if they are not static. This is true for classes too, and there is a little more complexity coming from template instantiations inside functions in D).

When you instantiate a class you create a new section of memory that contains the class members, plus the two pointers.

You can have more than one reference to the same object. And two distinct objects in memory can have the same data into their members.

The "is" operator just compares the class instances, if they are equal (the optimizer can avoid some tests if it knows the objects are surely different, because it knows the static types).

The == among class instances does several things. See D docs page about operator overloading. But basically it tests if the references are the same. If it's true, then they are two references to the same class instance, so they must be equal, and the == returns true.
If the references are different it tests for equality of all members, and returns true if they are all equal, otherwise false.

Bye,
bearophile

On Tue, 06 Apr 2010 21:15:02 -0400, bearophile <bearophileHUGS@lycos.com> wrote:
> 
> Time ago I have told Walter that adding images with pointers and boxes to the D docs, that represent the main data structures used in D, can help a lot the understanding and usage of D.
> 
> When you *see* the data structure in an image, understanding what happens and how to write program gets easy. So I'd like to see images of the virtual table, an object, interface, etc.
> 
> A class reference is a pointer, that is the index (an integer number) of the first byte of RAM of a segment of RAM.
> 
> The segment of ram contains the class instance data, plus two more pointers at its start, one to the virtual table, and one to the monitor. The virtual table is a struct that contains indirect pointers to the virtual functions and more. I don't know the layout of the virtual tables in dmd. And I have no idea how the monitor is structured, it's a mystery for me still. I am learning still.
> 
> All the instances of a single class point to the same virtual table. Instances of different classes contain pointers to different virtual tables. All objects in D have a pointer to VPT, even classes with no virtual methods. (Structs have no pointer to monitor and vtbl, but they can have a pointer to outer scope if they are not static. This is true for classes too, and there is a little more complexity coming from template instantiations inside functions in D).
> 
> When you instantiate a class you create a new section of memory that contains the class members, plus the two pointers.
> 
> You can have more than one reference to the same object. And two distinct objects in memory can have the same data into their members.
> 
> The "is" operator just compares the class instances, if they are equal (the optimizer can avoid some tests if it knows the objects are surely different, because it knows the static types).
> 
> The == among class instances does several things. See D docs page about operator overloading. But basically it tests if the references are the same. If it's true, then they are two references to the same class instance, so they must be equal, and the == returns true.
> If the references are different it tests for equality of all members, and returns true if they are all equal, otherwise false.
> 
> Bye,
> bearophile

I think he said that he has two distinct object references, but the value stored in the object(s) changes by changing either one.

In other words, we'd need to see the code.

bearophile Wrote:

> Time ago I have told Walter that adding images with pointers and boxes to the D docs, that represent the main data structures used in D, can help a lot the understanding and usage of D.
> 
> When you *see* the data structure in an image, understanding what happens and how to write program gets easy. So I'd like to see images of the virtual table, an object, interface, etc.
> 
> A class reference is a pointer, that is the index (an integer number) of the first byte of RAM of a segment of RAM.
> 
> The segment of ram contains the class instance data, plus two more pointers at its start, one to the virtual table, and one to the monitor. The virtual table is a struct that contains indirect pointers to the virtual functions and more. I don't know the layout of the virtual tables in dmd. And I have no idea how the monitor is structured, it's a mystery for me still. I am learning still.
> 
> All the instances of a single class point to the same virtual table. Instances of different classes contain pointers to different virtual tables. All objects in D have a pointer to VPT, even classes with no virtual methods. (Structs have no pointer to monitor and vtbl, but they can have a pointer to outer scope if they are not static. This is true for classes too, and there is a little more complexity coming from template instantiations inside functions in D).
> 
> When you instantiate a class you create a new section of memory that contains the class members, plus the two pointers.
> 
> You can have more than one reference to the same object. And two distinct objects in memory can have the same data into their members.
> 
> The "is" operator just compares the class instances, if they are equal (the optimizer can avoid some tests if it knows the objects are surely different, because it knows the static types).
> 
> The == among class instances does several things. See D docs page about operator overloading. But basically it tests if the references are the same. If it's true, then they are two references to the same class instance, so they must be equal, and the == returns true.
> If the references are different it tests for equality of all members, and returns true if they are all equal, otherwise false.
> 
> Bye,
> bearophile

I totally agree on the visual help!
I think I'll create such a diagram after I get my brain mess cleaned up :)
Your explanation doesn't differ (but does expand ;) from my understanding  of the whole class implementation subject. I still do not know what a monitor is though ;)

Justin Spahr-Summers Wrote:
> 
> I think he said that he has two distinct object references, but the value stored in the object(s) changes by changing either one.
> 
> In other words, we'd need to see the code.

I've added this exact sequence:

	if( c1 !is null )
	{
		c1.value = 1;
		if( c2 !is null )
		{
			c2.value = 2;

			if( c1 !is c2 )
			{
				c1.value = 3;
				assert(c2.value == 2 );
			}
			c2.value = 0;
		}
		c1.value = 0;
	}

To my understanding this should never fails, yet it does. AssertError Failure

On Tue, 06 Apr 2010 22:41:43 -0400, strtr <strtr@spam.com> wrote:
> 
> Justin Spahr-Summers Wrote:
> > 
> > I think he said that he has two distinct object references, but the value stored in the object(s) changes by changing either one.
> > 
> > In other words, we'd need to see the code.
> 
> I've added this exact sequence:
> 
> 	if( c1 !is null )
> 	{
> 		c1.value = 1;
> 		if( c2 !is null )
> 		{
> 			c2.value = 2;
> 
> 			if( c1 !is c2 )
> 			{
> 				c1.value = 3;
> 				assert(c2.value == 2 );
> 			}
> 			c2.value = 0;
> 		}
> 		c1.value = 0;
> 	}
> 
> To my understanding this should never fails, yet it does. AssertError Failure

Hmm, that is pretty weird. Are you doing any casts anywhere, or any pointer arithmetic/tricks?

The only thing that I can think of is that you might've somehow unintentionally fooled the compiler/runtime by coercing some types somewhere.

If not, it might comprise a valid bug report.

Justin Spahr-Summers Wrote:
> 
> Hmm, that is pretty weird. Are you doing any casts anywhere, or any pointer arithmetic/tricks?
A search for cast didn't show any related casts.
Do you maybe know another thing to check?
I do throw references around and there are a lot of implicit casts to extended interfaces.

> 
> The only thing that I can think of is that you might've somehow unintentionally fooled the compiler/runtime by coercing some types somewhere.
Don't the different vptrs also hint to this?

> 
> If not, it might comprise a valid bug report.
Trying to find a minimal version.. might take some time :(

On Tue, 06 Apr 2010 23:35:01 -0400, strtr <strtr@spam.com> wrote:
> 
> Justin Spahr-Summers Wrote:
> > 
> > Hmm, that is pretty weird. Are you doing any casts anywhere, or any pointer arithmetic/tricks?
> A search for cast didn't show any related casts.
> Do you maybe know another thing to check?
> I do throw references around and there are a lot of implicit casts to extended interfaces.

Without actual explicit casting, I don't know how it'd be possible to invoke behavior like that. Maybe an object of class X getting implicitly converted to interface A and then explicitly cast to class Y? It'd have to be pretty convoluted.