There's nothing stopping a D compiler from turning a suitable switch into a jump table.  In the string case the compiler could build a hidden static constant associative array to a jump address, or it could turn it into a series of if-else statements.  For integers or enums it should be able to optimize as much as C can.  I can't think of a reason anyone would want to switch on the value of a float unless one could specify ranges for each case.  I have no idea if switches on class instances would be legal or not, as it seems like we won't be able to override class operator ==.

What is the defined behavior for comparing two object instances?  Compare the actual pointers, and if they're the same return true.  Otherwise compare their vtable pointers, and if they're the same, compare the actual data member by member.

I suppose memberwise assignment of an object to another isn't possible, since it seems it would just assign the reference pointer?  What about structs?

Sean

"a" <a@b.c> wrote in message news:3C0B150D.E8A5ADAC@b.c...
> I believe if was suppose to be the high level equivalent of a conditional branch.  Switch was supposed to be the equivalent of a jump table.  The is a performance difference.  C made it pretty easy to look at the code and know what the compiler was going to do to it.
>
> Dan

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9ufi76$2k1b$1@digitaldaemon.com...

> What is the defined behavior for comparing two object instances?  Compare the actual pointers, and if they're the same return true.  Otherwise
compare
> their vtable pointers, and if they're the same, compare the actual data member by member.

I believe pointers are compared. Otherwise, there's no way to find out if two references point to the same object.

> I suppose memberwise assignment of an object to another isn't possible, since it seems it would just assign the reference pointer?  What about structs?

Since structs are not references, it seems just logical for them to be copied on assignment, like in C/C++.

a wrote:

> I see how it works, but it is not very general purpose.  If Apple and Orange had some other common base (say fruit) this suddenly breaks.

But if the programmer has declared (by the class structure) that Fruit are Comparable, then why not use that to compare them?

> This container simply uses the first ancestor after Object to divide types into equivalence classes.  A general container should not make this type of assumption.  A domain specific probably ought to deal more with the base classes it was designed for.

I'm not sure why this is a problem.  Examples, please, so I can understand better?

>         I guess you could have a common base other than object (again Fruit)
> and make it a design decision that direct children of that class are not
> comparable.  I would also put the requirement to implement compare in
> that class.  I guess I see how it can be used.  I don't like it, but it
> will take a while for me to decide if it's just because it's new to me.
>         You do know that such a design will require the eventual addition of
> multiple inheritance once the biological engineers make a fruit that can
> be compared to it's own kind as well as apples and oranges.  :-)

????  If fruit are comparable, then why not just declare Fruit as implementing interface Comparable? I'm lost again.

>         Also your error message in the first if is wrong.  All classes in D
> have a common parent class.  I see you are trying to simulate a C++
> style object model in this sense but it may clash with D code that does
> not differentiate between Objects that only have a parent of Object.

True, it was kind of rough.  Acutally, the message should be "Cannot compare objects: no common parent class other than Object"

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9ufi76$2k1b$1@digitaldaemon.com...
> What is the defined behavior for comparing two object instances?  Compare the actual pointers, and if they're the same return true.  Otherwise
compare
> their vtable pointers, and if they're the same, compare the actual data member by member.

Compare the pointers. There is a root overridable method called cmp(),
however. cmp() will get used for sorting arrays, for building associative
arrays out of objects, etc.

> I suppose memberwise assignment of an object to another isn't possible, since it seems it would just assign the reference pointer?

Correct.

> What about structs?

It'll always do a bit copy - based on the notion that structs are simple aggregations.

I've always been uncomfortable with the C++ notion that arbitrary functions can be executed when copying structs.

Walter wrote:

> "Sean L. Palmer" <spalmer@iname.com> wrote in message
> news:9ufi76$2k1b$1@digitaldaemon.com...
>>I suppose memberwise assignment of an object to another isn't possible,
>>since it seems it would just assign the reference pointer?
>>
> 
> Correct.


Does this mean the language should provide a deep-copy or clone operation?


>>What about structs?
>>
> 
> It'll always do a bit copy - based on the notion that structs are simple
> aggregations.



Will that break structs that include class members?

-R

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C0E62DD.803@estarcion.com...

> Does this mean the language should provide a deep-copy or clone operation?

I've also thought of it... maybe a built-in assign() method
or a new operator (":=" ?) or something like that?

> > It'll always do a bit copy - based on the notion that structs are simple aggregations.
>
> Will that break structs that include class members?

Why? It'll simply copy the pointer, so you get two structs referencing one object - not a problem.

Pavel Minayev wrote:
> 
> "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C0E62DD.803@estarcion.com...
> 
> > Does this mean the language should provide a deep-copy or clone operation?
> 
> I've also thought of it... maybe a built-in assign() method
> or a new operator (":=" ?) or something like that?
> 
> > > It'll always do a bit copy - based on the notion that structs are simple aggregations.
> >
> > Will that break structs that include class members?
> 
> Why? It'll simply copy the pointer, so you get two structs referencing one object - not a problem.

As long as the referenced object gets its refcount increased, I suppose so.[1] I guess I'm still thinking in terms of the bastardized C/C++ hybrid code that I deal with daily, where references and pointers are mixed at whim, and you have to play "guess the semantic" everywhere.

(Especially when the compiler randomly decides that reference members in structs somehow make struct initializers not work. Grrrrrr.)

-RB

[1] Walter, does updating ref counts qualify as "arbitrary functions [...] executed when copying structs?"

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C0E7447.E2DA8E9F@estarcion.com...

> [1] Walter, does updating ref counts qualify as "arbitrary functions [...] executed when copying structs?"

Ref counts? I've always thought there are none in D,
and different techniques are used...

Walter, the more I hear you talk, the more I think D may not be for me. People that afraid of code being executed that isn't specified right there in the source file are people that want big bloated source files, and that isn't for me.  I want the compiler to do stuff automatically for me, if it is so instructed or designed.  It's not like people can't figure out what's going on by stepping through the code in the debugger.

It seems to me that all the nicest and most powerful features of C++ have been dropped just to end up with a language that cleans up just a few of C/C++'s worst things (header files, memory leaks) without really adding much besides native string support and associative and dynamic arrays.  Guess what... you can already do all that stuff in C++, using templates and operator overloading, 2 of the things you seems to abhor.

Walter, I think you and I just have a basic philosophical difference.  D sounded nice at first but the more I listen to you the more I realize it's just not the right language for me.  Maybe C# version 2.0 will be ok...

Sean


"Walter" <walter@digitalmars.com> wrote in message news:9ukrph$k78$1@digitaldaemon.com...
>
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:9ufi76$2k1b$1@digitaldaemon.com...
> > What is the defined behavior for comparing two object instances?
Compare
> > the actual pointers, and if they're the same return true.  Otherwise
> compare
> > their vtable pointers, and if they're the same, compare the actual data member by member.
>
> Compare the pointers. There is a root overridable method called cmp(),
> however. cmp() will get used for sorting arrays, for building associative
> arrays out of objects, etc.
>
> > I suppose memberwise assignment of an object to another isn't possible, since it seems it would just assign the reference pointer?
>
> Correct.
>
> > What about structs?
>
> It'll always do a bit copy - based on the notion that structs are simple aggregations.
>
> I've always been uncomfortable with the C++ notion that arbitrary
functions
> can be executed when copying structs.

It's entirely possible we have different philosophies on what makes a great language. And that's fine, the give and take here is valuable. I have read your posts with great interest.

One crucial feature of D you didn't mention, and which unfortuately isn't obvious, is the design by contract and unit testing features. I've tried to do them in my C++ code, but the results aren't pretty or satisfactory. When I have used them, I discovered that the code was much more bug-free, reliable, and development was faster.

-Walter

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9unc1g$ed$1@digitaldaemon.com...
> Walter, the more I hear you talk, the more I think D may not be for me. People that afraid of code being executed that isn't specified right there in the source file are people that want big bloated source files, and that isn't for me.  I want the compiler to do stuff automatically for me, if it is so instructed or designed.  It's not like people can't figure out
what's
> going on by stepping through the code in the debugger.
>
> It seems to me that all the nicest and most powerful features of C++ have been dropped just to end up with a language that cleans up just a few of C/C++'s worst things (header files, memory leaks) without really adding
much
> besides native string support and associative and dynamic arrays.  Guess what... you can already do all that stuff in C++, using templates and operator overloading, 2 of the things you seems to abhor.
>
> Walter, I think you and I just have a basic philosophical difference.  D sounded nice at first but the more I listen to you the more I realize it's just not the right language for me.  Maybe C# version 2.0 will be ok...
>
> Sean
>
>
> "Walter" <walter@digitalmars.com> wrote in message news:9ukrph$k78$1@digitaldaemon.com...
> >
> > "Sean L. Palmer" <spalmer@iname.com> wrote in message news:9ufi76$2k1b$1@digitaldaemon.com...
> > > What is the defined behavior for comparing two object instances?
> Compare
> > > the actual pointers, and if they're the same return true.  Otherwise
> > compare
> > > their vtable pointers, and if they're the same, compare the actual
data
> > > member by member.
> >
> > Compare the pointers. There is a root overridable method called cmp(),
> > however. cmp() will get used for sorting arrays, for building
associative
> > arrays out of objects, etc.
> >
> > > I suppose memberwise assignment of an object to another isn't
possible,
> > > since it seems it would just assign the reference pointer?
> >
> > Correct.
> >
> > > What about structs?
> >
> > It'll always do a bit copy - based on the notion that structs are simple aggregations.
> >
> > I've always been uncomfortable with the C++ notion that arbitrary
> functions
> > can be executed when copying structs.
>
>
>